Nesneye Yönelik Programlama karmaşıklığa bir çözüm müdür? [kapalı]

Nesne Odaklı Programlamanın karmaşıklığa bir çözüm olduğunu düşünüyor musunuz? Neden? Bu konu biraz tartışmalı olabilir ama niyetim neden buradaki uzmanlardan cevabı bilmek!

Karmaşıklığın çözümü yoktur.

"Mythical Man-Month" da Fred Brooks, programlamadaki kazara ve temel karmaşıklık arasındaki farkı tartışıyor. Yanlışlıkla karmaşıklık, bir dilde ek kod yazmak ve test etmek gibi araç ve yöntemlerimizden kaynaklanır, çünkü fikirlerimizi doğrudan ifade edemeyiz ve bunun gibi şeyler. Yeni yöntem ve teknikler kazara karmaşıklığı azaltabilir. Programları yirmi beş yıl öncesine göre daha hızlı ve daha iyi yazabilirim çünkü daha iyi dil ve araçlara sahibim.

Temel karmaşıklık, programlama ile yapmaya çalıştığımız şeyin doğası gereği karmaşık olduğu ve indirgenemez bir karmaşıklık olduğu gerçeğinden kaynaklanmaktadır. "Temel", bu bağlamda, "çok gerekli" olmak yerine "şeyin özü ile ilgili" anlamına gelir.

Bu nedenle, gümüş mermi olmayacağını, yazma yazılımının zor olmaya devam edeceğini iddia etti.

Kitabını okumanızı şiddetle tavsiye ederim: özellikle, ek bir "Gümüş Kurşun" denemesiyle Gümüş Yıldönümü baskısını öneriyorum. Bu bağlamda, karmaşıklığa yönelik önerilen çözümleri gözden geçirir ve etkilerini dikkate alır. (En etkili bulduğu şey shrink-wrap yazılımıdır - bir kez karmaşık bir şeyler yazın ve binlerce veya milyonlarca kopya satın.)

Şimdi, nesne yönelimli programlama, doğru yapıldığında, soyutlamalar yaratarak ve karmaşıklığı gizleyerek yardımcı oluyor. Bir sınıfın nesnesi, uygulamanın karmaşıklığına dikkat etmeden akla getirebileceğimiz belirli bir tanımlanmış davranışa sahiptir. Düzgün yazılmış sınıflar birbirleriyle düşük bağlantıya sahiptir ve böl ve fethet, eğer ondan kurtulabilirseniz karmaşıklıkla başa çıkmanın mükemmel bir yoludur. Birbirleriyle çok yakından ilgili olan bir dizi işlev ve veri oldukları için yüksek bir kohezyona sahiptirler.

Yakında daha iyi cevaplar alacağınızı umuyorum, ancak basit bir cevap:

OOP, yazılımı dünyadaki diğer her şeyi modelleme şeklimize daha yakın bir şekilde modelleyerek karmaşıklığa * yardımcı olur. Bir duvar nesnesiyle etkileşime giren bir top nesnesini görüntülemek genellikle aynı şeyi yapmak için bir dizi rutin ve veri yapısını hayal etmekten daha kolaydır, çünkü gerçek dünyayla nasıl etkileşim kurduğumuza daha yakındır.

* Çünkü hiçbir şey karmaşıklığı 'çözemez'

OOP'un şu anki ana akım tanımının karmaşıklığı yönetmek için iyi bir çözüm olmadığını düşünüyorum.

Köklerine geri dönerseniz Alan Kay'ın "lisp" den çok etkilendiğine inanıyorum.

Lisp ana akım benimsenmesi ile bozulmadığı için muhtemelen temel değerlerini korumayı başardı. Bu yüzden lisp'in bu karmaşıklık sorunuyla nasıl başa çıktığını incelemek bize bir fikir verebilir ve bunu karmaşıklıkla başa çıkmada OOP'un ne kadar yararlı olduğunu yargılamak için bir temel olarak kullanabiliriz.

"Ders 3a: Henderson Escher Örneği" ifadesinin sonundaki bakarsak ait SICP Hal Abelson karmaşıklığı, daha küçük alt görevler içine görevi kırarak ancak soyutlama katmanları yaratarak değil yönetildiğini önermektedir. En üst düzeyde, daha düşük soyutlama düzeyine çözüm açısından karmaşık soruna çözüm ifade edersiniz.

Bence OOP aslında bu soyutlama katmanlarını yaratmak için bir mekanizma olarak düşünülmüştü.

Ne yazık ki günümüzde, OOP spagetti kodu / yapıları yazmak için kullanılmaktadır.

Bir örnek oluşturacağım: Bir FPS çok oyunculu oyun.

En üst düzeyde, oyun bir harita etrafında koşan ve silah kullanarak birbirlerine ateş eden bir grup oyuncuya sahip olarak çalışır.

Bir sonraki alt seviyede, haritalar, silahlar ve oyuncular hakkında konuşmalıyız. Belki onlar hakkında oyunun dünyasında etkileşen fiziksel nesneler olarak konuşabiliriz.

Bir sonraki düşük seviyede, nesnelerin fiziksel olarak nasıl etkileştiklerinden (hareket, çarpışmalar, vb.) Bahsedebiliriz.

Ve bu böyle devam eder.

Bunun anlamı, (ve ben SICP'den alıntı yapıyorum ..), her katmanda sadece belirli bir problemi çözmekle kalmıyoruz, aynı zamanda problemin mahallesine düşen bir tür problemleri de çözüyoruz. çözmeye çalışıyorum. Bu nedenle, sorunun açıklamasında küçük bir değişiklik varsa, çözümde sadece küçük bir değişiklik yapılması gerekebilir.

Yani, OOP kullanmanın akıllı yolu, soyutlama katmanları oluşturmaktır, her soyutlama seviyesinde, sorunu doğrudan aşağıda bulunan seviyeden "nesneleri" kullanarak çözersiniz.

Dersten alıntı yaptığım kısım: http://www.youtube.com/watch?v=CYtrfncMqHQ

Her zamanki gibi herkese katılmıyorum. Karmaşıklığı yönetmek için araçlar vermekten çok, OOP yetersiz ve matematiksel olarak sahte bir paradigma olduğu için çok miktarda karmaşıklık yaratır. OOP ile modellenemeyen şeyleri OOP ile modellemeye çalışmak, programcıları hiçbir şekilde karıştırmaz.

Bana göre buradaki seminal çalışma Meyer'in Nesneye Dayalı Yazılım Yapısı. Önemli olduğunu düşündüğüm biri de dahil olmak üzere bir dizi gereksinimi detaylandırıyor: Açık-Kapalı Prensibi. Bu, bir şeyin uzatma için açık ancak aynı zamanda kullanım için kapalı olması gerektiğini söylüyor.

Meyer, Eiffel'de somutlaştırıldığı gibi bu gereksinimlerden Nesne Yönelimi elde etmeye devam eder. Kapsülleme, kapama, kalıtım açıklığı sağlar ve bahsedilen "şey" sınıftır.

Bu işi iyi bilim olarak görüyorum, çünkü Meyer açıkça yanlıştı ve çalışmasının kalitesi nedeniyle hatayı tespit etmek ve düzeltmek mümkündür.

Hata, modülerlik sınıfını veya türünü yapmaktır. Bu yanlış ve muhtemelen öyle. Meyer bile (kovaryans problemi olarak adlandırılır) problemi tanıdı, OOP'nin arity ilişkilerini birden fazla ele alamadığı (yani, OOP mülkler için iyi çalışıyor, ancak ikili ilişkilerde başarısız oluyor). Eyfel'de bu sorun, tip sisteminde bir ses çıkmasına neden oldu!

Çözüm oldukça açık. Modülerlik birimi tek tipten daha büyük olmalıdır. Birkaç türden ve bunlarla ilgili yöntemlerden oluşmalıdır.

Bu soyutlama modelinin, soyutlama matematiksel teorisi, yani kategori teorisi tarafından desteklenmesi şaşırtıcı değildir: türler bir kategorinin nesneleridir ve yöntemler (işlevler) oklardır.

Bu modelle, birkaç türün temsili bir dizi fonksiyon tarafından bilinir. Temsil halktan gizlidir, bu yüzden bu kapsülleme, ancak sınıfları değil modülleri kullanıyoruz.

Standart Meta Dil (SML) ve Ocaml doğrudan bu modele dayanmaktadır. Ocaml'ın da sınıfları ve OOP'si var: işe yaramaz çünkü OOP size dinamik bağlama olarak da adlandırılan özellikler hakkında bilgi verir. Bununla birlikte, gerçek dünyadaki sorunların çoğu ilişkileri içerir ve Ocaml'de sınıfların fazla kullanılmaması şaşırtıcı değildir.

C ++ Standart şablon kitaplığında hiç miras kalması pek şaşırtıcı değildir.

Basit gerçek şu ki, OOP size karmaşıklığı idare etmek için doğru araçları vermiyor, hatta gerçekten basit problemleri halletmek için araçlar bile vermiyor, bunun yerine yanıltıcı ve iki nesil programcıyı karıştırıyor. OOP, yardım etmekten çok, C, Fortran ve Cobol'un yorulmaya başlamasından bu yana programlamaya gelen en Kötü ve Kötü şeydir.

Nesne yönelimli programlama, 1960'lara kadar izlenebilen köklere sahiptir. Donanım ve yazılım gittikçe karmaşıklaştıkça, yönetilebilirlik çoğu zaman bir sorun haline geldi. Araştırmacılar, yazılım kalitesini korumanın yollarını araştırdılar ve kısmen ayrık, yeniden kullanılabilir programlama mantığı birimlerini güçlü bir şekilde vurgulayarak ortak sorunları ele almak için nesne yönelimli programlama geliştirdiler .

Bu nedenle, bir nesne yönelimli program, bir programın gerçekleştirilecek görevler listesi (alt rutinler) olarak görüldüğü geleneksel modelin aksine, etkileşen nesnelerin bir koleksiyonu olarak görülebilir. OOP'de her nesne mesaj alma, veri işleme ve diğer nesnelere mesaj gönderme yeteneğine sahiptir. Her nesne, farklı bir rol veya sorumluluğa sahip bağımsız bir 'makine' olarak görülebilir. Bu nesneler üzerindeki eylemler (veya "yöntemler") , nesnenin kendisiyle yakından ilişkilidir.

http://en.wikipedia.org/wiki/Object-oriented_programming

Endişelerin bu şekilde ayrılması, polimorfizm, kalıtım, mesaj geçirme, ayırma ve kapsülleme gibi Nesne Yönelimi'nin diğer özellikleri ile birlikte, büyük programların karmaşıklığının oldukça etkili bir şekilde yönetilebileceği mantıklı ve kavramsal bir çerçeve sağlar.

Yazılım geliştirmenin birçok karmaşıklığı vardır. Programlama düzeyinde, OOP, problem etki alanını modellemek için nesneler ve sınıflar kullanarak karmaşıklığı gidermeyi amaçlamaktadır. Tanınmış bir guru, problem çözmenin sadece problemi temsil ettiğini, böylece çözümün temsilin kendisi olduğunu söyledi. Bu nedenle, sınıfları kullanarak soyutlama, erişim değiştiricileri ve yöntemlerini kullanarak kapsülleme, ilişki ve yeniden kullanımın belirlenmesi için miras, sınıflar arasında ilişki ve işbirliğinin oluşturulmasında kompozisyon, benzer nesnelerdeki farklı davranışların belirlenmesini basitleştirmenin bir yolu olarak polimorfizm, karmaşıklık yönetilebilir.

Yazılım karmaşıklığını yönetmenin başka yolları da vardır, örneğin Mantık (Prolog) ve Fonksiyonel (Haskell) programlama.

Programlamadan daha yüksek bir seviyede, OOP'ye rehberlik etmek için Tasarım Desenlerine ve İlkelerine ihtiyacımız var. Bu nedenle OOP, karmaşıklığı düşük (kodlama) düzeyde yönetirken, Tasarım Kalıpları ve İlkeleri gibi bu metodolojiler, çözümün tasarımını daha yüksek (sistem ve uygulama) düzeyde yönlendirir ve yazılım geliştirme ve işleme karmaşıklıklarını daha yönetilebilir hale getirir.

Sorunuzu cevaplamak için, evet, OOP sadece diğer birçok çözüm arasında karmaşıklığı ele almak için bir çözümdür. Düşük seviyede bir çözümdür. OOP'u daha üst düzeyde yönlendirmek için Tasarım Desenlerine ve İlkelerine ihtiyacımız var.

Nesneye yönelik programlama , temel ve isteğe bağlı karmaşıklığı yönetir , ancak ikisini de azaltmaz.

Unix Programlama Sanatı'nda Eric Steven Raymond tarafından sağlanan tanımı tercih ediyorum , çünkü temel, isteğe bağlı ve kazara karmaşıklık arasında bir tasarıma sahip. http://www.faqs.org/docs/artu/ch13s01.html#id2964646

OOP, temel veya isteğe bağlı karmaşıklık için hiçbir şey yapmaz, programın gereksinimlerinin bir işlevidir. Yanlışlıkla karmaşıklık üzerinde bir etkisi olabilir, çünkü bazen OOP ile daha zarif bir tasarım yaratabilirsiniz. Ancak bazen OOP kullanılırken tasarım daha kötüdür.

Karmaşık problemler teknoloji ile daha basit hale getirilemez, sadece teknoloji ile yönetilebilir .

OOP bir teknoloji, kavram ve bir probleme yaklaşmanın bir yoludur.

OOP size karmaşıklığı yönetmeyi kolaylaştıracak bir tasarım uygulamak için araçlar sunar , ancak karmaşıklığınızı artıran kötü bir tasarıma kolayca sahip olabilirsiniz. Başka bir deyişle, düzgün kullanılmazsa, sorunlarınızda teknolojiye bağlı karmaşıklığa sahip olabilirsiniz.

Projenizin ne kadar başarılı olacağını belirleyecek başka birçok yönün olduğunu unutmayın (örn. Proje yönetimi stili, problem tanımı, değişiklik yönetimi, vb.). Kullandığınız teknoloji yalnızca sorunu yönetmenize ne kadar yardımcı olacağı ile ilgilidir .

Sonuçta, nesne yönelimli programlama karmaşıklığa bir çözüm olamaz ; sadece yönetmek için bir araç. (düzgün kullanılırsa)

Nesne Yönelimi (geleneksel olarak kullanıldığı gibi) birçok durumda yararlı bir araçtır, ancak karmaşıklığa yeterli bir çözüm değildir.

Özellikle, çoğu zaman " tesadüfi karmaşıklık " ekler . Örnekler, uygulama mirasını çevreleyen karmaşıklık, equals () ve hashCode () gibi birçok "standart işlevsellik" sağlama ihtiyacıdır. Stuart Halloway'ın bu konuda hoş bir sunumu: " Sadelik Kolay Değil "

Çoğu dilde nesneler, aynı anda bir dünyada giderek zayıf bir tasarım kararı gibi görünmeye başlayan çok sayıda değişebilir durumu kapsama eğilimindedir . Yine Rich Hickey'in ilginç bir videosu, nesne kimliği ve devlet arasındaki ayrımı ve ikisini birleştirmenin nasıl bir hata olabileceğini inceliyor.

Nesneye yönelik programlama bir sorunu temsil etmenin bir yoludur, başka bir şey değil, daha az bir şey. Kendi başına, diğer programlama paradigmalarından daha az karmaşık değildir. İyi tasarlanmış bir OOP sistemi karmaşıklığı yönetir ve azaltır, ancak gerekenden çok daha karmaşık ve her şeyin önüne geçen bir sistem tasarlamak da çok kolaydır.

C ++ dediği gibi, OOP kendinizi asmak için yeterli ip verir.

Bence EVET , karmaşıklığı ayrıntıları gizleyen kendi kendine yeten küçük "yapı taşlarına" dilimlemenize izin verir ve sonra bunları adım adım katman katman ihtiyacınız olan işlevselliği oluşturmak için kullanır.

Böl ve fethet.

OOP bir çözüm girişimidir.

Karmaşıklığı yönetmenin en iyi yolu soyutlamalar oluşturmaktır. Verilerimi bu koleksiyonlarda çalışan tanınabilir işlevlerle yararlı koleksiyonlara dönüştürebilirsem koleksiyonları ayrı "şeyler" olarak düşünmeye başlayabilirim. Sınıfların ve yöntemlerin temeli budur. Bu bağlamda, uygun şekilde tasarlanmış OOP karmaşıklığı yönetmeye yardımcı olabilir.

Yol boyunca bir yerlerde, birisi OOP'u kodun yeniden kullanımı sorununu çözmeye yardımcı olabileceğimize karar verdi. Yani, tekerleği neden yeniden icat ettiniz? Birisi bu sorunu çözmek için çok çalışmışsa, yaptıklarından faydalanın, özel projenizin gerektirdiği tweaks'i ekleyin ve işinizi yapın! Sizin açınızdan nispeten az çalışma ile güçlü, sofistike bir uygulama yarattınız. OO programcıları çok verimli programcılar olabilir.

Sonuç olarak, modern OO programcıları "büyücünün çırakları" haline gelir ve burada birkaç satır "yapıştırıcı" ile büyük, hantal kütüphaneleri birbirine bağlar ve işe yarayan bir şey elde ederler. Sorta. Tür. Çoğu zaman. Bu kütüphaneyi bu kütüphaneyle kullanmanın olası yan etkileri var mı? Olabilir. Ama bu kütüphanelerde bulunan kodu gerçekten incelemek için kim vakti var? Özellikle kütüphaneler gelişirken. Sonuç, bir programcının bu kütüphaneden bir avuç sınıf ve yönteme ihtiyaç duyduğu şişirilmiş uygulamalarla sonuçlandığımız, ancak uygulamanın ihtiyaç duymadıkları tüm diğer şeylerin ağırlığını taşıması gerektiğidir.

Sonuçta ihtiyacınız olandan çok daha karmaşık bir sonuç elde edersiniz.

İşlevselliği ayırmak istediğiniz karmaşıklıkla başa çıkmak için başka bir mekanizma. Tüm veri erişim işlevlerinizi tek bir yerde istiyorsunuz. Tüm kullanıcı arayüzü işlevlerinizi tek bir yerde istiyorsunuz. Tüm denetleyicilerinizi tek bir yerde istiyorsunuz. Böylece işlevselliğin farklı bölümlerini yöneten farklı sınıflar yaratırsınız. Çok uzak çok iyi. Ve bu, bir dereceye kadar ölçeklenir; veri erişimine sahip olan geliştiricileriniz bu sınıfları yazabilir, kullanıcı arabirimi çalışanlarınız kullanıcı arabirimi sınıflarını vb. yazabilir. Her şey iyi ve iyidir.

Başka biri tarafından yazılan bir şeyi korumak zorunda kalana kadar.

Evet, tüm veri erişim işlevlerinin burada bulunduğunu bilmek güzel. Ama onlara ne diyor?

Bu yöntem bu yöntemi o sınıfta çağırıyor. Ama sınıf tanımına baktığımda, bu isimle bir yöntem yok. Oh, bu miras zincirinde bir veya iki katman yukarıdan başka bir şeyden miras alınır. Bir dakika bekle; o sınıf bir arayüz uyguladı mı? Bu arayüzü kaç farklı sınıf uygular? Ve biz çalışma zamanında sınıfların "birbirine bağlamak" için bazı karmaşık çalışma zamanı sistemi (size bakıyorum, Bahar) kullanıyoruz? Bu arayüzü uygulayan HERHANGİ BİR sınıf nerede kullanılabilir?

Kesin şeyler yapan çok sayıda küçük, ayrık yöntemle sonuçlanırsınız. Ama bu, bunu başka bir sınıfta çağırıyor. Hangi başka bir sınıfta, bu denir. Hangi hala başka bir sınıfta bu denir. Ek bir sınıfta olanı çağırır. Hangi belirli bir tür sonucu döndürür. Belirli bir şey yapmak için bir yöntem çağırmanız gerekir. Hangi başka bir tür sonucu döndürür. Vb.

Bunun için bir terim var: spagetti kodu.

Sadece kodu oluşturmak için gereken çok karmaşık bir sistemle sonuçlanırsınız. Bu nedenle Visual Studio, Eclipse ve NetBeans gibi IDE'ler. Hepsi önemli bir öğrenme eğrisine sahiptir. Gerçekten de birçoğu, her biri kendi öğrenme eğrileri olan farklı gruplar tarafından geliştirilen çoklu araçları kapsülleyebilir / toplayabilir.

Bu karmaşıklığı mı yönetiyor?

Hata ayıklama kodu yazmaktan iki kat daha zordur. Bazı şeyleri hata ayıklamada iyi şanslar. Özellikle birden fazla kütüphane kullanıyorsa, bir çeşit bağımlılık enjeksiyon sistemi kullanarak çalışma zamanında "birbirine bağlanmış".

Özetle: OOP, karmaşıklığı yönetmeye yardımcı olmak için umut verici bir araç gibi görünüyor. Gerçekte, ortaya çıkan kod korkunç bir şekilde şişirilme eğilimindedir (çünkü sadece bu bağlantılı kütüphanelerden ihtiyacınız olan parçaları çıkaramazsınız) ve sadece kodda gezinmek için gelişmiş araçlara ihtiyacınız vardır. Hızla bir bakım kabusu haline gelir.

IMHO, net bir kayıp; ortadan kaldırdığından daha fazla karmaşıklık katıyor. Onsuz, son derece zor, hatta imkansız olan şeyleri yapmanıza izin verir. Ancak herhangi bir büyük proje hızla sürdürülemez bir karmaşaya dönüşür.

Nasıl çalıştığını zaten biliyorsanız ve bunu hatırlayabiliyorsanız, bunu sürdürme şansınız olabilir.

Eagleson Yasasını uygulamayı unutmayın: altı ay içinde bakmadığınız herhangi bir kod, başka biri tarafından da yazılabilir.

Bir dereceye kadar...

Neden? Çünkü çok mantıklı bir modülerliği kolaylaştırıyor. En azından büyük spagetti kod yığınları yazmanın çok cazip olduğu prosedürel programlamaya kıyasla.

Nesne yönelimli programlamanın karmaşıklığı ele almamıza yardımcı olmasının nedeni, bizi çok çeşitli yollar yerine belirli bir şekilde kod yazmaya zorlamasıdır. Görev odaklı programlama çok daha sezgiseldir, bu yüzden programlama bu şekilde başlamıştır. Nesne yönelimi, etkili bir şekilde anlamak ve kullanmak için eğitim ve uygulama gerektirir, ancak programlamayı belirli bir yolla sınırlandırarak, eğitimli olanların yazılan kodu etkili bir şekilde sürdürmelerini sağlar.

Diğer yöntemlerden daha mantıklı ya da gerçek dünya değil, sorunumuzu benzer objektiflerden odaklamanın bir yolu. Birçok teknik uzmanlık, görevlerinin karmaşıklığını ele almak için sezgisel olmayan katı bir metodoloji paradigmasını kullanır.

Karmaşıklığı ele almak için üçüncü bir yöntem, işlevsel programlama olacaktır ve gelecekte de yeni yöntemler olacaktır.

Bence bu, sürdürülebilirlik için daha çok bir çözüm, çünkü bir programcı olarak, verilerinizin olduğu yöntemlere koymanız gerekiyor, böylece uygulamanızın nesne modelini oluşturuyorsunuz.

evet, aynı zamanda kodunuzu doğal bir şekilde, özellikleri ve olası eylemleri olan nesneler olarak "görmeniz" için bir model sağlayarak karmaşıklığa bir çözümdür