Dörtlü Çete “Desen Uzayı” nı iyice araştırdı mı?

Dörtlü Çete (GoF) tasarım kalıplarını ilk öğrendiğimden beri , en az 10 yıl önce, bu 23 kalıptan sadece Desen Alanı olarak adlandırmayı sevdiğimden daha büyük bir şeyin küçük bir örneği olması gerektiği izlenimini edindim . Bu varsayımsal Desen Alanı , yaygın nesne yönelimli yazılım tasarımı sorunları için önerilen tüm çözümlerden (bilinen veya bilinmeyen) oluşur.

Bu yüzden bilinen ve belgelenen tasarım modellerinin sayısının önemli ölçüde artmasını bekledim.

Bu yaşanmadı. GoF kitabının yayınlanmasından 20 yıl sonra, Wikipedia makalesinde, çoğu orijinallerinden daha az popüler olan sadece 12 ek örnek listelenmiştir. (Eşzamanlılık kalıplarını buraya dahil etmedim çünkü belirli bir konuyu kapsıyorlar.)

Sebepler neler?

• GoF kalıpları dizileri aslında sandığımdan daha mı kapsamlı?

• Yeni modeller bulma konusundaki ilgi, belki de yazılım tasarımında o kadar da faydalı olmadıkları için azaldı mı?

• Başka bir şey?

Kitap çıktığında, birçok insan bu şekilde düşündü ve “desen kütüphaneleri” ve hatta “desen toplulukları” oluşturmak için birçok çaba vardı. Bunlardan bazılarını hala bulabilirsiniz:

• "Desen Topluluğu" , WikiWikiWeb
• "New York Şehri Tasarım Desenleri Çalışma Grubu" , Endüstriyel Mantık
• "Desen Kataloğu" , Hillside Grubu

Ama sonra...

Yeni modeller bulma konusundaki ilgi, belki de yazılım tasarımında o kadar da kullanışlı olmadıkları için azaldı mı?

Bu, çok fazla. Tasarım kalıplarının amacı, geliştiriciler arasındaki iletişimi geliştirmektir, ancak daha fazla kalıp eklemeye çalışırsanız, hızlı bir şekilde insanların onları hatırlayamayacağı, onları yanlış anlayacağı veya tam olarak neye benzemeleri gerektiği konusunda anlaşamadığınız bir noktaya ulaşırsınız; aslında, geliştirilmiş değil. Bu zaten GoF kalıplarında çok olur.

Şahsen, daha da ileri gideceğim: Yazılım tasarımı, özellikle iyi yazılım tasarımı, kalıplarda, özellikle insanların gerçekten hatırlayabileceği az sayıdaki kalıpta anlamlı bir şekilde yakalanmayacak kadar çeşitlidir - ve insanlar için çok soyut Bir avuçtan çok daha fazlasını hatırlıyorum. Yani fazla yardımcı olmuyorlar.

Ve çok fazla insan kavramı ile aşina ve her yerde desenleri uygulamaya çalışın - genellikle, sonuç kodunda tüm (tamamen anlamsız) Singletons ve Soyut Fabrikalar arasında gerçek tasarım bulamıyor.

Bu 23 modelin, sadece Desen Alanı olarak adlandırdığım daha büyük bir şeyin küçük bir örneği olması gerektiği izlenimini edindim.

Bu, her yerde neofit programcıları tarafından yayılan ve yalnızca bir program yazmayı bir araya getirerek bir program yazabileceklerini düşünen programcıların yaydığı korkunç varsayımdır. Bu şekilde çalışmıyor. Böyle bir "desen alanı" varsa, boyutunun etkili bir şekilde sonsuz olduğunu varsayabilirsiniz.

Tasarım kalıplarının (GoF anlamında) bir amacı vardır: kullandığınız programlama dilindeki eksiklikleri gidermek.

Tasarım desenleri ne evrensel ne de kapsamlı değildir. Farklı, daha etkileyici bir programlama diline geçerseniz, GoF kitabındaki kalıpların çoğu hem gereksiz hem de istenmeyen hale gelir.

Burada ortaya çıkan üç faktör olduğunu düşünüyorum.

Kritik Kütle Eksikliği

İlk olarak, bir model, temel olarak, işlevselliğin belirli bir "öbeğini" uygulayan bazı koda bir isim vermekten daha azdır. Bu ismin gerçek değerini sağlamanın tek yolu, ismin ne anlama geldiğini bilen herkese güvenebiliyorsanız, sadece ismi kullanarak derhal kodu çok iyi anlarlar.

Desenler, bunu başarmak için ihtiyaç duydukları kritik kütleyi hiçbir zaman oluşturmadı. Aksine, AAMOF. GoF kitabının çıktığından bu yana geçen 20 (20) yıl boyunca, katılan herkesin iletişimi geliştirmek için kullanabilecekleri tasarım desenlerini gerçekten bildiği bir düzine kadar konuşma görmedim.

Biraz daha ilginç söylemek gerekirse: tasarım desenleri özellikle başarısız oldukları için başarısız oldu.

Çok fazla desen

Bence ikinci ana faktör, eğer bir şey varsa, başlangıçta çok fazla desen seçtiler. Çok sayıda durumda, kalıplar arasındaki farklar, belirli bir sınıfın bir kalıba mı yoksa diğerine mi uyduğunu (ya da belki her ikisini ya da belki ikisini de) gerçekten kesin olarak söylemenin imkânsız olduğu konusunda yeterince incedir.

Amaç, kod hakkında daha yüksek bir düzeyde konuşabilmenizdi. Belirli bir desenin uygulaması olarak oldukça büyük bir kod öbeğini etiketleyebilirsiniz. Basitçe, önceden tanımlanmış olan bu ismi kullanarak, herkes dinleyen genellikle o kodu önemsemediği kadarını bilirdi, böylece bir sonraki şeye geçebildiniz.

Gerçek neredeyse tam tersi olma eğilimindedir. Diyelim ki bir toplantıdasınız ve bu belirli sınıfın bir Cephe olduğunu söyleyelim. Toplantıdaki kişilerin yarısı, ne anlama geldiğini tam olarak unuttuğundan beri, hiçbir zaman bilemez ya da bilmez. Onlardan biri ona bir Cephe ve bir Proxy arasındaki tam farkı hatırlatmanızı ister. Ah, ve kalıpları gerçekten tanıyan bir çift insan, toplantının geri kalanını bunun bir Cephe mi yoksa sadece bir Adaptör olarak mı '' bir '' Bağdaştırıcı '' olarak kabul edilip edilmeyeceğini tartışarak geçirir (bu adam hala onun için Proxy gibi görünmesi konusunda ısrar eder).

Niyetiniz gerçekten sadece: "bu kod çok ilginç değil; devam edelim" diyerek, bir modelin adını kullanmaya çalışırken, sadece dikkat dağıtma ekledi, değer değil.

İlgi eksikliği

Çoğu tasarım deseni, kodun ilginç kısımlarıyla gerçekten ilgilenmez. "Bu nesneleri nasıl yaratırım?" Ve "Bu nesnenin onunla konuşmasını nasıl sağlayabilirim?" Bunlar için örüntü adlarını ezberlemek (ve ayrıca detaylar ve daha önce bahsi geçen argümanların yanı sıra) çoğu programcının umursamadığı şeylere çok fazla enerji harcıyor.

Biraz daha farklı koymak gerekirse: kalıplar pek çok program arasında aynı olan şeylerle ilgilenir - ama gerçekten bir programı ilginç yapan şey , diğer programlardan nasıl farklı olduğu .

özet

Tasarım desenleri başarısız oldu, çünkü:

1. Kritik kütle elde edemediler.
2. Desenler arasındaki farklılıklar netliği sağlamak için yetersizdi.
3. Çoğunlukla kod bölümleriyle ilgileniyorlardı, neredeyse hiç kimse gerçekten umursamıyordu.

Kalıplar soyutlama eksik, basit kalıplar soyutlanmış, karmaşık kalıplar tanınmıyor, bu yüzden kalıplar kullanışlı değil (birkaç üst seviye hariç).

Bence Paul Graham en iyisini söyledi:

Programlarımda modeller gördüğümde, bunun bir sorun belirtisi olduğunu düşünüyorum. Bir programın şekli yalnızca çözmesi gereken sorunu yansıtmalıdır. Koddaki diğer herhangi bir düzenlilik, en azından benim için yeterince güçlü olmayan soyutlamalar kullandığımın - genellikle elle yazmam gereken bazı makroların genişlemelerini ürettiğimin bir işareti.

Kodunuzdaki bir deseni tanıdığınızda, bu bir şeyin kendisini tekrar ettiği ve daha iyi bir soyutlama kullanmanız gerektiği anlamına gelir. Daha iyi bir soyutlamaya sahip değilseniz, deseni bir geçici çözüm olarak kullanın. Yeni programlama dilleri daha iyi soyutlamalar sağladığından, desenler çok daha az kullanışlı hale gelir.
Ayrıca basit desenler genellikle kolayca soyutlanır ve karmaşık desenler nadiren tanınır.
Bir model bir soyutlama ile yer değiştirdiğinde, bu, modelin arkasındaki kavramın ortadan kalkması anlamına gelmez, fakat bu kavramın dolaylı yerine açıkça yazılabileceği ve diğer kodla karşılaştırıldığında artık özel olmadığı ve artık tanımlanamayacak hale geldiği anlamına gelir. Bir kalıp

Çoğunlukla başkalarının burada ne cevap verdiğiyle aynı fikirde olurken, şahsen, sayıları artmayan sayılar olduğunda, sayıları gittikçe artan sayıda örüntü için ana nedenlerin anlamlarını yitirdiğini düşünüyorum. Bu birkaç kalıpla ilgili güzel şey, bir çok sorunlu alanı standart bir şekilde ele almaları. Sonsuz bir kalıp etki alanına odaklanırsanız, hiçbir kalıp kalmayacaksınız. Bu biraz "bir adanın sahil şeridi ne kadar?" Gibi. Bir haritada ölçüyorsanız, makul bir rakamla gelirsiniz. Ancak, daha kesin ve daha hassas bir çözüm elde etmeye çalışırsanız, uzunluğun sonsuzluğa (veya belirsizliğe gittikçe daha fazla arttığını göreceksiniz); gelgit ve atomik seviyedeki kesin sınırı nasıl ölçeceksiniz?).

Diğer cevapların hiçbirinin bahsetmediği bir konu da bununla ilgilidir:

Dinamik olarak yazılmış dillerin yükselişi.

Kitap ilk çıktığında Java. Şimdi Java gerçek bir iş yapmak sadece çok yavaş ciddi tartışma sıklıkla daha etkileyici dilleri üzerinde kullanılır oldu çünkü onun hızı. Belki Ruby, Python, JavaScript ve diğerleri, bazı önemli uygulama sınıfları için hala çok yavaş olsa da, çoğu kişi için yeterince hızlıdırlar. Ve en azından JavaScript, her sürümde daha fazla özellik paketlenmiş olmasına rağmen aslında daha hızlı oluyor.

Orijinal GoF kitabında hem küçük hem de c ++ desenleri vardı ve eğer bellek işe yararsa, desenler her zaman küçük harflerde kısaydı ve bazen de çok önemliydi. Klasik tasarım modellerinin özelliklerinden bazıları, statik olarak yazılan bir sisteme dinamik özellikler eklemenin gerçekten yoludur (çalışma zamanı verilerine göre doğru sınıfı başlattığınız önceden tanımlanmış AbstractFactory gibi). Diğerleri dinamik dillerde o kadar kısadır ki, dilin kendisinin deyimsel kullanımına karışırlar.

Bu oldu . Yayıncılar ve yazarlar başka bir gruba atlamaya (ya da yaratmaya) çalışırken bilgisayar biliminin bütününü desen tasarlamaya indirgeme girişimi gibi görünen yüzlerce kitap yayınlanmamışsa onlarca. Onlardan bir rafım var. İlk taranandan beri hiç danışılmadı ve evet ben enayiştim, çünkü herhangi bir fiili kullanımda çok az ya da hiçbir şey yoktu ya da zaten iyi bilinmemişlerdi (örneğin, ifade edilen üçüncü normal formdan başka bir şey olmayan Tip Nesnesine bakınız). bir paragraf yerine bir düzine sayfa) ve tabii ki ne kadar az desen daha iyi olursa: pratisyenlerin çoğundan kaçan bir nokta. Gerçekten, Type Object'in bir çürütüsünü gönderdiğimde, metnimi tasarım deseni olarak yeniden yazmam istendi .Gerçek hikaye. Aynı zamanda projenin başka bir eksikliğini de gösterir: gözden geçirme veya hariç tutma veya reddetme mekanizması yoktur.

Aslına bakılırsa, GoF aslında 'Tasarım Modellerini' iyice araştırmaya çalışmadı. Daha ziyade, çok daha büyük bir proje üzerinde çalıştılar: “kalıp dili” ni CS'ye, bütünüyle tuhaf olan Kuvvetler, Katılımcılar vb.

Ne ki yararlı olduğu, başarmak, iki şey oldu:

• Ziyaretçi kalıbı gibi birkaç faydalı püf noktası yayınlayabilir
• Sıkışmış standart bir isim seti sağlar: Fabrika, Adaptör, Yineleyici, ... Hemen önceden tasarlanmış olan CORBA'ya bakarsanız, bunun değerini göreceksiniz: Interceptor gibi her türlü 'yabancı' isim , Hizmetkar, Komisyoncu, ...

Ortaya çıkan bir başka yararlı kavram 'anti-patern', örneğin 'kütük atma' idi. Proje, CS’deki pek çok şey gibi, kendi evangelizmiyle ve yanlış bir şekilde başka bir CS dini olarak benimsendikten sonra raydan çıkarıldı ve bu tür dinlerin çoğunun yoluna gitti: bazı yerlerde yararlı, ancak kesinlikle “gümüş mermi yok” ((c Fred Brooks, 1965). Gerçekten bunu birkaç yılda bir yeniden keşfetmeye devam etmemiz gerektiğine üzücü.

Yıllık konferansta sunulan makalelerin bir antolojisi olan PLoP ( Program Tasarımının Desen Dilleri) adlı birkaç kitap vardı / vardı .

Kitapları okurken, bazı modellerin benim için ilginç ve yeni olduğunu, bazılarının standart olduğunu gördüm (örneğin, "yarım nesne artı protokol").

Bu yüzden hayır, GoF'un koleksiyonu ayrıntılı değildi ve insanlara yeni şeyler toplama / açıklama / keşfetme / icat etme konusunda ilham verdi / ilham verdi.

"Vikipedi makalesinde listelenen sadece 12 ek kalıp" muhtemelen de tam bir koleksiyon değil: yani başka yerlerde belgelenen başkaları da var, örneğin PLoP kitaplarında ve belki başka yerlerde.

The Gang of Four (GoF) kitabı, işlevsel olmayan bir dilde deneyimli bir programcının alet kemerinde sahip olduğu çoğu deseni içerir. Tüm inşaatçıların nasıl kullanılacağını bildikleri temel araçlar gibidir. Kitabın birincil katkısı, o sırada en deneyimli programcılar tarafından yaygın olarak kullanılan kalıplara iyi tanımlanmış bir isim vermek ve böylece tasarım seçeneklerini tartışan programcılar arasında iletişimi sağlamaktı.

Bir elektrik teknisyeninin normal bir üreticinin yapmadığı bazı araçlara sahip olmasını beklersiniz, aynı şekilde bir WPF programlayıcısının “Bağımlılık Özellikleri” için tasarım modellerini bilmesini beklersiniz veya “SQL Programcı” için tetikleyicileri kullanmak için tasarım modelini bilmek istersiniz. denetim verisi yarat.

Ancak bunları yalnızca bir teknolojiyle kullanıldığı için “Tasarım kalıpları” olarak düşünmüyoruz.

Bazı modem tasarım desen kitapları “Yenileme, Mevcut Kod Tasarımını İyileştirme (Martin Fowler)” ve “Temiz Kod: Çevik Yazılım İşçiliğinin El Kitabı (Robert C. Martin) ” dır. şu anki kodunuz için, “önceden konserve yeniden kullanılabilir tasarım” yerine, ancak onlar da “tasarım kalıpları” dır.

İşte Erich Gamma ile röportajlarını seçtikleri kalıpları ve bugün neleri değiştireceklerini yansıttığı bir röportaj.

http://www.informit.com/articles/article.aspx?p=1404056

Larry: "Tasarım Desenleri" ni nasıl yeniden değerlendirirsiniz?

Erich: Bu alıştırmayı 2005 yılında yaptık. İşte oturumumuzdan bazı notlar. Nesneye yönelik tasarım ilkelerinin ve kalıpların çoğunun o zamandan beri değişmediğini bulduk. Sınıflandırmayı değiştirmek, yeni üyeler eklemek ve bazı kalıpları bırakmak istedik. Tartışmanın çoğu, kategorizasyonun değiştirilmesi ve özellikle hangi kalıpların kaldırılacağıyla ilgiliydi.

Hangi kalıpların düşeceğini tartışırken, hepsini hala sevdiğimizi gördük. (Pek sayılmaz - Singleton'ı düşürmekten yanayım. Kullanımı neredeyse her zaman bir tasarım kokusudur.)

Yani burada bazı değişiklikler var:

• Tercüman ve Uçucu Ağırlık, "Diğer / Bileşik" olarak adlandırdığımız ayrı bir kategoriye taşınmalıdır, çünkü diğer modellerden gerçekten farklı hayvanlardır. Fabrika Yöntemi, Fabrikaya Genelleştirilecektir.
• Kategoriler: Çekirdek, Yaratılışsal, Çevresel ve Diğer. Buradaki amaç, önemli kalıpları vurgulamak ve bunları daha az kullanılanlardan ayırmaktır.
• Yeni üyeler: Boş Nesne, Tip Nesnesi, Bağımlılık Enjeksiyonu ve Uzatma Nesnesi / Arabirimi (bkz. Program Tasarımı 3'ün Deseni Dillerinde "Uzatma Nesnesi", Addison-Wesley, 1997).
• Bunlar kategorilerdi:
  • Çekirdek: Kompozit, Strateji, Devlet, Komuta, Yineleyici, Proxy, Şablon Yöntemi, Cephe
  • Yaratılış: Fabrika, Prototip, Oluşturucu, Bağımlılık Enjeksiyonu
  • Çevre Birimi: Soyut Fabrika, Ziyaretçi, Dekoratör, Arabulucu, Tür Nesnesi, Boş Nesne, Uzatma Nesnesi
  • Diğer: Sinek, Tercüman

Kitaptaki asıl kalıplar bazen gerçekten yararlıdır, ancak bunlar aslında kitabın size sunduğu daha güçlü bir aracın örnekleridir: monolitik kodu bir arayüzle ayrılmış ve düzenlenmiş bağımsız parçalarda ne zaman ve nerede kesmenin daha iyi olduğu hakkında derinlemesine bir anlayış. .

Bu beceriyi öğrendiğinizde, her bir desenin kesin ayrıntılarını hatırlamanıza gerek olmadığını fark edersiniz, çünkü uyguladığınız çözümü her zaman amacına en iyi şekilde uyacak şekilde kesebilirsiniz. Böylece daha fazla desen yazma fikri çok akademik ve anlamsız görünüyor.

Bu yüzden bilinen ve belgelenen tasarım modellerinin sayısının önemli ölçüde artmasını bekledim.

Bu yaşanmadı. GoF kitabının yayınlanmasından 20 yıl sonra, Wikipedia makalesinde, çoğu orijinallerinden daha az popüler olan sadece 12 ek örnek listelenmiştir. (Eşzamanlılık kalıplarını buraya dahil etmedim çünkü belirli bir konuyu kapsıyorlar.)

GoF kitabı ve Wikipedia, bilinen tasarım desenlerinin tek kaynağı değildir. Amazon.com'da "tasarım desenleri" ni arıyorsanız, yüzlerce kitap alırsınız (bu aramayı deneyin ). Sanırım Vikipedi makalesinde sadece en iyi bilinen modeli listeliyorlar .

Bu nedenle sorun, yeterince belgelenmiş tasarım deseni bulunmamasıdır. Aksine, hiç kimse hepsini ezberleyemez ve çoğu programcı yalnızca bir kaçını tanır. Ortak kalıp dilinin büyük vaadi bu noktada bozuluyor.

Muhtemelen henüz düşünülmemiş çok fazla yapı var. İnsanlar yazılım geliştirdiği sürece üstesinden gelinmesi gereken tasarım zorlukları olacaktır. Bunlardan bazıları, başkalarının faydalanabileceği akıllı yeni modeller kullanılarak çözülebilir.

Programlama dilleri, en sık kullanılan kalıpları soyutlamak için gelişti ve ilerlemiştir. Bu desenler dillerin tasarımında hala mevcuttur. Bu yüzden bugün göz ardı edilebilirler, ancak bu onları önemsiz yapmaz.

Bizim için yapabilecek robotlarımız olduğunda bir evin nasıl inşa edileceği bilgisi aniden önemsiz mi? Hayır tartışırdım, değil. Daha az alakalı, kesin - ve talep keskin bir şekilde düştüğü ve başka hiç kimse üzerinde çalışmadığı için muhtemelen çok daha az faydalı.

Yani hayır, sizin dediğiniz gibi kalıp uzayının tükenmiş olduğuna inanmıyorum. Başka bir cevabın işaret ettiği gibi, sonsuz olması muhtemeldir. Ancak, sistem tasarımına olan talep azaldıkça, soyutlama kulemizin yüksekliğini ve programlama dillerimizin gücünü artırdıkça - en üst katlarda inşa edilen az ya da çok insan kulenin nasıl inşa edildiğine dikkat edecektir. .

Desenler sonsuzdur .. Her bir deseni düzenleyebilir veya yenilerini oluşturmak için n eşleşmesini karıştırabilirsiniz .. Kurumsal entegrasyon desenleri de iyi tanımlanmıştır. Her etki alanı için desen gelişir ve python veya scala gibi ifade dili için de değişirler.