Tasarım Deseni'nin doğru bir şekilde uygulanıp uygulanmadığı nasıl belirlenir?

Belgelenmiş Tasarım Desenleri kullanmayan tüm eski uygulamalarımı başarıyla ölçeklendirebiliyorum. Hangi desen olursa olsun bilmiyorum. Büyük ölçüde, sadece basit OOP kavramlarını kullanma ihtiyacı duydum.

Tasarım Desenleri kavramı karmaşıktır ve anlaşılması zordur. Uygulandığında, uygulamanın doğru olup olmadığı ve uygulamanın gerçek gevşek bağlantıya sahip olup olmadığı nasıl belirlenir?

Cevabı kısa tutmak için, kodunuzda aşağıdaki özellikler görünürse, buna yönelik kasıtlı çabalar (bu bir sorun değildir) yapmasanız bile kalıpların yerinde olduğundan emin olabilirsiniz.

İstenen Özellikler:

1. Kod tabanınız birim düzeyinde test edilebilir
2. Herhangi bir değişiklik isteği gerçekleştirdiğinizde, yalnızca alan adıyla birlikte alakalı olan ilgili sınıflarda değişiklik yaparsınız.
3. Kod tabanınız yazılım entropisi göstermiyor .

Kodunuzu hala gerçek desen isimleriyle tanımlamak ve etiketlemek istiyorsanız, topu yuvarlamak için aşağıdaki eylemleri gerçekleştirmenizi tavsiye ederim.

1. Birkaç UML daigramı oluşturmak için kod tabanınızı tersine mühendislik yapın.
2. Diyagramları , desen referans malzemesinin hazır referanslarıyla görsel olarak karşılaştırın .

Bu size adil bir fikir vermelidir.

Hem tasarım desenlerinden hem de kuplajdan bahsediyorsunuz. Bunlar ayrı kavramlar, bu yüzden onlarla ayrı ayrı ilgileneceğim. Tek gerçek bağlantı, tasarım modellerinin gevşek kuplajı teşvik etme eğiliminde olmasıdır (çünkü iyi tasarımın önemli bir yönüdür).

Tasarım desenleri

Tasarım Desenleri kavramı aslında oldukça basittir: Bunlar sadece çeşitli yaygın sorunların nasıl ele alınacağına dair bir dizi şablondur. Popüler olmalarının 2 ana nedeni vardır:

1. 'Kanıtlanmışlardır': birçok kez kullanılmışlardır ve her birinin yararları / dezavantajları genellikle bilinir, özellikle büyük sorunlara neden olabilecek ince konular bilinmektedir.
2. Ortak bir terminoloji seti sağlarlar ve böylece daha kolay iletişim sağlarlar. Birisi "sınıf X, gözlemci modelinde gözlemcinin rolünü oynar" derse, o zaman kalıba aşina olan geliştiriciler neler olup bittiğini hemen kavrayabilir.

Doğru uyguladığınızı nasıl anlarsınız? Bu biraz zor. Çoğu desen için basittir - ya onu salladınız ya da yapmadınız. Bazı modeller diğerlerinden daha az açık bir şekilde tanımlanmıştır - örn. Model-görünüm denetleyicisi . Bunun gibi desenler genel kurallar olarak daha iyi kullanılır. Bunu nasıl uyguladığınıza ilişkin ayrıntılar, kalıbın nedenlerini ve neyi başarması gerektiğini anlamaktan daha az önemlidir.

Tasarım kalıpları 'tek doğru yol' değildir. Çoğu zaman bunları özel amaçlarınız için uyarlamanız gerekir veya bazen gereksinimlere uyan herhangi bir desen olmaz. Bir tasarım desenini uymadığı yerde zorlamak kötü bir fikirdir; aslında istediğiniz bir tornavida olduğunda gerçekten iyi bir çekiç kullanmak gibidir.

Kavrama

Bu bilgisayar biliminde gerçekten önemli bir fikir. Çoğu yazılım projesi için gereksinimler zamanla (bazen önemli ölçüde) değiştiğinden, bir tasarımın değişikliklerle başa çıkabilmesi önemlidir. Kuplaj temelde "bu bileşeni başka bir bileşenle değiştirmek ne kadar zor olur?" 'Bileşen' bir yöntem, sınıf, paket, kütüphane vb. Olabilir.

Bu Wikipedia makalesinde listelenen çeşitli bağlantı türleri vardır .

Cevap aslında tasarım desenlerini baştan yazmak istediğiniz amaçtır. Neden esneklik istiyorsunuz?

Bu değişim; gereksinimler değişir. Gereksinimlerinizde, kod değişikliğine yansıyan bir şeyi değiştirmeye çalışın ve bunu yapmanın ne kadar kolay / zor olduğunu görün.

Tasarım kalıplarını kullanmak önleyici bir eylemdir. Daha sonra uygulamayı ölçeklendirirken çalışmanızı kolaylaştırmak için tasarım paternleri kullanırsınız. Tabii ki, daha sonra işinizi kolaylaştırmak için şimdi biraz daha fazla iş yapmalısınız. yani asıl soru gelecekte ne kadar değişiklik bekleyebileceğiniz ve bu değişikliğin ne olduğudur. Ölçeklenebilirlik ve esnekliğe ihtiyacınız yoksa tasarım desenlerini ortadan kaldırabilirsiniz.

Tasarım kalıplarının kendisi Nesneye Dayalı Tasarım İlkelerinin bir uygulamasıdır. Bu ilkelere uyduğunuz sürece uygulamalarınız esnek ve ölçeklenebilir olacaktır; gerçek bir tasarım deseniniz olmasa bile. Joachim Sauer'in yukarıda açıkladığı gibi, ortak sorunlara ortak çözümler.