Kaçınılacak tasarım desenleri [kapalı]

Pek çok insan, Singleton modelinin bir takım dezavantajları olduğu konusunda hemfikir görünüyor ve hatta bazıları modelden tamamen kaçınmayı öneriyor. Burada mükemmel bir tartışma var . Lütfen Singleton modeliyle ilgili her türlü yorumu bu soruya yöneltin.

Sorum : Kaçınılması veya çok dikkatli kullanılması gereken başka tasarım modelleri var mı?

Desenler karmaşıktır

Tüm tasarım desenleri dikkatli kullanılmalıdır. Bence , hemen bir model uygulamak yerine, bunu yapmak için geçerli bir neden olduğunda kalıpları yeniden gözden geçirmelisiniz . Kalıpları kullanmanın genel sorunu, karmaşıklık katmalarıdır. Modellerin aşırı kullanımı, belirli bir uygulamayı veya sistemi daha da geliştirmek ve sürdürmek için zahmetli hale getirir.

Çoğu zaman basit bir çözüm vardır ve herhangi bir özel kalıp uygulamanıza gerek kalmaz. İyi bir temel kural, kod parçalarının değiştirilmesi veya sık sık değiştirilmesi gerektiğinde bir model kullanmak ve bir model kullanırken karmaşık kod uyarısını almaya hazır olmaktır.

Kodunuzda değişikliği desteklemek için pratik bir ihtiyaç görürseniz , amacınızın basitlik olması ve bir kalıp kullanmanız gerektiğini unutmayın .

Kalıplar üzerindeki ilkeler

Aşırı tasarlanmış ve karmaşık çözümlere yol açabileceklerse, kalıpları kullanmak bir tartışma gibi görünebilir. Bununla birlikte, bir programcı için modellerin çoğunun temelini oluşturan tasarım tekniklerini ve ilkelerini okumak çok daha ilginçtir . Aslında , 'tasarım kalıpları' üzerine en sevdiğim kitaplardan biri, söz konusu modele hangi ilkelerin uygulanabilir olduğunu yineleyerek bunu vurguluyor . Alaka düzeyi açısından modellerden faydalı olacak kadar basittirler. Kodunuzun modülleri oluşturabildiğiniz sürece , ilkelerden bazıları, Liskov İkame İlkesi gibi nesne yönelimli programlamadan (OOP) daha fazlasını kapsayacak kadar geneldir .

Çok sayıda tasarım ilkesi vardır, ancak GoF kitabının ilk bölümünde açıklananlar başlamak için oldukça yararlıdır.

• Bir 'uygulama' değil, bir 'arayüz' için programlayın. (Dörtlü Çete 1995: 18)
• "Nesne bileşimini" "sınıf kalıtımına" tercih edin. (Dörtlü Çete 1995: 20)

Bir süreliğine bunların içine kapılmasına izin ver. GoF yazıldığında, arayüzün Java veya C # tür olarak arayüzle karıştırılmaması gereken, soyutlama olan (süper sınıflar anlamına gelen) herhangi bir şey anlamına geldiği unutulmamalıdır . İkinci ilke, maalesef bugün hala yaygın olan, gözlemlenen aşırı miras kullanımından kaynaklanmaktadır .

Oradan , Robert Cecil Martin (aka Bob Amca) tarafından bilinen SOLID ilkelerini okuyabilirsiniz . Scott Hanselman, Bob Amca ile bu ilkeler hakkında bir podcast'te röportaj yaptı :

• Tek Sorumluluk İlkesi
• O pen Kapalı Prensibi
• L iskov İkame Prensibi
• Ben ayrılığı prensibi nterface
• D ependency Reversiyon Prensibi

Bu ilkeler, meslektaşlarınızla okumak ve tartışmak için iyi bir başlangıçtır. İlkelerin birbiriyle ve kaygıların ayrılması ve bağımlılık aşılama gibi diğer süreçlerle iç içe geçtiğini görebilirsiniz . Bir süre TDD yaptıktan sonra, izole ve tekrarlanabilir birim testleri oluşturmak için bunları bir dereceye kadar takip etmeniz gerektiğinden, bu ilkelerin doğal olarak pratikte geldiğini görebilirsiniz .

Design Patterns yazarlarının kendilerinin en çok endişelendiği şey "Ziyaretçi" modeliydi.

Bu "gerekli bir kötülüktür" - ancak genellikle aşırı kullanılır ve buna duyulan ihtiyaç genellikle tasarımınızda daha temel bir kusuru ortaya çıkarır.

"Ziyaretçi" kalıbı için alternatif bir ad "Çoklu gönderim" dir, çünkü Ziyaretçi kalıbı, iki türüne göre kullanılacak kodu seçmek için tek tip bir gönderim OO dili kullanmak istediğinizde elde ettiğiniz şeydir. (veya daha fazla) farklı nesneler.

Klasik örnek, iki şekil arasında kesişme noktasına sahip olmanızdır, ancak genellikle gözden kaçırılan daha da basit bir durum vardır: iki heterojen nesnenin eşitliğini karşılaştırmak.

Her neyse, genellikle böyle bir şeyle sonuçlanırsınız:

interface IShape
{
    double intersectWith(Triangle t);
    double intersectWith(Rectangle r);
    double intersectWith(Circle c);
}

Bununla ilgili sorun, tüm "IShape" uygulamalarınızı bir araya getirmiş olmanızdır. Hiyerarşiye yeni bir şekil eklemek istediğinizde, diğer tüm "Shape" uygulamalarını da değiştirmeniz gerekeceğini ima ettiniz.

Bazen bu doğru minimal tasarımdır - ama iyice düşünün. Tasarımınız gerçekten iki türde göndermeniz gerektiğini şart koşuyor mu? Çoklu yöntemlerin her bir kombinasyon patlamasını yazmaya istekli misiniz?

Genellikle, başka bir kavramı tanıtarak aslında yazmak zorunda kalacağınız kombinasyonların sayısını azaltabilirsiniz:

interface IShape
{
    Area getArea();
}

class Area
{
    public double intersectWith(Area otherArea);
    ...
}

Elbette buna bağlıdır - bazen tüm bu farklı durumların üstesinden gelmek için gerçekten kod yazmanız gerekir - ancak dalmaya başlamadan ve Ziyaretçi'yi kullanmadan önce durup düşünmeye değer. Daha sonra sizi çok fazla acıdan kurtarabilir.

Singletons - singleton X kullanan bir sınıfın ona bağımlılığı görülmesi ve test için izole edilmesi zor.

Çok sık kullanılırlar çünkü uygun ve anlaşılması kolaydır, ancak testi gerçekten karmaşık hale getirebilirler.

Bakın Singletons Patolojik Yalancılardır .

Şablon Yöntemi modelinin genellikle çok tehlikeli bir model olduğuna inanıyorum.

• Çoğu zaman "yanlış nedenlerle" miras hiyerarşinizi kullanır.
• Temel sınıflar, her türlü ilişkisiz kodla kirlenme eğilimindedir.
• Sizi, genellikle geliştirme sürecinin oldukça erken safhalarında tasarımı kilitlemeye zorlar. (Çoğu durumda erken kilitlenme)
• Bunu daha sonraki bir aşamada değiştirmek daha da zorlaşır.

Tasarım Modellerinden (DP) kaçınmanız gerektiğini düşünmüyorum ve mimarinizi planlarken kendinizi DP'leri kullanmaya zorlamanız gerektiğini düşünmüyorum. DP'leri yalnızca planlamamızdan doğal çıktıklarında kullanmalıyız.

Baştan belirli bir DP'yi kullanmak istediğimizi tanımlarsak, gelecekteki tasarım kararlarımızın çoğu, seçtiğimiz DP'nin ihtiyaçlarımıza uygun olduğuna dair hiçbir garanti olmaksızın bu seçimden etkilenecektir.

Ayrıca yapmamamız gereken bir şey de bir DP'yi değişmez bir varlık olarak ele almaktır, modeli ihtiyaçlarımıza göre uyarlamalıyız.

Yani özetlemek gerekirse, DP'lerden kaçınmamız gerektiğini düşünmüyorum, mimarimizde zaten şekillenirken onları kucaklamalıyız.

Bence Active Record, iş mantığını kalıcı kodla karıştırmayı teşvik eden aşırı kullanılan bir model. Depolama uygulamasını model katmanından gizlemek için çok iyi bir iş yapmaz ve modelleri bir veritabanına bağlar. Tablo Veri Ağ Geçidi, Satır Veri Geçidi ve Veri Eşleştiricisi gibi, genellikle daha iyi bir çözüm sunan ve kesinlikle depolamaya daha iyi bir soyutlama sağlamaya yardımcı olan birçok alternatif (PoEAA'da açıklanmıştır) vardır. Ayrıca, modelinizin bir veritabanında saklanmasına gerek yoktur ; XML olarak depolamaya veya web hizmetlerini kullanarak bunlara erişmeye ne dersiniz? Modellerinizin depolama mekanizmasını değiştirmek ne kadar kolay olurdu?

Bununla birlikte, Aktif Kayıt her zaman kötü değildir ve diğer seçeneklerin gereğinden fazla olacağı daha basit uygulamalar için mükemmeldir.

Çok basit ... Sizin için net olmayan veya kendinizi rahat hissetmediğiniz Tasarım Modellerinden kaçının .

Bazılarını adlandırmak için ...

bazı pratik olmayan kalıplar vardır , örneğin:

• Interpreter
• Flyweight

ayrıca anlaşılması daha zor , örneğin:

• Abstract Factory - Oluşturulan nesnelerin ailelerini içeren tam soyut fabrika deseni, göründüğü kadar kolay değil
• Bridge - Soyutlama ve uygulama alt ağaçlara bölünürse çok soyut olabilir, ancak bazı durumlarda çok kullanılabilir bir modeldir
• Visitor - Çift gönderim mekanizması anlayışı gerçekten bir zorunluluktur

ve son derece basit görünen , ancak ilkeleri veya uygulamaları ile ilgili çeşitli nedenlerden dolayı çok net bir seçim olmayan bazı kalıplar vardır :

• Singleton - gerçekten tamamen kötü bir model değil, sadece ÇOK fazla kullanılmış (genellikle orada, uygun olmadığı yerlerde)
• Observer - harika desen ... sadece kodu okumayı ve hata ayıklamayı çok daha zor hale getirir
• Prototype - ticaret derleyicisi dinamizmi denetler (iyi veya kötü olabilir ... bağlıdır)
• Chain of responsibility - çok sık olarak zorla / yapay olarak tasarıma itiliyor

"Pratik olmayanlar" için, kullanmadan önce gerçekten düşünmek gerekir, çünkü genellikle bir yerlerde daha zarif bir çözüm vardır.

"Kavranması daha zor" olanlar için ... uygun yerlerde kullanıldıklarında ve iyi uygulandıklarında gerçekten çok yardımcı oluyorlar ... ama yanlış kullanıldığında kabuslar.

Şimdi, sırada ne var ...

• Head First Design Patterns bir zorunluluktur
• Kaynak yapımı "ilk yardım" dır

Umarım bunun için fazla dayak yemeyeceğim. Christer Ericsson , gerçek zamanlı çarpışma tespit blogunda tasarım kalıpları konusunda iki makale ( bir , iki ) yazdı . Ses tonu oldukça sert ve belki biraz kışkırtıcı, ama adam işini biliyor, bu yüzden bunu bir delinin çılgınlığı olarak görmezden gelmem.

Bazıları servis bulucunun bir anti model olduğunu söylüyor .

Gözlemci modelinin cevaplaması gereken çok şey olduğuna inanıyorum, çok genel durumlarda işe yarıyor, ancak sistemler daha karmaşık hale geldikçe bir kabusa dönüşüyor, OnBefore (), OnAfter () bildirimlerine ihtiyaç duyuyor ve tekrarlanmayı önlemek için sıklıkla eşzamansız görevler yayınlıyor. eğlence. Çok daha iyi bir çözüm, hesaplamalar sırasında tüm nesne erişimlerini (okuma engelleriyle) ölçen ve otomatik olarak bir bağımlılık grafiğinde bir kenar oluşturan bir otomatik bağımlılık analizi sistemi geliştirmektir.

Spoike'ın gönderisinin bir tamamlayıcısı olan Refactoring to Patterns iyi bir okuma.

Yineleyici, kaçınılması gereken veya en azından alternatiflerden hiçbiri mevcut olmadığında kullanmak için bir başka GoF modelidir.

Alternatifler:

1. her döngü için. Bu yapı çoğu ana dilde mevcuttur ve çoğu durumda yinelemelerden kaçınmak için kullanılabilir.

2. seçiciler à la LINQ veya jQuery. Konteynerdeki tüm nesneler işlenmemesi gerektiğinden, her biri için uygun olmadığında kullanılmalıdır. Yineleyicilerden farklı olarak, seçiciler, hangi tür nesnelerin işleneceğini tek bir yerde göstermeye izin verir.