Doğru Tasarım Desenini Seçme

Tasarım kalıplarını kullanmanın önemini her zaman tanıdım. Diğer geliştiricilerin en uygun olanı seçmeye nasıl gittiğini merak ediyorum. Karar vermenize yardımcı olacak bir dizi özellik (akış şeması gibi) kullanıyor musunuz?

Örneğin:

Nesneler birbiriyle ilişkiliyse, ancak somut sınıf belirtmek istemiyoruz, Özet

Örnekleme türetilmiş sınıflara bırakıldığında, Fabrika’yı düşünün

Toplama nesnesinin öğelerine sırayla erişmeniz gerekiyor, yineleyiciyi deneyin.

Veya benzeri?

Günümüzün kodlama dünyasında kilit bir yanılgı, kalıpların yapı taşları olduğudur. Bir almak AbstractFactoryburada ve bir Flyweightbelki var ve Singletonoraya ve XML ve presto birbirine bağlayın, çalışan bir uygulama var.

Onlar değil.

Hmm, bu yeterince büyük değildi.

Desenler yapı taşları değildir

Bu daha iyi.

Bir şablon, bir sorunun olduğunu tespit ettiğinizde kullandığınız bir şeydir - şablonun sağladığı ya da config dosyasında küçük bir dil oluştururken karşılaştığınız esnekliğe ihtiyacınız var ve "bekleyin Bir an, dur, bu yazdığım kendi tercümandır - bu bilinen ve çözülmüş bir problemdir, bir tercüman deseni kullanın . "

Ama orada not alın, kodunuzda keşfettiğiniz bir şey, başladığınız bir şey değil. Java yaratıcıları başlangıçta "Ah, Tamsayıya Bir Uç Ağırlık koyacağız" demediler, fakat daha çok bir uç ağırlık tarafından çözülebilecek bir performans sorunu fark ettiler .

Ve böylece, doğru modeli bulmak için kullandığınız "akış şeması" yoktur. Model, tekrar tekrar karşılaşılan belirli bir problem tipi için bir çözümdür ve anahtar kısımları bir Paternde damıtılır.

Desene başlamak, bir çözüme sahip olmak ve bir problem aramak gibi. Bu kötü bir şey: aşırı mühendislik ve tasarımda nihayetinde esneksizliğe yol açıyor.

Kod yazarken, bir Fabrika yazdığınızı fark ettiğinizde, "ah ha! Bu yazacağım bir fabrika" diyebilir ve bir sonraki parçayı hızlıca yazmak için Fabrika şablonunu bilme bilginizi kullanabilirsiniz. Fabrika modelini yeniden keşfetmeye çalışmadan kod verin. Ama "Burada bir sınıfım var, bunun için esnek olması için bir fabrika yazacağım" ile başlamıyorsunuz - çünkü olmayacak.

İşte Erich Gamma ( Gamma, Helm, Johnson ve Vissides ) ile yapılan röportajdan bir alıntı : Tasarım Desenlerinin Kullanımı :

Tüm kalıpları kullanmaya çalışmak kötü bir şey çünkü kimsenin ihtiyaç duymadığı esnekliğe sahip spekülatif tasarımlar gibi sentetik tasarımlara sahip olacaksınız. Bugünlerde yazılım çok karmaşık. Başka ne yapması gerektiğini speküle edemeyiz. Gereksinim duyduğu şeye odaklanmamız gerekiyor. Bu yüzden kalıplara yeniden bakmayı seviyorum. İnsanlar, belirli bir sorun ya da kod kokusu olduğunda, insanlar bugünlerde dedikleri gibi, bir çözüm bulmak için kalıp araçlarına gidebileceklerini öğrenmelidir.

"Ne kullanılacağı, ne zaman" için en iyi yardım muhtemelen yazılım tasarım deseni için Wikipedia sayfasıdır - "Sınıflandırma ve liste" bölümü, her bir kalıbın içinde bulunduğu kategoriyi ve ne yaptığını tanımlar. Akış çizelgesi yok; Buradaki açıklama muhtemelen "ne zaman kullanılacağı" için kısa bir kod parçası olarak bulabileceğiniz en iyisidir.

Programlamanın farklı alanlarında farklı desenler bulacağınızı unutmayın. Web tasarımı kendi kalıplarını oluştururken, JEE (web tasarımı değil) başka bir kalıp setine sahiptir. Finansal programlama kalıpları, bağımsız uygulama UI tasarımı için olanlardan tamamen farklıdır.

Her türlü girişimin bunları listelemek için Yani bütün doğal olarak tamamlanmamıştır. Birini bulursun, nasıl kullanılacağını bul ve sonunda sonunda ikinci doğa olur ve ne zaman ve ne zaman kullanılacağını düşünmene gerek kalmaz (birisi onu açıklamanı isteyene kadar).

Kendime soruyorum:

1. Hangi sorunu çözmeye çalışıyorum?
2. Hangi yazılım tasarım deseni (varsa) aynı sorunu en yakın bir şekilde çözer veya sorunumu çözme yolunda mantıklı bir yol sağlar?
3. Desenin sağladığı ek soyutlamaya (ve karmaşıklığa) ihtiyacım var mı, yoksa kendi sorunum için aşırı mühendislik mi yapıyorsun? Problem, model olmadan daha basit ve daha verimli bir şekilde çözülebilir mi?

Bir yazılım modelini seçme süreci, bir veri yapısı seçme sürecine benzemez, ancak bir veri yapısı seçerken , probleminizin performansını ve hafıza özelliklerini değerlendirebilir ve bu özelliklere en çok uyan veri yapısını seçersiniz.