Bugünlerde neyin tek bir sorumluluk veya niçin değişmek için bir sebep teşkil ettiği hakkında tartışmanın faydalı olmadığını düşünüyorum. Yerine bir Asgari Keder Prensibi öneriyorum:
Minimum Keder Prensibi: Kod, değişiklik yapma olasılığını en aza indirmeyi veya değiştirilme kolaylığını en üst seviyeye çıkarmaya çalışmalıdır.
O nasıl? Bunun neden bakım maliyetlerini azaltmaya yardımcı olabileceğini bulmak için bir roket bilimci almamalı ve umarım sonsuz bir tartışma konusu olmamalıdır, ancak genel olarak SOLID'de olduğu gibi, her yerde kör olarak uygulanacak bir şey değildir. Takas dengeleme sırasında göz önünde bulundurulması gereken bir şey.
Değişiklik gerektiren olasılık gelince, bu aşağı gider:
- İyi test (geliştirilmiş güvenilirlik).
- Özel bir şeyler yapmak için gereken yalnızca minimum kodun dahil edilmesi (bu, afferent kuplajların azaltılmasını içerebilir).
- Sadece kodun ne yaptığını badass yapmak (Badass Prensibi Yapma bölümüne bakınız).
Değişiklik yapma zorluğuna gelince, efferent kuplajlarla yükseliyor. Test, farklı kaplinleri tanıtır, ancak güvenilirliği artırır. İyi yapıldığında, genellikle zarardan daha iyidir ve Asgari Keder Prensibi tarafından tamamen kabul edilebilir ve desteklenir.
Badas Prensibi olun: birçok yerde kullanılan sınıflar harika olmalı. Kalite, vb. İle bağları varsa güvenilir, verimli olmalılar.
Ve Badass Yapma Prensibi, En Az Keder Prensibi'ne bağlıdır, çünkü badass işleri, yaptıkları şeyleri emen şeylerden daha düşük bir değişiklik gerektirme olasılığını bulacaktır.
Yukarıda belirtilen paradoksa işaret ederek başlayacaktım ve daha sonra SRP'nin dikkate almak istediğiniz ayrıntı düzeyine bağlı olduğunu ve yeterince ileri götürürseniz, birden fazla özellik veya bir yöntem içeren herhangi bir sınıfın ihlal ettiğini belirtmek isterdim. o.
Bir SRP açısından bakıldığında, neredeyse hiç bir şeyi yapmayan bir sınıfın değişmesi için yalnızca bir (bazen sıfır) sebep olabilir:
class Float
{
public:
explicit Float(float val);
float get() const;
void set(float new_val);
};
Bunun pratik olarak değişmesi için hiçbir sebep yok! SRP'den daha iyi. ZRP!
Bunun dışında, Badass Prensibi yapmanın açıkça ihlal edildiğini ileri sürmemiştim. Aynı zamanda kesinlikle değersiz. Çok az şey yapan bir şey badass olmayı ümit edemez. Çok az bilgi (TLI) var. Ve tabii ki, TLI olan bir şeye sahip olduğunuzda, içerdiği bilgilerle bile, gerçekten anlamlı bir şey yapamaz, bu yüzden başka birinin gerçekten anlamlı ve kötü bir şey yapması umuduyla dış dünyaya sızdırması gerekir. Ve bu sızıntı sadece veri toplamayı amaçlayan bir şey için tamamdır, başka bir şey yoktur, ama bu eşik "veri" ve "nesneler" arasındaki fark olarak.
Tabii ki TMI olan bir şey de kötü. Tüm yazılımımızı bir sınıfa koyabiliriz. Sadece bir runyöntem bile olabilir . Ve birileri bile şimdi bunun değişmesi için çok geniş bir nedene sahip olduğunu iddia edebilir: "Bu sınıf sadece yazılımın geliştirilmesi gerekiyorsa değişmesi gerekir." Aptallık yapıyorum, ama elbette bununla ilgili tüm bakım konularını hayal edebiliyoruz.
Bu yüzden, tasarladığınız nesnelerin ayrıntı dereceleri veya kalınlıkları ile ilgili olarak dengeleyici bir hareket var. Genellikle dış dünyaya ne kadar bilgi sızdırmanız gerektiği ve ne kadar anlamlı işlevsellik gösterebileceği konusunda karar veririm. Badass Prensibi Yap'ı, Minimum Keder Prensibi ile birleştirirken dengeyi bulmak için sık sık yardımcı olurum.