Gerçekten ne zaman nesne yönelimli programlama kullanıyoruz? [kapalı]

Python'da temel olarak dizeleri işleyen bir program yazıyorum ve OOP ilkelerini kullanarak yapıp yapmamam gerektiğini merak ediyordum. Müşteri kodu umursamadığını, sadece işin yapılmasını istediğini söyledi .

Nesne yönelimli kodun tanımlayıcı temizleyici olmadığını ve tersine OO dışı kodun tanımsız crappy olmadığını biliyorum. Sorduğum soru az ya da çok görüşe dayalı olabilir, ancak farkında olmadığım bazı kurallar olabilir.

Ne yapılması gerektiği hakkında biraz daha bilgi:

• bir .csvdosyayı ayrıştırma ve bir yapılandırma dosyasına göre verileri işleme koyma (sütunlar farklı olabilir - sütunların sayısı veya sahip oldukları veriler gibi)
• yeni bir özel biçimlendirilmiş veri (veya yukarıdaki değerlerden bazılarını temel alan birden fazla dosya) oluşturmak için yukarıdaki işlenmiş verileri kullanın
• XML dosyası oluşturmak için en son biçimlendirilmiş verileri kullanın.
• XML dosyasını XMLiçeriğine göre birden fazla s'ye bölme
• uygulama CLI tabanlı olmalıdır
• Elbette ki başka şeyler de var: bazı olayları günlüğe kaydetme, CLI argümanlarını ayrıştırma vb.

Şimdi, bu hiç de büyük / zor bir uygulama değil ve aynı zamanda neredeyse bitti ancak tüm gelişim süreci boyunca kendime bunun OOP kullanılarak yapılıp yapılmayacağını sorup duruyordum.

Öyleyse benim sorum şu olurdu: nasıl bir uygulamada OOP kullanacağınızı nasıl bildiniz / karar veriyorsunuz ?

Python çok paradigma bir dildir; bu, görev için en uygun paradigmayı seçebileceğiniz anlamına gelir. Java gibi bazı diller, tek paradigma OO'dur; başka bir paradigma kullanmaya çalışırsanız, başınız ağrır. "Her zaman OO kullan" diyen posterler muhtemelen böyle bir dilde bir arka plandan geliyor. Neyse ki bir seçeneğin var!

Programınızın bazı girişleri okuyan (csv ve config dosyaları) ve bazı çıktılar (xml dosyaları) okuyan, ancak etkileşimli olmayan ve dolayısıyla durum bilgisi olan bir GUI veya API içermeyen bir CLI uygulaması olduğunu unutmayın. Bu tür bir program doğal olarak girdiden çıktıya bir fonksiyon olarak ifade edilir, bu da alt görevler için diğer fonksiyonlara yetki verir.

Öte yandan OO değişken durumu kapsüllemekle ilgilidir ve bu nedenle etkileşimli uygulamalar, GUI'ler ve API'nin açığa çıkabilen değişken durumu için daha uygundur. OO'nun ilk GUI'lere paralel olarak geliştirilmesi tesadüf değildir.

OO, polimorfizmde, aynı arabirimin farklı uygulamalarının kolayca ikame edilebildiği daha gevşek bir yapıya sahip bir mimariye izin vermesinde başka bir avantaja sahiptir. Bağımlılık enjeksiyonu ile birleştirildiğinde, bağımlılıkların ve diğer serin şeylerin konfigürasyon tabanlı yüklenmesine izin verebilir. Bu çoğunlukla çok büyük uygulamalar için uygundur. Tanımladığınızın boyutuna göre bir program için, görünürde bir faydası olmadığı kadar genel gider.

Dosyaları gerçekten okuyan ve yazan işlevlerin yanı sıra, mantığınızın büyük kısmı, bazı girdiler alan ve diğer çıktılar veren, yan etkisi olmayan işlevler olarak yazılabilir. Bu, test etmek için son derece kolaydır, bağımlılıklarla başa çıkmanız gereken OO birimlerini test etmekten çok daha kolaydır.

Alt satır: Organizasyon için modüllere bölünmüş bir grup fonksiyon öneririm, fakat nesne yok.

Bir GUI'deki bir düğmeyi düşünün. Devleti vardır (büyüklüğü, rengi, konumu, etiketi vb.). Bazı şeyler olabilir (tıklandı, yeniden çizilmesi gerekiyor vs.). Bu gibi durumlarda, onu bir nesne olarak modellemek mantıklıdır. Bir nesne olarak, durumunu içerebilir, üzerinde gerçekleştirilebilecek bir dizi eylemi (yöntemler) içerebilir ve uygulamanın diğer kısımlarına olayları ateşleyerek olayın başına geldiğini bildirir.

OOP, GUI'leri ve sistemin parçalarının uçucu durumda olduğu diğer durumları ele almak için mükemmel bir araçtır.

Açıkladığınız, örneğin bir kaynaktan okunan, işlenen ve bir hedefe yazılan diğer durumlar, farklı bir yaklaşımla iyi bir şekilde ele alınır: bildirimsel (veya işlev) programlama. Veri işleme için bildirim kodunun okunması OOP çözümlerinden daha kolay ve daha kısa olma eğilimindedir.

Hem bir çekiç hem de testere, doğru kullanıldığında hem güçlü aletlerdir hem de nesneye yönelik ve bildirimsel programlama teknikleridir. Muhtemelen bir testere sapıyla bir parça tahtaya çivi çakabilirsiniz. Aynı şekilde, bir tahta parçasını bir çekiçle ikiye bölebilirsiniz. Aynı şekilde, sadece fonksiyonlara sahip bir GUI oluşturabilir ve verileri nesnelerle birlikte işleyebilirsiniz. Aletler doğru kullanıldığında sonuçlar daha temiz ve basittir.

Kullandığım genel kural, çok fazla durumum varsa veya kullanıcı etkileşimi gerekiyorsa nesneleri kullanmam; Aksi halde (mümkünse saf ve yüksek dereceli) işlevler kullanırım.

Nesneye Yönelik Programlama cephaneliğinize dört yeni araç ekler :

1. kapsülleme
2. Soyutlama
3. miras
4. Polimorfizm

Uygulamanızda, bu araçlardan faydalanacak kadar geniş ve karmaşık bir hale geldiğinde OOP'yi kullanırsınız.

Bu soru bana biraz karıştı. Python'da yazıyorsanız, kesinlikle nesneleri kullanacaksınız . Bir dosyayı açtığınızda, bir nesne döndürür. Sonuç verdiğinizde, bir yineleyici Nesnesi döndürür. Oluşturduğunuz her işlev bir nesnedir. Python uygulamalarında OO'nun değerini sorgulamak en azını söylemek garip görünüyor.

Buradaki yorumlara dayanarak, evet, Python fonksiyonel paradigmaları destekliyor, ancak öncelikle nesne temelli. Dilin kendisi ve yerleşik kütüphaneler nesnelerin etrafında yönlendirilir. Evet, lambda'yı destekler (Java ve tipik olarak OO olarak tanımlanan diğer birçok dilde olduğu gibi), ancak gerçek bir işlevsel dile kıyasla kasıtlı olarak basittir.

Belki de OO tasarımı ve işlevsel tasarım hakkındaki bu ayrımlar eski hale geliyor. Bir OO tasarımlı Nesne * üzerinde polimorfik bir işlev alırsam ve o nesneye işlevsel bir şekilde stillenmiş işlevin parametresi olarak bir işaretçi iletirseniz *, OO mu yoksa işlevsel mi? Bence bu hem problemleri çözmede hem de etkili bir yaklaşım.

Bence asıl soru, 'sadece kendi işlevlerini yerine getiren bir modül yaratmaya karşı kendi sınıflarını ne zaman tasarlamaya başlaman gerekiyor?' Bence bunun için doğru cevap: çözümü basitleştirmeye yardımcı olduğu zaman. Herhangi bir nesne yönelimli dil için aynı temel cevabı veririm.

* fazlalık kasıtlı: Burada nesnelerin OO olduğunu veya işlevlerin işlevsel olduğunu varsaymakla suçlanmak istemiyorum.

Nesne yönelimli programlama ile ilgili en büyük şeylerden biri, program akışını düşünmek yerine durum hakkında akıl yürütmeye başlamanızdır.

Çoğu zaman nesneyi görüyorum, yöntemleri görüyorum ama aynı zamanda gördüğüm şey kodun arkasındaki itici düşüncenin durum yerine akış olduğudur.

Ve durum hakkında bir kez sebep verdiğinizde, iyi bir OOP kodu oluşturmak kolaydır, çünkü kodunuz çok karmaşık olur olmaz, artık durumunuzla ilgili bir sebep olamayacağınızı ve yeniden yönlendirici yapmanız gerektiğini bildiğinizi fark edersiniz.

Örneğinizi düşünün: Bir csv dosyasını ayrıştırmak istiyorsunuz. Nereden geliyor: diskteki bir dosya. Yüklüyor ve hafızaya alıyorsunuz ve ayrıştırıyorsunuz. Şimdi müşteriniz geliyor: hey Ben de dosyaları web'den ayrıştırmak istiyorum. Bu yüzden mutlusunuz, çünkü dosyanızı yüklemek için hoş bir arayüz oluşturdunuz ve yalnızca dosyayı webden alan kodu hazırlamanız gerekiyor ve programın geri kalanı aynı kalıyor.

Ve güzel olan şey: Bunun için test edebilirsiniz.

Layman'ın terimiyle:

• OOP veya OOP olmayan her türlü projelerde kullanabilirsiniz.
• OOP her derde deva değil, karmaşıklığı yönetmeye yardımcı oluyor.
• Modülerliğin ötesine geçer, bölümlendirmeyle ilgilidir. Bir gemi hasar görmüşse yüzdürmeyi korumak için sahip olduğu farklı bölmeleri düşünün.
• OOP bağımlılıkları yönetmenin bir yoludur, bu nedenle bir programın farklı bileşenlerinin diğerini iletebilmesi için tanımlanmış bir dizi yol olduğundan hataların izlenmesi daha kolay olabilir.
• Bir programda çalışan birçok şey var: değişkenler, sabitler, yöntemler, dosyalar, parametreler, işlevler, modüller vb. Bunlar birbirleriyle bazen anlaşılmaz şekilde etkileşime girebilirler. OOP, birbirlerinin birbirleriyle etkileşime girme yollarını azaltan bir dizi prensiptir. Bunu yapmak için OOP kullanmaya mecbur değilsin, ama işe yarıyor.

Bu, dikkate alınması gereken başka faktörler olduğunu söyledi:

• Programcılarınız OOP / OOD konusunda uzman mı?
• Programcılarınız bir OOP dilinde yetkin mi?
• Yazılımın zaman içinde karmaşık olacağını düşünüyor musunuz?
• Gelecekte kodu ölçeklendirmeyi veya yeniden kullanmayı planlıyor musunuz?
• "Tasarımınızın" bir varlık olabileceğini düşünüyor musunuz? Örneğin, büyümek için mi yoksa gelecekteki projeler için bir temel olarak mı kaldıracaksınız?

Beni yanlış anlama: OOP kullanmadan hepsini başarabilirsin, ancak OOP ile daha kolay olacak.

Fakat...

Ekibiniz OOP / OOD konusunda uzman değilse ve o alanda uzmanlığa sahip değilseniz, sahip olduğunuz kaynaklara gidin.

Öyleyse benim sorum şu olurdu: nasıl bir uygulamada OOP kullanacağınızı nasıl bildiniz / karar veriyorsunuz?

Her zaman kullan. Kullanmaya alışınca, her şey için kullanacaksın. Yetenekler ve kullanımları arasında iyi bir soyutlama sağlamanın mükemmel bir yoludur, bu bakım için önemli bir avantajdır. Örneğin, örneğin

• küçük veri yapısı nesneleri, çünkü bunlar genellikle polimorfiktir, örneğin ve bir şeyi ayrıştırdıktan sonra ara veri yapısı, genellikle ortak davranışı olan ve aynı zamanda özelleşmiş birden çok küçük varlığa sahiptir. Bunlar, özel uygulamalar ve davranışlar, yani bir sınıf hiyerarşisi (polimorfizm) ile ortak bir temel sınıf veya arayüz için harika bir kullanım durumudur.

• Örneğin, farklı bir loggerın yerini almayı kolaylaştırdığı için loglama

• büyük program yapısı parçaları, çünkü birden fazla eşzamanlı olanı bir araya getirirsiniz ve belki de çoklu işlemci işlemcilerinden yararlanabilirsiniz. Örneğin, bir web sunucusu nesneler nedeniyle eşzamanlı olarak birden fazla eşzamanlı istek işleyicisini kullanabilir.

Yeniden düzenlemeyi ve yeniden kullanımı kolaylaştırır, daha önce de belirttiğim gibi, her biri bakımı kolaylaştıran iyi bir soyutlamayı teşvik eder. OOP her zaman benimsenmeli ve kullanılmalıdır. İyi OOP programlaması statik yöntemlerden ve / veya statik verilerden kaçınır ve her şey için nesneler kullanır.

Nesneye Dayalı Programlama, çerçeve oluşturmak için araçlar sağlar. Bu araçlar Kapsülleme, Soyutlama, Kalıtım ve Polimorfizmdir. Bu fikirler, programınızı iki bölüme ayırmanıza yardımcı olacaktır.

Nasıl Yapılır - Bu, kodunuzun çerçeve çalışması kısmıdır, bir tür soyutlama yaratırsınız, bloklarınızın genel olarak nasıl çalıştığına ve diğer bloklarla nasıl etkileşime girdiğine karar verir.

Yapılması Gerekenler - Bu kısım blokların fiili işi kendisi yaptığı yerdir. Burada sınıf, "Nasıl yapılır" bölümünde oluşturulan temel sınıflardan türetilir.

Bir OOPS'den büyük ölçüde faydalanılabilir

1. Mevcut bir çerçeveyi tekrar kullanabilir ve sadece "ne yapmalı" bölümünde özel detaylar uygulamak zorundaysanız.
2. Mevcut proje için uygulanmakta olan işlevsellik, jenerik / yaygın olarak kullanılan bir projedir ve diğer proje / gelecek projeleri, mevcut projenin geliştirilmesi sırasında oluşturulan çerçeveden fayda sağlayabilir.
3. Büyük projeleri parçalamak, büyük bir sorunu çözmek için sık sık bilinen kalıpları bilir.
4. Küçük bir proje için bile kullanma alışkanlığına girmek için OOPS kullanın ve 1 - 3 tip problemler ortaya çıktığında hazır olun