Hangi tasarım desenleri en kötü veya en dar tanımlanmıştır? [kapalı]

Her programlama projesi için geçmiş programlama deneyimine sahip yöneticiler, projeniz için bazı tasarım desenleri önerdiklerinde parlamaya çalışırlar. Tasarım kalıplarını anlamlı bulduklarında veya ölçeklenebilir bir çözüme ihtiyaç duyduğunuzda seviyorum. Örneğin, Proxy'leri, Gözlemcileri ve Komut örneklerini olumlu bir şekilde kullandım ve bunu her gün yapıyorum. Ancak, bir nesneyi yaratmanın tek bir yolu varsa, bir fabrika gelecekte her şeyi kolaylaştırabilir, ancak kodu zorlaştırır ve ek yükler olduğundan, Fabrika modeli söylemek konusunda gerçekten tereddüt ediyorum.

Bu yüzden sorum, gelecekteki kariyerim ve etrafa rastgele kalıp isimleri atan menajer tiplerine verdiğim yanıtla ilgili olarak:

Hangi tasarım desenlerini kullandınız, bu sizi genel olarak geri attı mı? En kötü tasarım kalıpları hangileri, mantıklı oldukları tek durum dışında göz önünde bulundurmanız gerekenler (okuma: hangi tasarım kalıpları çok dar bir şekilde tanımlanmıştır)? (Sanki insanların tasarım kalıplarını en çok neyin rahatsız ettiğini görmek için genel olarak iyi bir Amazon ürününün olumsuz eleştirilerini arıyor gibiydim.) Ve burada Anti-Patterns hakkında değil, genelde düşündüğüm Patterns hakkında konuşuyorum. "iyi" desenler.

Düzenleme: Bazılarının cevapladığı gibi, sorun genellikle kalıpların "kötü" değil "yanlış kullanıldığı" şeklindedir. Sık sık yanlış kullanılan ve hatta kullanımı zor kalıpları biliyorsanız, aynı zamanda bir cevap olarak da kullanılabilir.

Kötü kalıplara inanmıyorum, kalıpların kötü uygulanabileceğine inanıyorum!

• IMHO singleton , en çok istismara uğramış ve en yanlış uygulanan kalıptır. İnsanlar tekil bir hastalığa yakalanmış gibi görünüyorlar ve alternatifleri düşünmeden her yerdeki tekiller için olanakları görmeye başlıyorlar.
• IMHO ziyaretçi kalıbı en dar kullanıma sahip ve neredeyse hiçbir zaman karmaşıklık haklı çıkmayacak. Güzel bir pdf kazanılmış olabilir burada . Gerçekten de, tüm verileri önceden bilmeden, veri yapısı üzerinde farklı işlemler yaparken, bildiğiniz bir veri yapısına sahip olduğunuzda geçilecekse, ziyaretçi desenine dövüş şansı verin. Bu güzel olsa da :)

Bu cevap için sadece GOF kalıplarını dikkate aldım. Olası bütün kalıpları da dikkate alacak kadar iyi tanımıyorum.

Diğer cevaplayıcıların daha önce bahsettiği Singleton ve Visitor'dan başka, "ünlü" tasarım kalıplarını da bilmiyorum. IMHO'nun en büyük problemleri, belirli bir tasarım deseninin "yanlış" olmasından değil, çok istekli kalıpları uygulayan geliştiricilerden kaynaklanıyor.

Neredeyse herkes, kalıplarla tanışırken “kalıp ateşi” aşamasından geçer. Dilimlenen ekmeklerden bu yana kalıpların en iyisi olduğunu düşünerek, ilk bakışta bir olasılık gördüğü zaman bunları uygulamaya çalışır. Bu, kodların, kalıpların kendilerinin artık yardımcı olamadığı kalıpların altına gömülmesine neden olur; kodun uzun vadede anlaşılmasını ve sürdürülmesini zorlaştırır.

Sonunda, çoğumuz bu aşamayı geçiyor ve kendi problemleri için değil, gerçek problemleri çözmek için kalıpları nasıl kullanacağımızı öğrenmeye başlıyor. Kalıplar karmaşıklık eklenmiş olan fiyatlarına sahiptir ve herhangi bir belirli kalıp uygulama, sadece sistemin diğer bir bölümünü basitleştirmeye yardımcı olarak ek karmaşıklık için geri ödeme yapıldığında haklı kılınmakta, böylece kodun / yapılandırmanın genel olarak anlaşılmasını ve sürdürülmesini kolaylaştırmaktadır. Bu durumda değilse, kalıplardan uzak durmak, muhtemelen işe yarayabilecek en basit çözümle yapışmak daha iyidir.

Burada uzuvdan çıkacağım ve kalıtımın aşırı kullanılmasını önereceğim. Kesinlikle en çok Java gibi katı derleme zamanı polimorfizm desteği olmayan dillerde uygulanabilir. Çalışma zamanı devralma, bir özellik değil, hepsine uyan bir özelliktir.

Diğer insanlar zaten Singletons'a olan nefretime benzer bir şekilde ifade ettiler, bu yüzden burada bunun üzerine genişlemeyeceğim.

Singleton. Şimdi daha sık olarak anti-desen olarak adlandırılan GOF kalıpları üzerindedir. Bunun nedenlerinden biri, Singleton'ın kodu test etmesini zorlaştırmasıdır.

Sık sık yanlış kullanılan ve hatta kullanımı zor kalıpları biliyorsanız, aynı zamanda bir cevap olarak da kullanılabilir.

Aşağıdaki MVVM desen için WPF örneğin belirtildiği gibi, çok sıkı bu soruya tarafından . Bazı insanlar, hiçbir kodun koda çok sıkı bir şekilde konulmaması gerektiği ve her türlü egzotik hacklerin ortaya çıkması gerektiği yönergesini izlemeye çalışır.

Ve elbette, MVVM cehennem kadar zordur ve küçük kısa vadeli projeler için buna değmez.

WPF, MV-poo adlı makalesinde ironik bir yazı yaptı .

GOF kitabındaki kalıpların bazıları C ++ 'a özgüdür, yani yansıması olan dillerde daha az uygulanabilirler, örn. Prototip kalıp Java'da daha az önemlidir.

Tercüman modelini 'dar' bir model olarak görüyorum. Genel bir problem çözücüyü geliştirmeye değer genel bir probleminiz olmalıdır. Yalnızca bir dil icat edebileceğiniz, dilbilgisi tanımlayabileceğiniz ve tercüman yazabileceğiniz özel problemler için işe yarar. Sorun örnekleri dilbilgisinde bir cümle olarak gösterilmelidir. Bu tür durumlara sıklıkla rastladığınızı sanmıyorum.

En sık pişman olduğum (en şiddetli olmasa da): Ne zaman yeni bir işlev yaratmalıydım ama bir OOP çözümü uyguladım.

Fabrika. Sadece bir tür yaratan kod uyguladığını gördüm. Bu tamamen yararsız kod IMO. Çevrimiçi örneklerin çoğunun tamamen yerine getirilmesine yardımcı olmuyor. Pizza fabrikası mı?

Belki de fabrika bağımlılık enjeksiyonundan dolayı test etmek daha kolaydır. Ancak ihtiyacınız olmayacaksa bu kodu eklemek benim için anlamsız ve JMockit gibi sahte çerçeveler kullandığınızda test argümanı kaybolur. Bir programı ne kadar basit yaparsanız, o kadar iyi olur. Fabrikalar yalnızca daha çok sayıda tip ile gerçekten anlamlıdır (daha büyük, yani en az 2 den fazla).

Singleton

Singleton hakkında diğerleriyle aynı fikirdeyim. Onları asla kullanmamalısın, sadece birkaç vaka ile sınırlı olmalı. Çoğu zaman tembel küreler olarak kullanılırlar.

İplik güvenliği, singletonlarla ilgili bir konudur. İstisna işleme başka bir şeydir - eğer singleton düzgün bir şekilde oluşturamazsa - hatayı güvenli bir şekilde yakalayıp yakalayamayacağınızı, özellikle de "ana" den önce oluşturulan nesnelerden biri olup olmadığını her zaman bilemezsiniz. Ve daha sonra temizlik sorunu var.

Bir singleton kullanmayı tercih ediyorum ve diğer tüm "wannabe" singletons "un bir tanesine abone olmasını istiyorum. En yaygın singleton kullanımı, "shout olayı" kullanımıdır: siz sadece bir etkinliğin gerçekleştiği "dünyaya yayın yaparsınız" ve olayı dinleyen herkes böyle yapar. Bu şekilde, gerçekte gerçekleşen olayları, onları dinleyenlerle birleştirirsiniz. (Günlüğe kaydetme, sinyaller vb.)

Ziyaretçi

Bu konuda bulduğum çirkin şey, geliştiricilerin anlamlı isimleri düşünmemeleri ve sadece çağrı yöntemlerini ziyaret etmeyi () ziyaret etmeleri dışında, bir yönde genişletirken bir yönde genişletilebilirlik eklemesi, yani başka işlevsellik eklemesi, ziyaretçilerinizin ziyaret edebileceği tüm nesne türleri hakkında bilmesi gereken nesnelerin sayısı.

Dağınık olmasına rağmen, uzantıyı her iki yönde de kullanmak mümkündür, ancak bu, ziyaretçi biçimini normal biçimde kullanmaz. Bunun için en yaygın uygulama, nesneleri basmaktır: nesneleri ve yazdırılması gereken farklı nesneleri basmak için farklı yöntemleriniz vardır. Bunu her iki yönde de genişletebilmelisiniz. (Yazdırma, herhangi bir nesneyi bir akıma dönüştürmek anlamına gelir: bir dosyada / yazıda konsola / GUI'ye vb. Koymak).

(Not: Bunu, biraz farklı bir desen olan belge görüntüleme mimarisiyle karıştırmamalısınız).

Daha karmaşık kalıpların bazılarındaki problemin, iletişim aygıtları olarak değerlerinin çoğunu kaybedecekleri çok fazla varyasyonun olduğunu düşünüyorum.

Bu kategoride aklıma gelen en kötü suçlu MVC paterni. MVP'yi görmezden gelsek bile, bu öğelerin her birinin rolünde, sınırların nerede olduğunu bulmak için her yeni çerçevede bir saat harcamak zorunda olduğunuz çok fazla değişiklik var.

Kötü modeller yok, sadece kötü insanlar var.

Açıkça net bir şeyler yapan, ancak biraz ezilmiş püre yerine tekrar kullanılabilir (gasp!) (Sıra kötü villian müziği) olan biraz ayrıntılı ya da olmayan (kolayca okunabilir kod) miras alırdım InheritAbstractTemplateFaucetSink<Kitchen>.

Yeniden kullanılabilir kod harika! Muhtemelen, yeniden kullanılacak bir kod yazmıyorsunuz veya başka bir uygulamanın benzer mantığını tekrar yazıyorsanız, başka bir uygulamanın kodunu yeniden kullanmaya çalışmaktan daha az zaman alacaksınız.

Daha fazla okuma çatlağı için bazı C kodunu posix başlıklarının veya uçurumların akıllı uygulamalarında açın ve deseni görün. Bu kod, dünyadaki en zeki ve en özel programcılar tarafından yazılmıştır. Kaç tane Soyut Fabrika Örüntüsünü göreceğinizi biliyor musunuz? ... YOK!. Neler olup bittiğini diğer kısımlarını anlarsanız, daha iyi şanslar bile, mantığı anlaması ve izlemesi çok kolay bulacaksınız.

Demek istediğim, bu "kalıpların" çoğunun kodları daha iyi hale getirmek için yaratılmadıkları, kitap satmak ve modelleme yazılımı oluşturmak için yaratıldıkları. Programlamada iyiyseniz, muhtemelen bunların çoğundan kaçınacak ve probleminizi çözen net, özlü ve akıllıca tasarlanmış bir kod yazacaksınız. Başka bir probleminiz olduğunda, bu problemi çözmek için açık, özlü, zekice tasarlanmış bir kod yazacaksınız. Amacınız daha az kod yazmaksa, bence bir programcı olmaktan vazgeçmediğinizi düşünürdüm. Kod yazmayı seviyorum ve mümkün olduğunca yazmak istiyorum. Zaten yazmış olduğum bir şeyi tekrar yazdığımda, onlarca kez hızlı yapıyorum ve ilk yaptığımda mutlu olmadığım her şeyden kurtuluyorum.

Bununla, bilgisayar bilimlerinde muhtemelen en iyi (ilgili) teklifi vereceğim.

“ Bir yazılım tasarımı yapmanın iki yolu vardır: Bir yol, açık bir şekilde hiçbir eksiklik olmayacak kadar basit hale getirmektir ve diğer yol, belirgin bir eksikliğin olmadığı kadar karmaşık hale getirmektir. İlk yöntem çok daha zor . "

• Tony Hoare (quicksort'un mucidi, modern işletim sistemi tasarımının babası, Hoare mantığının yaratıcısı ve Turing ödülü alıcısı)

Çoğu model için bir zaman olduğu ve birçok modeli kötüye kullanabileceğinize kesinlikle katılıyorum. Geçmişte en çok kötüye kullandığımın Soyut Şablon kalıbı olduğunu biliyorum. Tam olarak alındığında ASP.NET webformları olarak bilinir.