Belki de nesne yönelimli paradigma kullanmanın en büyük vaadi kodun yeniden kullanımıdır. Bazıları bunun gerçekleştiğini tartışıyor. Neden başarıldı?

OOP tanımladığı gibi yeniden kod kullanımı, projeleri daha üretken kılar mı?

Veya daha fazla yönetilebilir? Veya bakımı kolay mı? Veya daha kaliteli?

Muhtemelen hepimiz kodun yeniden kullanılmasının iyi bir şey olduğu konusunda hemfikiriz, ancak bu amacı gerçekleştirmenin birkaç yolu var. Soru, OOP tarafından önerilen kodun yeniden kullanımı yöntemi ile ilgilidir. İyi bir şey miydi? Yeniden kullanımı başarmak için nesne yönelimi, alt sınıflandırma, polimorfizm vb. Yöntemlerden daha iyi yöntemler var mı? Hangi yollar daha iyidir? Neden ?

Bize OOP yeniden kullanımı ya da diğer paradigmaların yeniden kullanımı konusundaki deneyimlerinizi söyleyin.

Kodun tekrar kullanımı oldukça iyi bir fikir. Harika değil .

Yaklaşık 30 yıllık yazılım mühendisliği ile çizilen bir perspektife sahibim, yeniden kullanmaya çalışıyorum

80'lerin başında bir kod olarak "kodun yeniden kullanılmasını" araştırmaya başladım, 70'lerin başında inşa ettiğim bir işletim sisteminin tasarımını yeniden kullandığımı keşfettikten sonra, 70'lerin sonlarında inşa ettiğim bir işletim sistemi için kullanmaya başladım.

Kodun yeniden kullanılmasının iyi yanı, bazen tanrıya hazır önceden varolan kodu yeniden kullanma yeteneğidir. Fakat dünya kodla dolu ; ne istediğini nasıl bulabilirsin? İşte Yeniden Kullanım Laneti dediğim şey :

Ben Noel Baba'yım (Açık Kaynak) ve 1 milyar yazılım bileşeninden oluşan bir çantam var. Bunlardan herhangi birine sahip olabilirsiniz.

Seçiminde iyi şanslar.

Yeniden kullanım problemini iyi çözmek için:

• Yeniden kullanıcının bir şekilde neye ihtiyacı olduğunu belirtmesi gerekiyor (işlevsellik, performans, hedef dil, çevre varsayımları, ...)
• Bu potansiyel kriterler tarafından çeşitli şekillerde indekslenmiş bir "yeniden kullanılabilir" kod kütüphanesi bulunmalıdır.
• Aday unsurları seçmek için bazı mekanizmalar bulunmalıdır (bir milyar öğeye hepsine şahsen bakamazsınız)
• Seçilen adayların şartnameden ne kadar uzakta olduğunu belirlemek için bir yöntem olmalı.
• yeniden kullanicinin seçilen tekrar kullanilabilir kodu degistirmesine izin vermek için bazi düzenli süreçler bulunmalidir (işte OOP'un en büyük katkisi: mevcut bir bilesen / nesneyi yuvalarini geçersiz kilarak düzenleyebilirsiniz.
• Bütün bunlar açıkça sadece kodlamaktan daha ucuz olmalı

Çoğunlukla yıllar boyunca keşfedilen, kodun yeniden kullanılabilir olması için bu tür bir amaç için tasarlanmış olması gerektiği veya çok fazla örtük varsayım içerdiğidir. En başarılı kod yeniden kullanım kitaplıkları aslında oldukça küçüktü. Muhtemelen kütüphaneler ve çerçeveler "yeniden kullanılabilir" koddur ve son derece başarılıdır; Java ve C #, oldukça iyi bilgisayar dili oldukları için değil, çok iyi tasarlanmış, uygulanmış ve belgelenmiş kütüphanelere sahip oldukları için başarılı olurlar. Ancak insanlar kütüphanelerdeki kaynak koduna bakmıyor; sadece iyi belgelenmiş bir API çağırırlar (genellikle kullanılabilir şekilde tasarlanmıştır).

Kod kullanımının yapmamış olduğu (OOP da) kodlama sistemlerimizde büyük gelişme emri vermek.

Bence temel hata, herhangi bir kod yeniden kullanımının temelde sınırlı olması, çünkü kodun yerleşik olarak çok fazla varsayımlara sahip olmasıdır . Kodu küçültürseniz, varsayımları en aza indirirsiniz, ancak daha sonra sıfırdan oluşturma maliyeti çok büyük değildir ve yeniden kazanımlar etkili değildir. Kod parçalarını büyük yaparsanız, yeni bir bağlamda oldukça yararsızdırlar. Gulliver gibi, onlar da bir milyon küçük iple sahile bağlanırlar ve hepsini kesmeyi göze alamazsınız.

Üzerinde çalışmamız gereken kod oluşturmak için bilginin tekrar kullanılmasıdır . Bunu yapabilirsek, o zaman bu varsayımları kullanarak, ihtiyaç duyduğumuz kodu oluşturmak için bu bilgiyi uygulayabiliriz.

Bunu yapmak için, bir yazılım bileşenlerini karakterize etmek için hala aynı özellik özelliğine ihtiyaç duyulmaktadır (hala ne istediğinizi söylemek zorundasınız!). Ama sonra bu "inşaat" bilgisini istediğiniz kodu üretmek için spesifikasyonlara uygularsınız .

Bir topluluk olarak, henüz bu konuda pek iyi değiliz. Ancak insanlar her zaman yaparlar; neden otomatikleştiremiyoruz? Çok fazla araştırma var ve bu birçok durumda yapılabileceğini gösteriyor.

Bunun için gerekli olan bir anahtar makine parçası "bileşen tanımlarını" (bunlar sadece resmi belgelerdir ve programlama dilleri gibi ayrıştırılabilir) kabul etmek ve program dönüştürmelerini uygulamak için kullanılan mekanik araçlardır .

Derleyiciler zaten bunu yapıyor: -} Ve mücadele ettikleri problem sınıfında gerçekten iyiler.

Kod oluşturma özellikli UML modelleri bunu yapmayı denemektedir. Çok iyi bir girişim değil; çoğu UML modelinde söylenenler "buna benzeyen verilerim var" dır. İşlevsellik dışlanmışsa gerçek bir program oluşturmak oldukça zor.

DMS adlı bir araç olan pratik program dönüştürme sistemleri kurmaya çalışıyorum . Program dönüşümlerini kod üretme özniteliklerine çok değil, temizliği yerine eski kodlara uygulayarak oldukça dikkatiniz dağıldı. (Bunlar soyutta aynı problem!). (Bu tür araçlar inşa etmek çok zaman alıyor; 15 yıldır bunu yapıyorum ve bu arada yemek yemeniz gerekiyor).

Ancak, DMS yukarıda tanımladığım iki temel özelliğe sahiptir: isteğe bağlı resmi spesifikasyonları 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, özelliklerden oldukça ilginç bir kod üretiyoruz; DMS, uygulamasını oluşturmak için büyük ölçüde kendisini kullanarak inşa edilmiştir. Bu, bizim için en azından bir miktar (bilgi) tekrar kullanım vaadinin gerçekleşmesini sağlamıştır: son derece önemli verimlilik kazanımları. Yaklaşık 7 teknik kişiden oluşan bir ekibim var; Biz muhtemelen DMS için "şartname" nin 1-2 MSLOC yazdık, ancak 10MSLOC tarafından oluşturulan bir kodumuz var.

Özet: üretim bilgisinin tekrar kullanılması kazancın, kodun tekrar kullanılması değil .

OOP'da kod yeniden kullanımı elde edilir, ancak fonksiyonel programlamada da elde edilir. Herhangi bir zamanda bir kod bloğu alıp kodunuzun geri kalanıyla çağrılabilir hale getirin, böylece bu işlevi başka bir yerde kullanabilirsiniz, kod tekrar kullanmaktır.

Bu kod yeniden kullanımı aynı zamanda kodu daha kolay yönetilebilir kılar, çünkü bu bir çağrılabilir bloğu değiştirmek, çağrıldığı her yeri değiştirir. Bu sonucun kaliteyi ve okunabilirliği arttırdığını söyleyebilirim.

OOP kod yeniden kullanımı sağlamak için sadece orada olduğundan emin değilim. OOP'a nesnelerle etkileşime girmenin ve veri yapısının ayrıntılarını soyutlamanın bir yolu olarak bakıyorum.

Wikpedia’dan:

Nesneye yönelik programlama, 1960'larda izlenebilecek köklere sahiptir. Donanım ve yazılım gittikçe daha karmaşık hale geldikçe, yönetilebilirlik çoğu zaman bir endişe haline geldi. Araştırmacılar, yazılım kalitesini korumanın yollarını araştırdılar ve kısmen, tekrar kullanılabilir programlama mantığı birimlerini vurgulamak suretiyle ortak problemleri ele almak için kısmen nesne yönelimli programlama geliştirdiler. Teknoloji, süreçler yerine verilere odaklanır, her biri ("nesneler") kendi veri yapısını ("üyeler") işlemek için gereken tüm bilgileri içeren kendi kendine yeten modüllerden ("sınıflar") oluşan programlarla çalışır. Bu, özellikle verilerden ziyade, bir modülün işlevine odaklanan, özellikle veri yerine, aynı zamanda kodun yeniden kullanımı için eşit olarak sağlanan mevcut modüler programlamanın aksine. ve bağlantılı modüllerin (alt yordamlar) kullanılmasıyla işbirliğini mümkün kılan, kendi kendine yeterli yeniden kullanılabilir programlama mantığı birimleri. Halen devam eden bu daha geleneksel yaklaşım, verileri ve davranışları ayrı ayrı dikkate alma eğilimindedir.

Evet ve hayır

Kodun yeniden kullanımı, pek çok farklı etkinlik için tümünü kapsayan bir terimdir.

1. Tek bir projede tekrar kod kullanın. OO bunun için mükemmel bir şekilde uygun, iyi tasarlanmış bir uygulama modellenen dünyanın ilişkilerini yakından eşlemiş olacak, böylece tekrarlanan kodu mümkün olduğunca ortadan kaldıracak ve tavsiye edilebilir. Ancak, OO öncesi teknolojilerin aynı şeyi başarabildiğini iddia edebilirsiniz, bu doğru, ancak OO birçok yönden daha uygun.
2. Üçüncü taraf kütüphaneleri Bu, OO ile veya OO olmadan eşit derecede iyi çalışıyor gibi görünmektedir.
3. Çapraz amaçlı kod yeniden kullanımı OO'nun en büyük yeniden kod kullanım vaadi, bir kez bir uygulama için yazılan kodun daha sonra özel olarak tasarlanmadığı başka biri için tekrar kullanılabileceği yönündeydi. Bu, OO nosyonu yüksek yönetim ofislerinin kapılarından süzüldüğünde ve OO bunu başaramadığında öfkelenmişti. Bu amacın, OO tasarımının (ve muhtemelen tüm prosedür kodunun, ancak bu benim teorimin) çok önemli bir yönü olduğu ve bakım felaketlerinde sona eren kodu yeniden yerleştirme girişimleri olduğu ortaya çıktı. (Eski bir çerçevenin bilinen zıt biçimleri hiç kimsenin değişmesine cesaret edemez ve arkadaşı, her biri için biraz farklı çerçeveler genellikle buradan kaynaklanır.)

Uzun bir cevap gönderirdim ama neden? Udi Dahan benden çok daha iyi açıklıyor.

http://www.udidahan.com/2009/06/07/the-fallacy-of-reuse/

İşte yazının başlangıcı:

Bu endüstri yeniden kullanımı ile meşgul.

Daha fazla kodu tekrar kullanırsak, her şeyin daha iyi olacağı inancı var.

Hatta bazıları, nesne yöneliminin tümünün yeniden kullanıldığını söyleyecek kadar ileri gitti - öyle değildi, enkapsülasyon büyük şeydi. Bundan sonra, bileşen yönelimi, yeniden kullanımı gerçekleştirmesi beklenen şeydi. Görünüşe göre bu da pek iyi sonuçlanmadı, çünkü biz şimdi yeniden hizmet umutlarımızı hizmet odaklı hale getiriyoruz.

Tüm desen kitapları, günün yönlendirmesiyle yeniden kullanımın nasıl sağlanacağı üzerine yazılmıştır. Hizmetler, varlık hizmetleri ve etkinlik hizmetlerinden, süreç hizmetleri ve düzenleme hizmetlerine kadar, bunu başarmaya çalışırken her şekilde sınıflandırılmıştır. Hizmetleri oluşturmak, yeniden kullanmanın ve yeniden kullanılabilir hizmetleri oluşturmanın anahtarı olarak kabul edilmiştir.

Kirli küçük sırrın içinde olmana izin verebilirim:

Yeniden kullanmak yanlıştır

Chris ile aynı fikirdeyim, işlevsel programlama kodu yeniden kullanmak için iyi bir yoldur.

Birçok programda tekrar eden kod yapıları vardır. Bunun için OOP dünyasında bazı tasarım kalıpları kullanılır, ancak bu fonksiyonel programlama dillerinde özyinelemeli fonksiyonlar ve kalıp eşleştirme ile sağlanabilir . Bu konuda daha fazla bilgi için Gerçek Dünya Fonksiyonel Programlama'daki ilk bölüme bakınız .

OOP'deki derin kalıtımın birçok durumda yanıltıcı olabileceğini düşünüyorum. Bir sınıfınız var ve yakından ilişkili yöntemlerin çoğu farklı dosyalarda uygulanıyor. Joe Armstrong'un OOP hakkında söylediği gibi :

Nesne yönelimli dillerle ilgili sorun, kendileriyle birlikte taşıdıkları tüm bu örtülü ortamlara sahip olmalarıdır. Bir muz istemiştin, fakat elindeki muz ve tüm ormanı tutan bir gorildi.

Yüksek dereceden fonksiyonlar o yeniden örneğin kod geldiğinde de çok yararlıdır mapve foldrbu Google'ın temelidir MapReduce .

Eşzamansız mesaj iletimi aynı zamanda karmaşık yazılım düzenlemenin iyi bir yoludur ve bazı bilgisayar bilimcileri, nesnelerin Tell ile olduğu gibi eşzamansız olarak birbirleriyle iletişim kurduğu varsayıldığını söyler , OOP ilkesini sormazlar . Nesneye Yönelik Programlama: Yanlış Yol'da bu konuda daha fazla bilgi edinin. idi Joe Armstrong alıntı:

Nesneye yönelik programlamanın ne olduğunu merak etmeye başladım ve Erlang'ın nesneye yönelik olmadığını, işlevsel bir programlama dili olduğunu düşündüm. Sonra tez danışmanım "Ama sen hatalısın, Erlang fazlasıyla nesne yönelimli" dedi. Nesne yönelimli dillerin nesne yönelimli olmadığını söyledi. Buna inanıp inanmadığımdan emin değilim, ancak Erlang tek nesne yönelimli dil olabilir, çünkü nesne yönelimli programlamanın 3 ilkesi mesaj iletmeye dayanıyor, nesneler arasında yalıtma olduğunu gösteriyor. sahip biçimlilik .

Olay güdümlü sistemlerde ve Erlang'da olduğu gibi geçen zaman uyumsuz mesaj, sistemleri ayırmanın çok iyi bir yoludur ve karmaşık bağlantılarda gevşek bağlantı önemlidir. Yeterince ayrıştırılmış bir sistemle, çalıştığı sırada sistemi, belki de farklı düğümlerde geliştirebilirsiniz. Unibet bu konuda harika bir sunum yaptı: Domain Event Driven Architecture

Ancak, kod kullanımının çoğunun kitaplıklar ve çerçeveler kullanılarak yapıldığını düşünüyorum.

Mütevazı unix boru kod yeniden kullanımı için gelip giden her şeyden daha fazlasını yaptı. Nesneler, ortaya çıktıklarında kodu yapılandırmanın sezgisel bir yoluydu ve daha sonra insanlar her şeyi ve her şeyi üzerine yapıştırmaya başladılar. Genel olarak nesneler kapsülleme içindir ve kodun yeniden kullanımı için değildir, kodun yeniden kullanımı daha fazla şey gerektirir ve sınıf mirası hiyerarşisi, bir kod yeniden kullanma mekanizmasının gerçekte ne olması gerektiğinin kötü bir alternatifidir.

OOP özel değildir; yeniden kullanılabilir kodu OOP ile veya OOP olmadan yapabilirsiniz. Saf fonksiyonlar özellikle yeniden kullanılabilir : örneğin, java.lang.math.sqrt(double)bir sayı alır ve bir sayı verir. OOP yok, ancak kesinlikle çoğu koddan daha fazla tekrar kullanılabilir.

İşlevsel bir programlama bakış açısından OOP çoğunlukla durumu yönetmekle ilgilidir.

Fonksiyonel programlamada listeler için yüzlerce yararlı fonksiyona kolayca sahip olabilirsiniz: http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/Data-List.html .

Liste sınıfında yüzlerce yöntem var mıydı? Genel yöntemler, küçük tutmak istediğiniz iç duruma bir arayüz olarak kabul edilir.

Ne yazık ki, çok sayıda küçük işlev kullanmak yerine (yeniden) yerine, bazı kişiler işlevselliği çoğaltır. Bana göre, OOP , işlevsel programlama kadar kodun tekrar kullanılmasını teşvik etmiyor.

Benim için, evet, ama her zaman değil ve başka yollarla da yapılabilirdi.

Çoğu zaman soyut bir temel sınıf oluşturarak 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 mirastan yararlanır (Delphi, Java, .Net, akla ilk gelenler arasındadır).

Bu, birçok yardımcı program kütüphanesinin ve kod snippet'inin de işi yapamayacağı anlamına gelmez, ancak iyi tasarlanmış bir nesne hiyerarşisi hakkında hoş bir şey vardır.

Tecrübelerime göre, genel programlama olanakları (C ++ şablonları gibi) yoluyla "yeniden kullanılabilir" koddan yararlanma, kalıtım hiyerarşileri gibi OOP ilkelerini kullanmaya göre daha fazla başarılı oldum.

OOP, etkili yeniden kullanım için çok açık.

Yeniden kullanmanın çok fazla yolu var. Her kamu sınıfı şunu soruyor: "yeni bir örnek yap!" Her ortak yöntem şöyle der: "beni ara!" korunan her yöntem: "beni geçersiz kıl!" - ve tüm bu yeniden kullanım şekilleri farklı , farklı parametrelere sahipler, farklı bağlamlarda görünüyorlar, hepsinin farklı kuralları var, nasıl çağırılır / genişletilir / geçersiz kılınır.

API daha iyidir, OOP (ya da oop olmayan) noktalarının katı bir alt kümesidir, ancak gerçek hayatta API'ler fazla etkilenir ve sonsuza dek büyüyor, hala çok fazla bağlantı noktası var. Ayrıca, iyi bir API hayatı kolaylaştırabilir, OOP için arayüz sağlamak için en iyi yoldur.

Datadlow paradigması , bileşenler için katı bir arayüz sağlar, aşağıdaki tür bağlantı noktalarına sahiptir:

• tüketiciler (girdiler) ve
• üreticiler (çıktılar).

Etki alanına bağlı olarak, bazı paket türleri vardır, bu nedenle tüketiciler ve üreticiler aynı (veya uyumlu) bağlantı noktalarına sahip olabilirler. Bunun en güzel kısmı, görsel olarak yapılabilmesidir, çünkü bağlantılarda herhangi bir parametre ya da başka bir ayar yoktur, onlar gerçekten bir tüketiciyi ve bir üreticiyi birbirine bağlar.

Biraz net değildim, StackOverflow üzerindeki "dataflow" etiketine ya da Wikipedia "datafow programlama" ya da Wikipedia "akış tabanlı programlama" ' ya bakabilirsiniz .

(Ayrıca, C ++ dilinde bir dataflow sistemi yazdım. OOP ve DF düşman değildir, DF daha üst düzey bir organizasyon yoludur.)

CommonLisp'te yeniden kullanıma ulaşmak için birçok yol vardır:

• dinamik yazma, kodunuzun varsayılan olarak genel olması

• Emir soyutlamaları, yani alt yordamlar

• Nesne yönelimi, çoklu kalıtım ve çoklu gönderim

• sözdizimi soyutlama, yeni sözdizimsel yapıları tanımlama veya kazan-plaka kodunu kısaltma becerisi

• fonksiyonel soyutlamalar, kapanışlar ve üst düzey fonksiyonlar

CommonLisp deneyimini diğer dillerle karşılaştırmaya çalışırsanız, kod kullanımını yeniden kolaylaştıran ana özelliğin hem nesne yönelimli hem de işlevsel soyutlamaların varlığı olduğunu görürsünüz . Alternatiflerden daha tamamlayıcılar: onlardan biri olmadan eksik özellikleri sakar biçimde yeniden uygulamak zorunda kalırsınız. Örneğin, genişletilebilir olmayan yöntem gönderimi elde etmek için kapaklar ve desen eşleştirme olarak kullanılan functor sınıflarına bakın.

Gerçekten insanların yeniden tanımladığı şekilde "yeniden kullanma" diye bir şey yoktur. Yeniden kullanmak her şeyin tesadüfi bir özelliğidir. Planlaması zor. Çoğu insan "yeniden kullanım" hakkında konuştukları zaman "kullanım" dır. Çok daha az çekici ve heyecan verici bir terim. Bir kütüphane kullanırken, normalde ne için amaçlandığı için kullanıyorsunuz. Gerçekten çılgınca bir şey yapmazsan , onu tekrar kullanmazsın.

Bu anlamda, gerçek dünyada tekrar kullanmak, şeyleri tekrar ele geçirmekle ilgilidir. Bu koltukları burada yeniden kullanabilir ve onları bir yatak oluşturacak şekilde düzenleyebilirim! Çok rahat bir yatak değil ama bunu yapabilirim. Bu birincil kullanım değil. Onları orijinal uygulanabilirlik alanı dışında kullanıyorum. [...] Yarın İngiltere'ye döneceğim. Ben olacak değil uçağı yeniden kullanın. Sadece amaçlandığı amaç için kullanacağım, bunun için süslü ya da heyecan verici bir şey yok.

- Kevlin Henney

Alay ve itiraf riski alacağım, çok yakın bir zamanda OOP kullanıyorum. Bana otomatik olarak gelmiyor. Tecrübelerimin çoğu ilişkisel veritabanları içeriyor, bu yüzden tablolarda ve katılımda düşünüyorum. Programlamaya gelince düşüncenizi yeniden canlandırmak zorunda kalmayan, en başından öğrenmenin daha iyi olduğu iddiaları var. O kadar lüksüm yok ve kariyerimi fildişi kule teorisi yüzünden mahvetmeyi reddediyorum. Her şey gibi, ben de çözeceğim.

İlk başta tüm konseptin bir anlam ifade etmediğini düşündüm. Sadece gereksiz ve çok fazla sorun gibi görünüyordu. Biliyorum, bu delice bir konuşma. Açıkçası, herhangi bir şeyin faydalarını takdir etmeden veya daha iyi yöntemler için görevden almadan önce belli bir anlayış seviyesi gerekir.

Kodun yeniden kullanımı, kodu tekrar etmemeye isteklidir, bunu nasıl başaracağına dair bir anlayış, önceden planlama yapmak ister. Buna değmeyecek bir durumun olduğuna karar verdiğinde kodu tekrar kullanmaktan kaçınmalı mısın? Ve hiçbir dil o kadar kesin değildir ki, başka bir sınıftan kodu almanız gerektiğini düşündüğü zaman hata verecektir. En iyi ihtimalle onu uygulamaya elverişli bir ortam sağlarlar.

Bence OOP'nin en büyük yararı, kodun nasıl düzenlenmesi gerektiği genel kabulüdür. Geri kalan her şey sos. Bir programcı ekibi, tüm sınıfların nasıl yapılandırılması gerektiği konusunda tam olarak anlaşmayabilir, ancak kodu bulabilmeleri gerekir.

Her yerde olabileceğini bilmek için yeterli prosedür kodu gördüm ve bazen her yerde.

OOP size kodu tekrar kullanmanız için daha fazla yol sunar. Hepsi bu.

Yatay Yeniden Kullanım: yönler, özellikler, greftler

Klasik OO bazen sınıflar arasında gerçek işlevselliği paylaşmanın daha iyi bir yolunun bulunmaması nedeniyle tüm kalıtım çılgına döndüğünüzde, kod kullanımında bazen yetersiz kalır. Bu problem için AOP, özellikler ve greftler gibi yatay yeniden kullanım mekanizmaları yaratılmıştır.

Boy Yönelimli Programlama

AOP'u, OOP'un eksik yarı portakalı olarak görüyorum. AOP gerçekte o kadar bilinmemektedir, ancak üretim koduna getirmiştir.

Basit terimlerle açıklamaya çalışacağım: İşlevselliği bir yön olarak adlandırılan özel bir yapıya enjekte edip filtreleyebileceğinizi hayal edin, bu yönlerin yansımadan neyin ve nasıl etkileneceğini tanımlayan " derleme zamanı " yöntemleri vardır. , bu sürece dokuma denir .

Bir örnek, "get ile başlayan tüm belirli sınıfların tüm yöntemleri için, bir günlük dosyasına, elde edilen verileri ve alınma zamanlarını yazacağınızı" söyleyen bir özellik olabilir.

AOP'yi daha iyi anlamak istiyorsanız, bu iki konuşmayı izleyin:

• Uygulama Saldırılarını Önlemek için Açı Yönelimli Programlamanın Kullanılması 1/6
• Boy Yönelimli Programlama: Gregor Kiczales ( AOP'ın arkasındaki ana adam) tarafından Modülerlikte Radikal Araştırma

Özellikler ve Greftler

Özellikler , OOP'yi tamamlayan yeniden kullanılabilir kodu tanımlamak için başka bir yapıdır, karışımlara benzer , ancak daha temizdir.

Onları açıklamak yerine , her ikisini de açıklayan harika bir PHP RFC'si var . Özellikler PHP btw'ye geliyor, onlar zaten bagaja bağlı.

Özetle

OOP modülerliğin anahtarıdır, yine de bence ve bugün bildiğimiz gibi OOP hala eksik .

OOP Kullanabileceğiniz kodlardan daha fazla yerde kullanabileceğiniz kodları yazmanıza olanak sağlayan bir dizi yararlı araç sağlar. Herhangi PrintItbir eski nesneyi alan ve .toString()onu çağıran bir işlev yazarsanız, bu kodu birden fazla nesneyle çağırır çağırmaz yeniden kullanmış olacaksınız. Bu araçlarla her kod satırı daha fazlasını yapar.

Fonksiyonel programlama şu anda hipsterler arasında çok sıcak. Her kod satırını daha fazlasını yapmak için size ayrı bir araç seti sağlar. Muhtemelen daha iyi ya da işe yaramaz, ancak araç kutusunda başka bir araç sağlar.

(Nesne yönelimli yeniden kullanımın tüm ekstra seviyesi için çılgınca bir fikir vardı: Fikir, tek bir Customersınıfı tanımlayıp yazdığımız her uygulamada kullanabilmemizdi. Sonra uygulamalar burada biraz tutkal olurdu. işe yaramadı ama bu, OO'nun Başarısız olduğu, hatta Yeniden Kullanmanın başarısız olduğu anlamına gelmiyor. Uygulamalar içinde tekrar kullanılan temel kod türleri, daha fazlasını yapan uygulamalar yazmayı ve daha hızlı yazmayı mümkün kıldı.)

Yukarıdaki yazıların okunması, birkaç açıklama:

• Pek çok kişi, OOP'da kodun yeniden kullanılmasının miras anlamına geldiğini düşünüyor. Katılmıyorum. Arayüzler ve sözleşmeler, OOP sistemlerinde yeniden kullanımı kodlamanın temelini oluşturur. OOP, bir bileşen teknolojisi yaratmada gri kutu girişimidir.
• Etki alanına özgü ve yeniden kullanım konusu olarak genel "çerçeveler" arasındaki fark beni çok soyut olarak görüyor. İşler hakkındaki görüşüme göre, bir bileşen (özlü, asgari ve yeniden kullanılabilir bir arayüz sözleşmesi ve arkasındaki uygulama) ancak ele aldığı sorun iyi anlaşılırsa yapılabilir. Etki alanı dışındaki uzmanların, etki alanı hakkında daha az bilgi sahibi olarak işlerini yapmalarına olanak sağlayan, alana özgü bir bileşen (yeniden) yararlı bir bileşendir. Kullanıcıların arayüzü daha iyi anlamaları gerekir, bu yüzden sorunlu alanın karmaşıklığı daha azdır.
• Yeniden kullanım seviyeleri sıklıkla unutulur: Fikir yeniden kullanımı, Şartname yeniden kullanımı, Mimari / Tasarım yeniden kullanımı, Arayüz yeniden kullanımı, Test çantası yeniden kullanımı. Kod yeniden kullanımı her zaman uygun değildir. Ancak yeni, benzer bir ürünle başa çıkmak için sık sık belirli bir mimariye bağlı kalmak büyük bir zaman tasarrufu sağlar.
• Gözlerimdeki OOP Tasarım desenleri (Gamma ve diğerleri), daha büyük ölçekte kod kullanımı bağlamında anlamlı olmak yerine, taktiksel uygulama teknikleri üzerinde yoğunlaştı. OOP öğeleriyle birlikte bir uygulama yazmaya yardımcı olurlar, ancak ben bunları tek bir uygulamanın ötesinde "yeniden kullanım kodu" sorusuna bir çözüm olarak görmezdim.
• Belki de adil değil: 20 yıllık C / C ++ / C # deneyimi ve 6 aylık fonksiyonel programlama (F #). Yeniden kullanımı mümkün kılmanın temel unsurlarından biri: İnsanların kolayca "arayüzü" bulması, araştırması, anlaması ve kullanması gerekir. Saf işlevsel programlama, yapıyı, yeniden kullanım için adayları veya nerede başladığı ve nerede bittiği konusunda kolay olmamı sağlıyor. Öyle övülen “sözdizimsel şeker” genellikle gözlerimdeki tuz olup ne olduğunu kolayca görmemi engelliyor. Bu nedenle, göremediğim bile gizli yan etkilere sahip olan bir işlevselliği (işlev nedir?) Tekrar denemeyi daha az deneyecektim (tembel değerlendirme, monadlar, ...). Beni yanlış anlamayın, işlevsel programlamanın çok güzel yanları var, ancak gördüğüm tüm güçlü yanları iyi bir şüphe ile ilan ediyorum.
• Spesifikasyon, Tasarım, Uygulama birleştiler, ancak “aynı şey” hakkında kolayca gezilebilecek görüşler değil. Gelecekteki üretkenlik artışı için yeni bir programlama paradigmasından çok daha hayati olan, boşluğu kapatmak, bu görüşler arasındaki karşılıklı yararları artırmak (otomatik muhakeme, izlenebilirlik). Formelize spesifikasyon dilleri, standartlaştırılmış test notasyonları (örn. Ttcn3) ve yorum atlatma yapmadan spesifikasyonlara karşı arayüzlerin ve sözleşmelerin doğrulanmasını destekleyen programlama dilleri en acil olarak ihtiyaç duyduğumuz şey olabilir.

Sorun şu ki daha ince:

1. OOP, değişken durumlu kod yapılandırmak için harika bir yöntemdir . Devleti nesnelerin içine alarak, zorunlu durum kodu daha anlaşılır hale gelir, çünkü örneğin bir durum parçası bir sınıfın özel alanları olarak ifade edilirse, en azından bu özel durum parçasının sadece bu yöntemlerle değiştirilebileceğini bilirsiniz. sınıf. (Ve kalıtım kötüye kullanımıyla bu kazancı kolayca kırabilirsin, btw.) Bu şimdi yeterli, ama buna sahip olmamaktan daha iyi .
2. değişken durumlu kodun doğal olarak yeniden kullanılması zordur . Değişmez veri yapılarını kullanarak koddan daha zor.

Bu nedenle, OOP kendi içinde yeniden kullanılabilir kod üretmekten kötü değildir , ancak OOP kullanılarak yazılan kod türlerini yeniden kullanmak doğal olarak zordur .

Ayrıca, işlevsel programlama daha fazla yeniden kullanılabilir kodla sonuçlanabilir . Ancak, bir son teslim tarihine uygun toplantılarda aklı başında işlevsel kod yazma hakkının alınması uygun olmayabilir. Ve "yarı sağ" soyutlamalar, OOP stilini ifade etmek için daha kolay olacaktır. Ve kodun yeniden kullanımı daha kolay sonuçlanma eğiliminde olmayacaktır - daha yüksek soyutlamalar seviyesi, kod anlayışının programcıların sınırlı bilişsel kapasitelerinden daha yüksek bir ön yatırım gerektireceği anlamına gelir.

Pratik bir örnek olarak: Oyun kodu çok fazla değişken durum içerir, çünkü bu bir oyunu kodlamayı düşünmenin doğal yoludur, çok bulmaca / algoritmik bir durum olmadığı sürece, bu nedenle açıkça OO kullanılarak yapılandırılmış olarak sona erer. Ve tabii ki yeniden kullanmak zor. Ancak aynı bilgiyi içeren aynı kod, OOP olmadan tekrar kullanmak daha zor olacaktır . Ve işlevsel bir stil olarak yeniden yazmanın , bu kod hakkındaki düşüncelerinizi ve arkasındaki bilgileri tamamen değiştirmesi gerekebilir . Evet, kodun arkasındaki sonuç bilgisi OO - FP yeniden yazdıktan sonra çok daha net olurdu ... ama maliyeti çok büyük olabilir veSon derece akıllı ve iyi hazırlanmış bir kodu tekrar kullanmak isteyenler tarafından ödenmesi gereken maliyet türü , bu yüzden paradoksal olarak, insanlar teknik olarak daha fazla tekrarlanabilir olsalar bile, kodu tekrar kullanmayacaklar.

... son inceliklere yol açar: kodun yeniden kullanımı sadece kodla ilgili değil, People | Code arayüzü ile ilgilidir. OOP, bu arayüze hizmet etmek için iyi bir iş yapıyor çünkü günümüzde yazılan birçok kod hakkında kaç kişinin düşündüğünü iyi planlıyor. FP, kodun yeniden kullanımı için daha iyi olabilir, ancak bugünlerde insanların gerçekten yazması gereken kod türünü kolayca yeniden kullanmak için değil . Bu, değişiklikler yazmamız gereken kod türü olarak değişecektir.

Not: Eğer “OO değişmez durumla ilgili değilse, değişmez durumlu OO'ya da sahip olabilirsiniz” demek isterse “Ben buna“ sınıfları ad alanları olarak kullanarak FP ”derim. Sizin için çalıştığında ve bazı dilin modül sistemlerinde bazı eksikliklerden kaçınır ve daha fazla yeniden kullanılabilir kodla sonuçlanabilir. Ama bu OO değildir;)