Tek sorumluluk, tek bir işlevin yerine getirebileceği bir şey olmayabilir.
class Location {
public int getX() {
return x;
}
public int getY() {
return y;
}
}
Bu sınıf tek sorumluluk ilkesini bozabilir. İki işlevi olduğu için değil, kodun değişmesi gerekebilecek farklı paydaşları memnun etmek getX()ve getY()yerine getirmek zorunda kalması durumunda. Eğer Başkan Yardımcısı X, tüm sayıların kayan nokta sayısı olarak ifade edileceği bir not gönderirse ve Muhasebe Direktörü Bayan Y, X'in iyi bir şekilde düşündüğüne bakılmaksızın, departman incelemelerinin tüm sayılarının tamsayı olarak kalması konusunda ısrar ediyor. Kimin sorumlusu olduğuna dair tek bir fikir, çünkü işler karışmak üzere.
SRP izlenmiş olsaydı, Location sınıfı, X ve grubunun maruz kaldığı şeylere katkıda bulunup bulunmadığı açık olurdu. Sınıfın sorumlu olduğunu açıkça belirtin ve hangi direktifin bu sınıfı etkilediğini biliyorsunuz. Her ikisi de bu sınıfı etkilerse, değişimin etkisini en aza indirecek şekilde zayıf bir şekilde tasarlanmıştır. “Bir sınıfın değişmesi için tek bir sebep olmalı”, tüm sınıfın sadece küçük bir şey yapabileceği anlamına gelmez. Bu, sınıfa bakıp hem Bay X'in hem de Bayan Y'nin bu sınıfa ilgisinin olduğunu söylememem gerektiği anlamına geliyor.
Bunun gibi şeyler dışında. Hayır, çoklu yöntemler iyi. Sadece sınıfa hangi yöntemlerin ait olduğunu ve hangilerinin olmadığını belirten bir isim verin.
Bob Amca'nın SRP'si Conly Yasası hakkında Curly Yasası'ndan daha fazla . Bob Amca, Curly Yasası'nın (bir şey yapmayı) sınıfları değil fonksiyonlara uygulanmasını savunuyor. SRP, karışım nedenlerinin birlikte değişmemesine dikkat eder. Conway Yasası, sistemin bir organizasyonun bilgilerinin nasıl aktığını takip edeceğini söylüyor. Bu, SRP'nin izlenmesine yol açar çünkü asla duymadığınız şeyleri umursamıyorsunuz.
"Bir modül bir oyuncuya ve bir oyuncuya karşı sorumlu olmalıdır"
Robert C Martin - Temiz Mimari
İnsanlar, SRP'nin kapsamı sınırlandırmak için her sebeple ilgili olmasını istemeye devam ediyor. Kapsamı sınırlamak için SRP'den daha fazla neden var. Sınıfın, içeriye bakmanın sizi şaşırtmayacağına dair bir isim alabilecek bir soyutlama olduğunu vurgulayarak kapsamı daha da sınırlandırıyorum .
Kıvırcık Yasasını derslere uygulayabilirsiniz. Bob Amca'nın bahsettiği şeyin dışındasın ama yapabilirsin. Yanlış gittiğin şey, bunun bir işlev anlamına geldiğini düşünmeye başladığın zamandır. Bu bir ailenin sadece bir çocuğu olması gerektiğini düşünmek gibidir. Birden fazla çocuğa sahip olmak, onun aile olmasını engellemez.
Curly yasasını bir sınıfa uygularsanız, sınıftaki her şey tek bir birleştirici fikir hakkında olmalıdır. Bu fikir geniş olabilir. Fikir sebat olabilir. Bazı kayıt yardımcı programı işlevleri oradaysa, o zaman açıkça kullanım dışıdır. Bu kodla ilgilenen tek kişinin Bay X olması önemli değil.
Burada uygulanacak klasik ilke , Endişelerin Ayrılması olarak adlandırılmaktadır . Tüm endişelerinizi ayırırsanız, herhangi bir yerde kalanın tek bir endişe olduğu söylenebilir. 1991 fikri City Slickers'ın bizi Curly karakteri ile tanıştırmasından önce bu fikri biz buna adlandırdık.
Bu iyi. Sadece Bob Amca'nın sorumluluk dediği şey bir endişe değil. Ona karşı sorumluluk, odaklanacağın bir şey değil. Sizi değişmeye zorlayabilecek bir şey. Tek bir endişeye odaklanabilir ve yine de farklı gündemleri olan farklı insan gruplarından sorumlu bir kod oluşturabilirsiniz.
Belki de umrunda değil. İnce. "Bir şeyi yapmayı" tutmanın tüm tasarım sorunlarınızı çözeceğini düşünmek, "bir şeyin" ne olabileceği konusunda hayal gücü eksikliği olduğunu gösterir. Kapsamı sınırlamanın başka bir nedeni de organizasyondur. Her şeyle dolu bir önemsiz çekmeceye sahip olana kadar birçok "bir şeyi" diğer "bir şeyin" içine yerleştirebilirsiniz. Bunun hakkında daha önce konuştum
Elbette, kapsamı sınırlandırmanın klasik OOP nedeni sınıfın içinde özel alanlara sahip olması ve daha sonra bu verileri paylaşmak için alıcılar kullanması, bu verilere ihtiyaç duyan her yöntemi özel olarak verileri kullanabilecekleri sınıfta koyuyoruz. Birçoğu bunu kapsam sınırlayıcı olarak kullanmak için çok kısıtlayıcı buluyor, çünkü birbirine ait her yöntem aynı alanları kullanmıyor. Verileri bir araya getiren herhangi bir fikrin, yöntemleri bir araya getiren aynı fikir olmasını sağlamayı seviyorum.
Bu bakmak için işlevsel bir şekilde olmasıdır a.f(x)ve a.g(x)f basitçe bir g (x) ve bir (X). İki işlev değil, birlikte değişen işlev çiftleri sürekliliği. aBile içinde verilere sahip olmak zorunda değildir. Kullanacağınız hangi uygulamayı fve guygulamayı nasıl bildiğinizle ilgili olabilir . Birlikte değişen fonksiyonlar birbirine aittir. Bu eski güzel polimorfizm.
SRP, kapsamı sınırlandırmanın birçok nedeninden yalnızca biri. İyi bir tane. Ama tek değil.