Tasarım desenleri günümüzde gerçekten gerekli mi?

"İşyerinde Kodlayıcılar" okuyordum ve kitapta görüşülen bazı profesyonellerin tasarım kalıpları konusunda çok hevesli olmadıkları gerçeğiyle karşılaştım.

Bunun 2 ana nedeni olduğunu düşünüyorum:

1. Tasarım desenleri bizi terimleriyle düşünmeye zorlar. Başka bir deyişle, yeni bir şey icat etmek neredeyse imkansızdır (belki daha iyi).

2. Tasarım desenleri sonsuza dek sürmez. Dil ve teknolojiler hızlı değişiyor; Bu nedenle, tasarım desenleri sonunda alakasız hale gelecektir.

Bu yüzden belki de belirli bir kalıp olmadan nasıl düzgün bir şekilde programlandığını öğrenmek ve onları öğrenmek için daha önemlidir.

Mesele şu ki, genellikle insanlar bir sorunla karşı karşıya kaldıklarında ve fazla zamanları olmadığında, bir kalıp kullanmaya çalıştıklarıydı. Bu, çalışmasını sağlamak için mevcut kodu projenize küçük değişiklikler yaparak kopyalayıp yapıştırmak anlamına gelir. Bir şeyi değiştirme veya ekleme zamanı geldiğinde, bir geliştirici nereden başlayacağını bilmez, çünkü bu onun kodu değildir ve ona çok aşina değildir.

Param için, herkesin tasarım desenleri noktasını kaçırdığını düşünüyorum. Belirli bir durumda hangi modeli kullanmam gerektiğini merak ediyorum. Ayrıca, bu kalıpların çoğunu isimlerinin olduğunu bilmeden çok önce kullanıyordum.

Tasarım kalıplarının gücü iletişimde. “Bunun için bir Strateji kullanın” demek benim için önerdiğim şeyi ayrıntılı olarak açıklamaktan daha hızlı. Bu iki terimin ne anlama geldiğini hepimiz biliyorsak, yağ alanlı modellerin ve işlem komut dosyalarının yararlarını tartışmamız çok daha kolaydır. Ve bunun gibi.

Ve hepsinden önemlisi, eğer bir FooBuilder sınıfı seçtiyseniz, Foo'umu oluşturmak için Oluşturucu desenini kullandığımı biliyorsunuz.

"Gözlemci modeli bunun için ideal" derken neyden bahsettiğimi bilmeseniz bile, hemen çıkıp kolayca google’a erişebileceksiniz.

Bu anlamda, tasarım modellerinin gücü asla kaybolmayacak.

Tasarım kalıpları, yazılım insanı olarak kullandığımız ortak dilin ifade gücünde bir artıştır. Bu ortak dil zorunlu değildir, ancak sorunlara birçok ortak çözümü ifade etmeyi daha kolay ve daha hızlı hale getirir. Örneğin, Singletons hakkında konuşmak, "yalnızca bir örneğe sahip olmamız gereken ancak durağan ve küresel olamayacağımız sınıflar" hakkında konuşmaktan çok daha kolaydır.

Tasarım modellerinin sağladığı çözümler kullanışlıdır, ancak çözdükleri sorunlarla karşılaştığınızda muhtemelen önceden düşündüğünüz çözümlerdir. Tasarım kalıplarını anlamak için belirli bir vade seviyesi gereklidir - sorunu hiç çözmek zorunda kalmazsanız, çözüme olan değeri veya ilgiyi göremezsiniz.

Desenler iki ana amaca hizmet eder:

• Gerginlikleri tahmin edilebilir bir şekilde çözme : Desenler, belirli bir gerginlik kümesini işe yaradığı bilinen bir şekilde çözmek için tasarlanmıştır. Smalltalk En İyi Uygulama Kalıplarının yazarı Kent Beck, kalıpları benzer durumlarda bir uzmanın vereceği kararı tekrarlamanın bir yolu olarak tanımlar. Gerilimler aynı kaldıkça (ve sıklıkla yaparlarsa), onları çözen kalıplar yararlı kalacaktır.

• İletişim gücü çarpanı : Desenler çok fazla şey söylememize izin veriyor. Çok çeşitli problem alanlarında uygulanabilir küçük, güçlü ve iyi anlaşılmış kavramlar setinden yararlanırlar. @ pdr'nin yanıtı, kalıpların iletişimsel değeri konusunda öldü.

Tasarım kalıplarının yeniliği engellediğine dair olumlu düşüncenin tamamen yanlış olduğunu düşünüyorum. Nerede olduğunu bilmelisin ki tekerleği yeniden icat etmene gerek kalmaz. Geçici olmak için, bir bütün olarak desenler OOP sistemlerine uygulanır ve herhangi bir platform veya dile bağlı değildir.

Şimdi, insanlar kalıplardan bahsettiklerinde sevmediğim şey, bazı insanların onlarla bir tür takıntı yaşaması. Bir keresinde benden "en az iki kalıp daha eklemem" (WTF ?!) sormam için bir müşterim vardı, çünkü kodumdaki buzzwords eksikliği nedeniyle yeterince girişimci görünmüyordu.

Belki de anti-kalıp kavramı almanyadır. Tasarım kalıplarını çalışmayı yazılım mühendisi olmak için kritik bir adım olarak düşünmüyorum. Yazılım tasarımı, genellikle bir projedeki yazılım mimarının ayrıcalığı olarak ayrılan bir şeydir, ancak gerçekçi bir şekilde, atasözü “iyi huylu” takımda fikir birliği ile dövülebilecek bir şeydir.

Ancak tasarım kalıpları ve anti kalıpları bu tartışmalar için bir kaynak oluşturur. İnsanın iyi işleyen (veya iyi olmayan) dersleri ve tasarım tercihlerinin sonuçlarını nasıl kullanabileceğinizi (veya azaltacağını) takdir etmesi gerekir. İyi bir takım , bu tür tartışmalar için kendi kelime hazinesiyle gelebilirdi, ancak orada bulunan yazarların uyguladığı defacto standartlarına atıfta bulunmak gerçekten de o kadar da kötü bir şey değil.

İki tür tasarım deseni vardır:

1. Onları daha iyi anlayabilmeniz için karmaşık programların nasıl organize edileceği hakkında çok daha fazlası olan evrensel modeller . Bunlar gitmiyor, ancak daha fazla örnek keşfedilebiliyor.
2. Kısıtlamalar (örn. Programlama dili) tarafından oluşturulan belirli güçlere o kadar bağlı olan durum örüntüleri , bu güçler değiştiğinde, ilgisiz kalmaktadır.

Tamam, tartışmasız tüm kalıplar biraz durumsaldır, ancak bazı güçler gerçek dünyadan ve diğerleri ile güçler araçlardandır. Araçlar gerçek dünyadan çok daha hızlı değişiyor.

Tasarım kalıplarını okumak, yeniden icat etmek yerine matematiği öğrenmek gibidir. Hiçbiri, daha önce neler olduğuna dair sağlam bir anlayışa sahip olduğunuzda sizi belirli bir alanda büyük ilerleme kaydetmekten alıkoymaz. Rieman'ın Euclid'i hiç okumadığını mı düşünüyorsun?

Meslektaşlarınızın veya müşterilerinizin "Bu nasıl çalışır?" Diye düşünerek harcadıkları süreyi azalttıklarında kalıp tasarlamanın yararı vardır. Standardizasyon uğruna bir standardın uygulanmasının bir anlamı olmasa da, bir şeyi yapmanın ortak ve iyi anlaşılmış bir yolu varsa, bir kodlayıcı onu bulmayı bekleyen ve yapmayı bekleyen bir model aradığında, onların ve işlerini yaptın Daha kolay.

Dört kişiden oluşan çetenin tasarım kalıplarını şöyle sınıflandırdığını düşünüyorum.

Sık karşılaşılan bir problem için ortak bir çözüm *

Bu yüzden evet, aynı tür problemler ortaya çıktığında modeller birbiriyle ilgilidir. Bu da bizi "Tasarım Deseni" terimiyle ilgili bir soruna getiriyor. Bir kalıp, tekrar tekrar meydana gelen tanınabilir bir şeydir. Yani gerçekte bir tasarım deseni yoktur, bir sorun modeli vardır.

Bazı programlama dilleri, bu sorunların bazıları için doğal çözümler olabilir. “Tasarım Desenleri” kitabının kendisi, eğer CLOS kullanıyorsanız, çok yönlü gönderim CLOS tarafından doğal olarak desteklendiğinden, Ziyaretçi deseninin çözmeye çalıştığı sorun olan CLOS kullanıyorsanız, ziyaretçi şablonunun değeri çok azdır.

Ayrıca, .NET çerçevesi, olayları birden fazla dinleyiciye yayınlamak için yerleşik bir olay mekanizmasına sahiptir ve böylece Observer modelini bu bağlamda daha az alakalı hale getirir.

Masaüstü uygulamalarından web uygulamalarına ** geçiş, çözmemiz gereken programlama problemlerinin türünü de değiştirir. "Tasarım Kalıpları" kitabındaki kalıpların çoğu, masaüstü uygulamaları ile ilgilidir, ancak web uygulamaları için fazla değildir. Tabii ki, tek sayfa uygulamalarında, bu modeller müşteri tarafında yine alakalı olabilir.

Ancak, tasarım kalıpları ve "Tasarım Kalıpları" veya "Kurumsal Uygulama Mimarisi Kalıpları" gibi kitaplar, acemi bir programcı olduğunuzda ve ilk kez yeni bir sorunla karşı karşıya kaldığınızda çok değerlidir; ilk kez olduğum gibi Geri Al işlevselliğini uygulamam istendi. “Tasarım Desenleri” kitabı olmasaydı, benim uygulamam büyük olasılıkla her durum değiştiren operasyondan sonra verilerin bir anlık görüntüsünü depolamak gibi bir şey olabilirdi *** - çok hataya açık ve korkunç derecede yetersiz bir yaklaşım.

Bu yüzden evet, kalıbın bir kısmı zamanla daha az alakalı hale gelir ve deneyimli bir programcı olduğunuzda onlar hakkında daha az düşünürsünüz. Ancak bir acemiye göre, bir problemi çözmenin bir yolu olduğunu hatırladığınız sürece değerlidirler - ve mümkün olduğunca çok bir arayış değildir.

* alıntı, bellekten alındığı için% 100 doğru olmayabilir

** benim deneyimlerime göre, işletmelerin iç iş kolu uygulamaları için web dağıtım mekanizmaları seçmeleri çok yaygınlaşıyor.

*** fonksiyonel programlama ve fonksiyonel veri yapılarını öğrendikten sonra, bu aslında bugün çözme yöntemim olabilir.

Tasarım kalıplarına Slav bağlılık zarar verebilir - kalıplar genel sorunların çözümünde belgelenmiştir, ancak kullanım kılavuzları değildir. Bununla birlikte, sadece uzun süre tartışıldıkları ve bazı durumlarda, etkili sorun alanları dışında uygulanan herhangi bir değere sahip olmadıkları anlamına gelmez. Bunlar, bir program ilkesi tasarlarken, mimarın çözüm çalışmasını nasıl görmek istediğine dair bir izlenim vermesine olanak tanıyan bir dizi prensiptir - buna bir çerçeve diyoruz. İyi bir geliştirme ekibi onları işlevsel bir şartname yerine fonksiyonelliğin temeli olarak görür.