Nesne yönelimli programlama hangi problemler için iyi bir seçim değildir? [kapalı]

Bu sorudan biraz ilham alındı: İşlevsel programlama hangi yaygın problemler için uygun değildir? - ama yine de hep istediğim bir soru ama sormaktan çok korkuyordum.

Ben ... iyiyim, buna neredeyse tüm yaşamım boyunca mühendislik yazılımı geliştirme diyelim ve tüm bu süre boyunca, OO her zaman orada olmasına rağmen (o zamanlar çoğu zaman) hiç kullanmaya ihtiyacım olmadı "onun yolları" ne de bu paradigmayı öğrenmek için. Her zaman oldukça basit program yapıları, rutinler / fonksiyonlar / modüller kullandık ve bu programları yöneten günümüzün en iyi uygulamalarının (yaklaşık 300k LOC'a kadar olan programlar, çok büyük bir şey değil) tersine olsa da, imkansız olsa bile, hiç zor olmadı.

Size sormak istedim, nesne yönelimli paradigmanın iyi bir seçim olmayacağı sorta problemleri ne olurdu? Prosedürel programlamaya kıyasla?

Nesne yönelimli programlama olduğu prosedürel programlama. OO nesnesini yönlendiren şey, Robert Harvey'nin bir yorumda belirttiği gibi, OO'nun verileri belirli bir şekilde soyutlamasıdır (zekâ: bu yapı ile çalışan bir yapı üzerinde çalışan fonksiyonları bir araya getirme).

William Cook , nesneler ve soyut veri türleri arasındaki farkı güzelce açıklıyor.

Bu nedenle, ses çıkarma riski altında, verileriniz üzerinde gerçekleştirilen (sayısı) işlemleri kolayca genişletmeniz ve nesnelerinizin çeşitli uygulamalarına sahip olmanız gerekmediğinde nesnelerin uygun olmadığını söyleyebilirim. veri. Bunu söyledikten sonra , ikisini birbirine yaklaştırmak için yapabileceğiniz şeyler var .

OO'nun ana değeri, sisteminizin bileşenleri arasında ayırma sağlayarak DRY kodu yazmayı ve tasarımınızda planladığınız belirli türdeki değişikliklere uyum sağlamayı kolaylaştırmasıdır. Maliyet, kodun akla daha zor, daha az verimli ve beklenmedik şekillerde değiştirilmesini daha zor hale getirebilen (tasarımınızın sağladığı ayrışmanın yardım etmediği yollar) dolaylı katmanlar eklemesidir. Bu nedenle, sağladığı ayrıştırmaya ihtiyaç duymadığınız herhangi bir alt problem için zaman kaybıdır. Özellikle, DRY kodunu onsuz kolayca yazabiliyorsanız ve OO'nun sağladığı güçlü ayrıştırmadan yararlanacak herhangi bir özel gereksinim değişikliği öngörmüyorsanız, zaman kaybıdır .

eşzamanlılık: kilitleme mekanizması biraz sorunlu görünmektedir; sadece bazı çok iyi geliştiriciler projelerin iş parçacığı üzerinde çalışmaya başladı

genişletme: mevcut OO dillerinin ne kadar genişletilebilir olduğunu bilmiyorum. sadece Java'nın kötü olduğunu bilin. bunun için DSL'lerin (alana özgü diller) Çerçeveler olarak uygulanması gerekir. Clojure ise (işlevsel) makrolara sahiptir.

Çoğu programcı, OO anlayışlı olsun veya olmasın, kodlarında soyutlama, bilgi gizleme ve arayüzler gibi kavramları kullanır. OO dilleri, bu kavramlar zaten yerleşik olduğu için bunu kolaylaştırır. Onları kendiniz icat etmek zorunda değilsiniz.

Gibi çekirdek bir algoritma qsort(), keyfi nesnelerin karşılaştırılması için soyutlamalar kullanır. fread()akış vb ayrıntılarını soyutlamak için bir arayüz kullanır.

O bakış açısından, OO olmayan bir yaklaşımla daha iyi çözülmüş herhangi bir problemle karşılaşmayı zor buluyorum.

Web apis (dinlenme, xmlprc, düz kıvırmak / wget) aracılığıyla diğer sistemleri birleştiren sistemler oluştururken OO sarmalayıcıları yazabileceğinizi düşünüyorum, ancak açıkça sadece bir kolaylık. Kullanılacak web hizmeti basitse ve bu sadece bir veya iki satırdan ibaretse, OO çok fazladır. Öte yandan, karmaşık bir web api (örneğin Amazon AWS gibi) sarmak zorunda kalırsanız, bir sarıcı kitaplığı (AWS için python'daki boto gibi) olması güzeldir.

Düşünceler?

PURE nesne yönelimli diller birçok durum için uygun değildir. Çünkü saf nesneye yönelik dil olmak için yerine getirilmesi gereken bazı kriterler var. Bkz.
Https://stackoverflow.com/questions/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098

Ancak en çok kullanılan programlama dilleri çoklu paradigmadır. Çeşitli programlama ve geliştirme sorunlarıyla karşılaşmak için OO olmayan birçok özelliği içerirler. C ++, C #, Java veya Ruby'nin tümü OO olmayan işlevlere sahiptir. Böylece, saf OO'nun iyi olmadığı sorunlarla karşılaşabilirler.

Alan adınızı modellemek için Nesneye Yönelik programlama kullanılabilir. Sınıflar, alan adı modelinizdeki varlıkların, toplamların, işbirliklerinin, hizmetlerin durumunu ve davranışını temsil etmek için kullanılabilir. Ayrıca, nesneler arasındaki yöntem çağırma ve protokolleri varlıklar arasındaki dinamik ilişkileri modelleyebilir.

Uygulamanızın kurallarını ve davranışını, teknik sorunlardan (veritabanı kullanımı veya mesaj kuyruğu kullanımı veya aslında bir web uygulamasıdır). Konu ile ilgili iyi bir kitap Etki Alanına Dayalı Tasarım

Burada dikkat edilmesi gereken önemli bir nokta, yukarıda bahsettiğim "varlıklar" ın gerçek dünya nesnelerini eşlemek zorunda olmamasıdır! Bunlar, uygulamanızın alan adının soyut bölümlerini temsil edebilir.

Yani, eğer Nesne Yönelimli programlama iyi ise; ne iyi değil? Etki alanı modelinin nesneler kadar iyi ifade edilemediği herhangi bir şey. Örneğin, bazı matematiksel, (istatistiksel, mantık vb.) Veya teknik (örneğin bir derleyici) programlar farklı stillerle daha iyi ifade edilebilir. İş akışı uygulamaları için OO ve özel DSL tekniklerinin bir kombinasyonunun iş sürecinde meydana gelen ilişki ve olay türlerini modellememize olanak tanıdığını gördüm. Program doğrulaması ve otomatik kanıt kontrolü için genellikle işlevsel bir yaklaşım kullanılır, çünkü saf işlevleri daha doğrudan matematiksel akıl yürütmeye izin verir.