Belki de nesneye yönelik paradigmayı kullanmanın en büyük vaadi kodun yeniden kullanılmasıdır. Bazıları bunun başarıldığına karşı çıkıyor. Neden elde edilmedi?
Kod OOP olarak tanımlar, projeleri daha verimli hale getirir mi?
Yoksa daha yönetilebilir mi? Yoksa bakımı daha kolay mı? Yoksa daha kaliteli?
Muhtemelen hepimiz, kodun yeniden kullanılmasının iyi bir şey olduğu konusunda hemfikiriz, ancak bu hedefe ulaşmanın birkaç yolu vardır. Soru, OOP tarafından sunulan kodun yeniden kullanılması yöntemidir. İyi bir şey miydi? Kodun yeniden kullanılmasını sağlamak için daha iyi yöntemler var mı nesne yönlendirme, alt sınıflandırma, polimorfizm vb. Hangi yollar daha iyi? Neden?
Bize deneyiminizi OOP yeniden veya diğer paradigmaların yeniden kullanımı) ile paylaşın.
Kodun yeniden kullanımı oldukça iyi bir fikirdir. Harika değil.
Yaklaşık 30 yıllık yazılım mühendisliğinden, "yeniden kullanmaya" çalıştığım bir perspektifim var.
70'lerin başında inşa ettiğim bir işletim sisteminin tasarımını yeniden kullandığımı keşfettikten sonra, 70'lerin sonunda "kodun yeniden kullanımı" yı araştırma konusu olarak araştırmaya başladım.
Kodun yeniden kullanılmasının iyi bir kısmı, bazen dürüst-tanrılı önceden var olan kodu yeniden kullanma yeteneğidir. Ama dünya dolu kod; ne istediğini nasıl bulabilirsin? İşte Yeniden Kullan Laneti :
Ben Noel Baba (ok Açık Kaynak) ve 1 milyar yazılım bileşeninden oluşan bir çantam var. Bunlardan herhangi birine sahip olabilirsiniz.
İyi şanslar seçme.
Yeniden kullanım sorununu iyi çözmek için:
Çoğunlukla yıllar boyunca keşfedilen şey, kodun yeniden kullanılabilir olması için bir tür bu amaç için tasarlanması veya çok fazla örtülü varsayım içermesidir. En başarılı kod yeniden kullanım kitaplıkları aslında oldukça küçüktür. Muhtemelen kütüphaneler ve çerçeveler "yeniden kullanılabilir" koddur ve son derece başarılıdırlar; Java ve C #, oldukça iyi bilgisayar dilleri olduğu için değil, çok iyi tasarlanmış, uygulanmış ve belgelenmiş büyük kütüphaneleri olduğu için başarılı olurlar. Ancak, insanlar kaynak koduna bakmazlar. sadece iyi belgelenmiş bir API (genellikle kullanılabilir şekilde tasarlanmış) olarak adlandırırlar.
Kodun yeniden kullanılmaması (hiçbiri OOP), sistemleri kodlama yeteneğimizde büyüklük iyileştirme emirleri sağlamaktır.
Ben anahtar kusur kod yerleşik çok fazla varsayımları olduğu için her türlü kod yeniden kullanımı temelde sınırlı olduğunu düşünüyorum. Kodu küçük yaparsanız, varsayımları en aza indirirsiniz, ancak daha sonra sıfırdan inşa etme maliyeti çok büyük değildir ve yeniden kullanım kazanımları etkili değildir. Kod parçalarını çok büyük yaparsanız, yeni bir bağlamda neredeyse işe yaramazlar. Gulliver gibi, sahile milyonlarca küçük iplerle bağlılar ve hepsini kesmeyi göze alamazsınız.
Üzerinde çalışmamız gereken şey kod oluşturmak için bilginin tekrar kullanılmasıdır . Bunu yapabilirsek, o zaman mevcut varsayımlar kümesini işleyerek ihtiyacımız olan kodu oluşturmak için bu bilgiyi uygulayabiliriz.
Bunu yapmak için, yazılım bileşenlerini karakterize etmek için hala aynı şartname kapasitesine ihtiyaç duyulmaktadır (hala ne istediğinizi söylemelisiniz!). Ama sonra bu "inşaat" bilgilerini oluşturmak istediğiniz koda şartnameye uygularsınız.
Bir topluluk olarak, henüz bu konuda çok iyi değiliz. Ama insanlar bunu her zaman yapar; neden otomatikleştiremiyoruz? Çok fazla araştırma var ve bu birçok durumda yapılabileceğini gösteriyor.
Bunun için gerekli olan önemli bir makine parçası, "bileşen tanımlarını" kabul etmek için mekanik araçlardır (bunlar sadece resmi belgelerdir ve programlama dilleri gibi ayrıştırılabilir) ve uygulayın program dönüşümleri = onlara.
Derleyiciler bunu zaten yapıyor: -} Ve ele aldıkları problem sınıfında gerçekten çok iyi.
Kod oluşturma özelliğine sahip UML modelleri bunu yapmaya yönelik bir girişimdir. Çok iyi bir girişim değil; hemen hemen çoğu UML modelinde söylediklerim "Buna benzeyen verilerim var". İşlevler dışarıda bırakılırsa gerçek bir program oluşturmak oldukça zordur.
Ben pratik program dönüşüm sistemleri, DMS adlı bir araç oluşturmaya çalışıyorum. Program dönüştürmelerini kod oluşturmak için soyut özelliklere çok değil, temizlemek için eski koda uygulayarak oldukça dikkat dağıtılmıştır. (Bunlar özette aynı problemdir!). (Bu tür araçları inşa etmek çok zaman alır; Bunu 15 yıldır yapıyorum ve bu arada yemek zorundasınız).
Ancak DMS yukarıda tarif ettiğim iki temel özelliğe sahiptir: keyfi biçimsel özellikleri işleme yeteneği ve "kod oluşturma bilgisini" dönüşüm olarak yakalama ve talep üzerine uygulama yeteneği. Ve dikkat çekici bir şekilde, bazı özel durumlarda, spesifikasyonlardan oldukça ilginç bir kod üretiyoruz; DMS, büyük ölçüde uygulanmasını oluşturmak için kendisi kullanılarak oluşturulmuştur. Bu bizim için (bilgi) yeniden kullanma vaadinin en azından bir kısmını gerçekleştirdi: son derece önemli verimlilik kazanımları. Yaklaşık 7 teknik kişiden oluşan bir ekibim var; DMS için muhtemelen "spesifikasyonlar" için 1-2 MSLOC yazdık, ancak oluşturulan kodun 10MSLOC'una sahibiz.
Özet: üretim bilgisinin yeniden kullanımı, kodun yeniden kullanımı değil.
Kod yeniden kullanımı OOP 'da elde edilir, ancak fonksiyonel programlamada da elde edilir.Her zaman bir kod bloğu alırsınız ve kodunuzun geri kalanı tarafından bu işlevselliği kullanabilmeniz için çağrılabilir hale getirirsiniz. başka bir yerde kod yeniden kullanımı.
Bu tür kodların yeniden kullanımı da kodun daha yönetilebilir olmasını sağlar, çünkü bu çağrılabilir bloğu değiştirmek çağrıldığı tüm yerleri değiştirir. Bu sonucun kaliteyi ve okunabilirliği de artırdığını söyleyebilirim.
Emin değilim OOP kod yeniden kullanımı sağlamak için sadece orada. OOP nesneleri ile etkileşim ve ayrıntılarını soyut bir yol daha bakmak veri yapısı.
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 endişe kaynağı 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 [alıntı gerekli] vurgulayarak ortak sorunları ele almak için nesne yönelimli programlama geliştirdiler. Teknoloji, her biri ("nesneler") kendi veri yapısını ("üyeler") manipüle etmek için gereken tüm bilgileri içeren kendi kendine yeterli modüllerden ("sınıflar") oluşan programlarla süreçlerden ziyade verilere odaklanır. Bu, özel olarak verilerden ziyade bir modülün işlevine odaklanan, ancak kodun yeniden kullanımı ve aynı zamanda kendi kendine yeterli yeniden kullanılabilir programlama mantığı birimleri olan ve işbirliğini mümkün kılan, yıllardır baskın olan mevcut modüler programlamanın aksine bağlı modüllerin (alt rutinler) kullanımı yoluyla. Hala devam eden bu daha geleneksel yaklaşım, veri ve davranışı ayrı ayrı ele alma eğilimindedir.
Evet ve Hayır
Kodun yeniden kullanımı, birçok farklı etkinlik için bir tümünü yakalama terimidir.
Chris ile hemfikirim, fonksiyonel programlama kodu tekrar kullanmanın iyi bir yoludur.
Birçok program, yinelenen kod yapılarına sahiptir. Bunun için OOP dünyasında bazı tasarım modelleri kullanılır, ancak bu özyinelemeli işlevler ve fonksiyonel programlama dillerinde kalıp eşleme . Bununla ilgili daha fazla bilgi için Gerçek Dünya Fonksiyonel Programlama bölümündeki ilk bölüme bakın.
Ben OOP derin miras birçok durumda yanıltıcı olabilir düşünüyorum. Bir sınıf var ve yakından ilgili yöntemlerin çoğu farklı dosyalarda uygulanır. As Joe Armstrong OOP hakkında şunları söyledi:
Nesne yönelimli dillerin sorunu, yanlarında taşıdıkları tüm bu örtük ortamlara sahip olmalarıdır. Muz istedin ama elde ettiğin şey, muzu ve tüm ormanı tutan bir gorildi.
Eşzamansız mesaj iletme da karmaşık yazılımları organize etmenin iyi bir yoludur ve bazı bilgisayar bilimcileri, nesnelerin Söyle, sorma OOP prensibi. Bunun hakkında daha fazla bilgiyi Nesneye Yönelik Programlama: Yanlış Yol? = Joe Armstrong alıntılanmıştır:
Nesne yönelimli programlamanın ne olduğunu merak etmeye başladım ve Erlang'ın nesne yönelimli olmadığını, işlevsel bir programlama dili olduğunu düşündüm. Sonra tez danışmanım "Ama yanılıyorsun, Erlang son derece nesne yönelimli" dedi. Nesneye yönelik dillerin nesneye yönelik olmadığını söyledi. Buna inanıp inanmadığımdan emin değilim, ama Erlang tek nesne yönelimli dil olabilir, çünkü nesne yönelimli programlamanın 3 ilkesi mesajına dayanıyor geçerek, nesneler arasında izolasyonunuz olduğunu ve polimorfizmi .
Olay güdümlü sistemlerde ve Erlang'da olduğu gibi zaman uyumsuz mesajlar da sistemleri ayırmak için çok iyi bir yoldur ve karmaşık sistemlerde gevşek bağlantı önemlidir. Yeterince ayrıştırılmış bir sistemle, sistemi çalışırken, belki de farklı düğümlerde geliştirebilirsiniz. Unibet bu konuda harika bir sunum yaptı: Domain Event Driven Architecture
Ancak kod yeniden kullanımı çoğu kütüphaneler ve çerçeveler kullanılarak yapıldığını düşünüyorum.
Uzun bir cevap gönderdim ama neden? Udi Dahan bunu benden daha iyi açıklıyor.
İşte yazının başlangıcı:
Bu endüstri yeniden kullanımla doludur.
Daha fazla kodu tekrar kullanırsak, her şeyin daha iyi olacağına dair bir inanç var.
Bazıları, nesne yöneliminin tümünün yeniden kullanıldığını söyleyecek kadar ileri gidiyor - kapsülleme büyük bir şey değildi. Bundan sonra bileşen yönelimi, yeniden kullanımı gerçekleştirmesi gereken şeydi. Görünüşe göre bu o kadar da iyi sonuç vermedi çünkü burada yeniden hizmet odaklı umutlarımızı sabitliyoruz.
Günün oryantasyonu ile yeniden kullanımın nasıl sağlanacağı ile ilgili tüm desen kitapları yazılmıştır. Hizmetler, kurum hizmetlerinden ve faaliyet hizmetlerinden süreç hizmetleri ve orkestrasyon hizmetlerine kadar bunu başarmaya çalışırken her şekilde sınıflandırılmıştır. Hizmet oluşturma, yeniden kullanım ve yeniden kullanılabilir hizmetler oluşturmanın anahtarı olarak kabul edilmiştir.
Kirli küçük sırta girmene izin verebilirim:
Yeniden kullanım yanlıştır
Mütevazi unix boru, kodun yeniden kullanımı için gelip giden her şeyden daha fazlasını yaptı. Nesneler, geldiklerinde kodu yapılandırmanın sezgisel bir yolu oldu ve daha sonra insanlar üzerinde her şeyi ve her şeyi ele almaya başladılar. Genelde nesneler kapsülleme içindir, kodun yeniden kullanımı için değildir, kodun yeniden kullanılması daha fazla bir şey gerektirir ve sınıf miras hiyerarşisi, bir kodun yeniden kullanım mekanizmasının gerçekte olması gerektiği için zayıf bir ikamedir.
OOP özel değildir; OOP ile veya OOP olmadan tekrar kullanılabilir kod yapabilirsiniz. Saf işlevler özellikle yeniden kullanılabilir: örneğin,
Java.lang.math.sqrt(double) bir sayı alır ve bir sayı verir. OOP yok, ama kesinlikle orada çoğu kod daha yeniden kullanılabilir.
İşlevsel bir programlama görünümünden OOP çoğunlukla durumu yönetmekle ilgilidir.
İşlevsel programlamada listeler için yüzlerce yararlı işleve kolayca sahip olabilirsiniz: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-220.127.116.11/Data-List.html .
Liste sınıfında yüzlerce yönteminiz olur mu? Genel yöntemler, küçük tutmak istediğiniz iç duruma bir arabirim olarak kabul edilir.
Ne yazık ki, çok sayıda küçük işlevi kullanmak yerine, bazı insanlar işlevselliği çoğaltır. Benim için bu OOP işlevsel programlama kadar kodun yeniden kullanımını teşvik etmez.
Benim için evet, ama her zaman değil ve başka yollar da yapılabilirdi.
Çoğu zaman soyut bir temel sınıf yaratarak ve o sınıfın somut uygulamalarını yaratarak.
Ayrıca birçok çerçeve, kodun yeniden kullanılmasını sağlamak için kalıtımdan yararlanır (Delphi, Java, .Net anında akla gelen baharlardan bazılarıdır).
Bu, birçok yardımcı program kütüphanesinin ve kod snippet'inin işi de yapamayacağı anlamına gelmez, ancak iyi tasarlanmış bir nesne hiyerarşisi hakkında hoş bir şey vardır.
Deneyimlerime göre, genel kullanım imkanları (C++ şablonları gibi) ile "yeniden kullanılabilir" kodunu kaldırarak OOP kalıtım hiyerarşileri gibi ilkeler) kullandığımdan daha başarılı oldum.
OOP etkin yeniden kullanım için çok açık.
Tekrar kullanmanın çok fazla yolu var. Her ortak sınıf şunu sorar: "benim yeni bir örneğimi yap!", her genel yöntem şöyle diyor: "beni ara!", her korunan yöntem şunu verir: = "beni geçersiz kıl!" - ve tüm bu yeniden kullanım şekilleri farklı , farklı parametreleri var, farklı görünüyorlar bağlamında, hepsinin farklı kuralları vardır, nasıl çağrılır/genişletilir/geçersiz kılınır.
[~ # ~] api [~ # ~] daha iyidir, OOP (veya olmayan) -oop) noktaları, ancak gerçek hayatta, API'ler aşırı özellikli ve sonsuza kadar büyüyen, hala çok fazla bağlantı noktası var.Ayrıca, iyi bir API hayatı kolaylaştırabilir, OOP için arayüz sağlamanın en iyi yoludur.
Datadlow paradigması bileşenler için sıkı bir arabirim sağlar, aşağıdaki türlerde bağlantı noktaları vardır:
Alan adına bağlı olarak, bazı paket türleri vardır, böylece tüketiciler ve üreticiler aynı (veya uyumlu) bağlantı noktalarına sahip olabilirler. Bunun en güzel yanı, görsel olarak yapılabilmesidir, çünkü bağlantılarda parametre veya başka ayar yoktur, gerçekten sadece bir tüketiciyi ve bir üreticiyi bağlarlar.
(Ayrıca, C++ 'da bir veri akışı sistemi yazdım. So OOP ve DF düşman değil, DF) daha üst düzey bir organizasyon yoludur.)
CommonLisp'te yeniden kullanımın birçok yolu vardır:
dinamik yazma, kodunuzun varsayılan olarak genel olması
zorunlu soyutlamalar, yani altyordamlar
birden çok miras ile nesne yönelimi ve çoklu gönderim
sözdizimi-soyutlama, yeni sözdizimsel yapıları tanımlama veya kazan plakası kodunu kısaltma yeteneği
fonksiyonel soyutlamalar, kapaklar ve yüksek dereceli fonksiyonlar
CommonLisp deneyimini diğer dillerle karşılaştırmaya çalışırsanız, kodun yeniden kullanılmasını kolaylaştıran ana özelliğin her ikisi de nesne yönelimli ve işlevsel soyutlamaların varlığı olduğunu görürsünüz. Alternatiflerden daha tamamlayıcıdırlar: bunlardan biri olmadan eksik özellikleri beceriksiz bir şekilde yeniden uygulamak zorunda kalırsınız. Örneğin, genişletilemez yöntem gönderimi almak için kapaklar ve desen eşleştirme olarak kullanılan işlev sınıflarına bakın.
OOP size diğer kodu yeniden kullanmanın yollarını verir. Hepsi bu.
İnsanların tanımladığı şekli "yeniden kullanma" diye bir şey yoktur. Yeniden kullanım, herhangi bir şeyin yanlışlıkla özelliğidir. Bunu planlamak zor. Çoğu insanın "yeniden kullanım" hakkında konuştuklarında ne anlama geldiği "kullanım" dır. Çok daha az çekici ve heyecan verici bir terim. Bir kitaplığı kullandığınızda, kitaplığı normalde amaçlandığı gibi kullanırsınız. Gerçekten çılgınca bir şey yapmadıkça kullanmıyorsunuz .
Bu anlamda, gerçek dünyada yeniden kullanım, şeyleri yeniden amaçlamakla ilgilidir. Bu koltukları burada tekrar kullanabilir ve bir yatak oluşturacak şekilde yeniden düzenleyebilirim! Çok rahat bir yatak değil, ama bunu yapabilirim. Bu onların birincil kullanımı değil. Onları orijinal uygulanabilirlik alanlarının dışında yeniden kullanıyorum. [...] Yarın, İngiltere'ye geri döneceğim. Uçağı tekrar kullanmam . Sadece amaçlandığı amaç için kullanacağım, bu konuda süslü veya heyecan verici bir şey yok.
- Kevlin Henney
Klasik OO bazen kod yeniden kullanımında yetersiz kalır, özellikle de tüm mirasları sınıflar arasında gerçek işlevselliği paylaşmanın daha iyi bir yolu olmadığı için çıldırdığınızda, bu sorun için yatay yeniden kullanım mekanizmaları oluşturulmuştur. AOP, özellikler ve greftler olarak.
AOP'yi OOP'nin eksik yarım portakalı olarak görüyorum. AOP gerçekten bilinmemektedir, ancak üretim koduna dönüştürmüştür.
Basit terimlerle açıklamaya çalışacağım: işlevselliği bir özellik adı verilen özel bir yapıya enjekte edebildiğinizi ve filtreleyebileceğinizi, bu yönlerin neyin ve nasıl etkileneceğini tanımlayan "yöntemlere" sahip olduğunu hayal edin yansıma , ancak derleme zamanında bu işleme dokuma denir.
Bir örnek, "get ile başlayan belirli sınıfların tüm yöntemleri için, program, elde edilen verileri ve alındığı zamanı bir günlük dosyasına yazacağınızı" söyleyen bir özellik olacaktır.
AOP'yi daha iyi anlamak istiyorsanız bu iki konuşmayı izleyin:
Onları açıklamak yerine, harika bir PHP RFC . Özellikler PHP btw, zaten geliyorlar) bagaj taahhüt etti.
OOP, modülerlik açısından hala önemli, benim görüşüme göre ve bugün yaygın olarak bildiğimiz gibi OOP hala eksik .
Alay ve itiraf riskiyle karşı karşıya kalacağım, sadece OOP çok yakın zamanda kullanıyorum. Bana otomatik olarak gelmiyor. Deneyimlerimin çoğu ilişkisel veritabanları içeriyor, bu yüzden bence Programlamaya gelince düşüncelerinizi yeniden sarmaktan kaçınmak için en baştan öğrenmenin daha iyi olduğu iddiaları var.Bu lüksüm yok ve kariyerimi bazı fildişi kule teorisi üzerinde hurdaya atmayı reddediyorum. diğer her şeyi, anlayacağım.
İlk başta tüm kavramın bir anlamı olmadığını düşündüm. Sadece gereksiz ve çok fazla sorun gibiydi. Biliyorum, bu çılgınca konuşma. Açıkçası, herhangi bir şeyin faydalarını takdir etmeden veya daha iyi yöntemler için reddetmeden önce belirli bir anlayış gerektirir.
Kodun yeniden kullanımı, kodu tekrarlamamaya, bunu nasıl gerçekleştireceğinize dair bir anlayışa, önceden planlamaya ihtiyaç duyar. Buna değmediği bir vakanız olduğuna karar verdiğinizde kodu tekrar kullanmaktan kaçınmalısınız mı? Ve hiçbir dil o kadar katı değildir OO başka bir sınıftan kod devralmanız gerektiğini düşündüğünde bir hata atar. En iyi ihtimalle onu uygulamaya elverişli bir ortam sağlarlar.
Ben OOP en büyük yarar kodun nasıl organize edilmesi gerektiğini genel kabul olduğunu düşünüyorum. Diğer her şey sos olduğunu. Bir programcılar ekibi tüm sınıfların nasıl yapılandırılması konusunda tam olarak aynı fikirde olmayabilir, ama kodu bulabilmelidirler.
Her yerde olabileceğini bilmek için yeterli prosedür kodu gördüm ve bazen her yerde.
Yukarıdaki yazıları okurken, birkaç açıklama:
Sorun daha ince imho:
Yani OOP kendi başına yeniden kullanılabilir kod yapma pov'dan kötü değil, ama OOP kullanarak yeniden yazılan kod türlerini kullanmak zordur.
Ayrıca, fonksiyonel programlama daha fazla yeniden kullanılabilir kod ile sonuçlanabilir. Ancak, bir son teslim tarihine ulaşılırken soyutlamaların aklı başında işlevsel kod yazmasını doğru yapmak mümkün olmayabilir. Ve "yarı-sağ" soyutlamaları ifade etmek daha kolay olacaktır OOP tarzı. Ve kodu tekrar kullanmak daha kolay - daha yüksek soyutlamalar, kod anlayışının programcıların sınırlı bilişsel kapasitesinden daha yüksek bir ön yatırım gerektireceği anlamına gelir.
Pratik bir örnek olarak: Oyun kodu çok sayıda değişebilir durum içerir, çünkü çok bulmaca/algoritmik bir oyun olmadığı sürece bir oyunu kodlamayı düşünmenin doğal yolu budur. OO. Ve elbette tekrar kullanmak zor. Ancak aynı bilgiyi içeren aynı kod, OOP olmadan tekrar kullanmak daha da zor olurd. Ve işlevsel bir stil olarak yeniden yazmanın bu kod hakkında düşünme şeklinizi, arkasındaki bilgiyi tamamen değiştirmesi gerekebilir. Evet, sonuçta Kodun arkasındaki bilgi OO to FP yeniden yaz ... ancak maliyet çok büyük olabilir ve insanlar tarafından da ödenmesi gereken maliyet türü olabilir Sonunda son derece akıllı ve iyi soyutlanmış kodu yeniden kullanmak isteyen, bu yüzden paradoksal olarak, insanlar teknik olarak daha yeniden kullanılabilir olsalar bile, kodu tekrar kullanmazlar.
... son inceliğe yol açar: kodun yeniden kullanımı People | Code arayüzüyle ilgilidir, sadece kodla ilgili değildir. OOP bu arayüze hizmet etmek için iyi bir iş çıkarıyor çünkü günümüzde yazılan birçok kod türü hakkında kaç kişinin düşündüğüyle iyi eşleşiyor. FP kod için daha iyi olabilir yeniden kullanmak, ancak imho değil insanların bugün gerçekten yazmak için gereken kod türünü kolayca yeniden kullanmak. Bu, bizim gereken kod türü olarak değişecektir değişiklikleri yaz.
Not; Ve eğer biri "OO değişebilir durumla ilgili değil, aynı zamanda OO değişmez durumla" da söylemek isterse ... Ben buna "sınıfları ad alanı olarak kullanan FP" diyorum. sizin için çalışır ve bazı dil modül sistemlerinin bazı eksikliklerini önler ve daha fazla yeniden kullanılabilir kodla sonuçlanabilir. Ancak bu OO;)
OOP Bu araçlar olmadan sahip olabileceğinizden daha fazla yerde kullanılabilen kod yazmanıza izin veren bir dizi kullanışlı araç sağlar. Herhangi bir eski nesneyi alan ve
.toString() işlevini çağıran bir
PrintIt işlevi yazarsanız, bu kodu birden fazla nesne türüyle çağırdığınızda yeniden kullanırsınız. Bu araçlarla her kod satırı daha fazlasını yapar.
Fonksiyonel programlama şu anda hipsters arasında çok sıcak. Her kod satırını daha fazlasını yapmak için size tamamen ayrı bir araç seti sağlar. Muhtemelen daha iyi değildir veya işe yarar, ancak araç kutusunda başka bir araç sağlar.
(Nesneye yönelik yeniden kullanımın ekstra seviyesi için çılgın bir fikir vardı: Fikir, tek bir
Customer sınıfı tanımlayabildiğimiz ve yazdığımız her uygulamada kullanabileceğimizdi. Burada ve orada tutkal. Bu işe yaramadı.Ancak bu OO Başarısız, hatta Yeniden Kullanım başarısız oldu.) Uygulamalarda temel kod yeniden kullanımı mümkün kıldı daha fazlasını yapan uygulamaları yazmak ve daha hızlı yazmak.)