SRP'yi uygulamanın pratik yolları nelerdir?

Bir sınıfın tek sorumluluk ilkesini ihlal edip etmediğini kontrol etmek için insanların kullandıkları pratik teknikler nelerdir?

Bir sınıfın değişmek için tek bir nedeni olması gerektiğini biliyorum, ama bu cümlenin bunu uygulamak için pratik bir yolu eksik.

Bulduğum tek yol "......... gerekir ......... kendisi" cümlesini kullanmaktır . burada birinci alan sınıf adı ve daha sonra yöntem (sorumluluk) adıdır.

Bununla birlikte, bazen bir sorumluluğun SRP'yi gerçekten ihlal edip etmediğini anlamak zordur.

SRP'yi kontrol etmenin başka yolları var mı?

Not:

Soru, SRP'nin ne anlama geldiği değil, SRP'yi kontrol etmek ve uygulamak için pratik bir yöntem veya bir dizi adım ile ilgilidir.

GÜNCELLEME

SRP'yi açıkça ihlal eden bir örnek sınıf ekledim. İnsanların tek sorumluluk ilkesine nasıl yaklaştıklarını açıklamak için bunu örnek olarak kullanmaları harika olurdu.

Örnek buradan .

SRP, belirsiz bir ifadeyle, bir sınıfın değişmek için sadece bir sebebi olması gerektiğini belirtir.

Sorudaki "rapor" sınıfının yeniden yapılandırılmasının üç yöntemi vardır:

• printReport
• getReportData
• formatReport

ReportHer yöntemde kullanılan fazlalığı göz ardı ederek , bunun neden SRP'yi ihlal ettiğini görmek kolaydır:

• "Yazdır" terimi bir tür kullanıcı arayüzü veya gerçek bir yazıcı anlamına gelir. Dolayısıyla bu sınıf bir miktar kullanıcı arayüzü veya sunum mantığı içerir. Kullanıcı arayüzü gereksinimlerindeki bir değişiklik, Reportsınıfta bir değişiklik yapılmasını gerektirecektir .

• "Veri" terimi bir tür veri yapısını ifade eder, fakat gerçekten ne olduğunu (XML? JSON? CSV?) Belirtmez. Ne olursa olsun, raporun "içeriği" hiç değişmezse, bu yöntem de değişecektir. Bir veritabanına veya etki alanına bağlantı var.

• formatReportgenel olarak bir yöntem için korkunç bir isim, ancak bir kez daha UI ile ilgili bir şey olduğunu ve muhtemelen UI'nin farklı bir yönüne sahip olduğunu düşünerek varsayıyorum printReport. Yani, başka, ilgisiz bir değişiklik nedeni.

Yani bu bir sınıf muhtemelen bir veritabanı, bir ekran / yazıcı aygıtı ve günlükler veya dosya çıktısı ya da ne için dahili biçimlendirme mantığı ile birleştirilir. Bir sınıftaki her üç işlevin de bulunmasıyla, bağımlılık sayısını çoğaltırsınız ve herhangi bir bağımlılık veya gereksinim değişikliğinin bu sınıfı (veya buna bağlı başka bir şeyi) kırma olasılığını üç katına çıkarırsınız.

Buradaki sorunun bir kısmı, özellikle dikenli bir örnek seçmiş olmanızdır. Muhtemelen Reportsadece bir şey yapsa bile denilen bir sınıfınız olmamalı , çünkü ... hangi rapor? Tüm "raporlar", farklı verilere ve farklı gereksinimlere dayalı olarak tamamen farklı hayvanlar değil mi? Ve rapor , ekran veya yazdırma için zaten biçimlendirilmiş bir şey değil mi?

Ancak, geçmişe bakmak ve varsayımsal bir somut ad oluşturmak - buna IncomeStatement(çok yaygın bir rapor) diyelim - uygun bir "SRPed" mimarisinin üç tipi olacaktır:

• IncomeStatement- biçimlendirilmiş raporlarda görünen bilgileri içeren ve / veya hesaplayan alan ve / veya model sınıfı .

• IncomeStatementPrintergibi bir standart arayüz uygular IPrintable<T>. Bir anahtar yönteme Print(IncomeStatement)ve belki de baskıya özgü ayarları yapılandırmak için başka yöntemlere veya özelliklere sahiptir.

• IncomeStatementRenderer, ekran görüntülemeyi işler ve yazıcı sınıfına çok benzer.

• Sonunda IncomeStatementExporter/ gibi daha fazla özelliğe özgü sınıf da ekleyebilirsiniz IExportable<TReport, TFormat>.

Bu, jenerikler ve IoC kaplarının tanıtımı ile modern dillerde önemli ölçüde kolaylaştırılmıştır. Uygulama kodunuzun çoğunun belirli IncomeStatementPrintersınıfa dayanması gerekmez IPrintable<T>, herhangi bir yazdırılabilir rapor kullanabilir ve bu şekilde çalışabilir , bu da size Reportbir printyöntemle bir temel sınıfın algılanan tüm avantajlarını verir ve her zamanki SRP ihlallerinden hiçbirini vermez . Gerçek uygulamanın, IoC konteynır kaydında yalnızca bir kez bildirilmesi gerekir.

Bazı insanlar, yukarıdaki tasarımla karşı karşıya kaldıklarında, şöyle bir şeyle yanıt verirler: "ancak bu prosedürel koda benziyor ve OOP'un tamamı, bizi veri ve davranışın ayrılmasından uzaklaştırmaktı!" Dediğim: yanlış .

IncomeStatementOlduğu değil sadece "veri" şeklinde ve yine hata ki içine ilgisiz işlevselliği her türlü parazit başlamak sonradan böyle bir "saydam" sınıfı yaratarak bir şey yanlış yapıyorsun ve hissetmek cepten millet bir sürü sebep budur IncomeStatementki (iyi ve genel tembellik). Bu sınıf sadece veri olarak başlayabilir , ancak zamanla garantili olarak daha fazla model olarak ortaya çıkacaktır .

Örneğin, gerçek gelir tablosunda toplam gelirler , toplam giderler ve net gelir çizgileri bulunur. Düzgün tasarlanmış bir finansal sistem büyük olasılıkla bunları depolamayacaktır çünkü bunlar işlemsel veriler değildir - aslında, yeni işlem verilerinin eklenmesine bağlı olarak değişirler. Ancak, raporu yazdırıyor, oluşturuyor veya dışa aktarıyor olsanız da, bu satırların hesaplanması her zaman tam olarak aynı olacaktır. Senin Yani IncomeStatementsınıf şeklinde kendisine davranışın adil bir miktarına sahip olacak getTotalRevenues(), getTotalExpenses()ve getNetIncome()yöntemlerle ve muhtemelen birkaç diğerleri. Gerçekten fazla bir şey yapmıyor gibi görünse bile, kendi davranışı olan gerçek bir OOP tarzı nesnedir.

Ancak formatve printyöntemleri, bilginin kendisiyle hiçbir ilgisi yoktur. Aslında, bu yöntemlerle ilgili birkaç uygulama yapmak istemeniz pek olası değildir , örneğin yönetim için ayrıntılı bir açıklama ve hissedarlar için o kadar ayrıntılı olmayan bir açıklama. Bu bağımsız işlevleri farklı sınıflara ayırmak, tek bir boyuta uyan tüm print(bool includeDetails, bool includeSubtotals, bool includeTotals, int columnWidth, CompanyLetterhead letterhead, ...)yöntemin yükü olmadan çalışma zamanında farklı uygulamaları seçebilmenizi sağlar . Yuck!

Umarım yukarıdaki, büyük ölçüde parametrelendirilmiş yöntemin nerede yanlış gittiğini ve ayrı uygulamaların nerede doğru gittiğini görebilirsiniz; tek nesne durumunda, yazdırma mantığına her yeni kırışıklık eklediğinizde, etki alanı modelinizi değiştirmeniz gerekir ( Finanstaki Tim sayfa numaralarını ister, ancak yalnızca dahili raporda, bunu ekleyebilir misiniz? ) bunun yerine bir veya iki uydu sınıfına bir yapılandırma özelliği eklemek yeterlidir.

SRP'yi doğru şekilde uygulamak bağımlılıkları yönetmekle ilgilidir . Bir sınıf zaten yararlı bir şeyler yapar ve (bir UI, yazıcı bir ağ, bir dosya, ne olursa olsun gibi) yeni bir bağımlılık getirecek başka bir yöntemi ekleyerek düşünüyorsanız Özetle, yok . Bunun yerine bu işlevselliği yeni bir sınıfa nasıl ekleyebileceğinizi ve bu yeni sınıfı genel mimarinize nasıl sığdırabileceğinizi düşünün (bağımlılık enjeksiyonunu tasarlarken oldukça kolaydır). Genel ilke / süreç budur.

Yan not: Robert gibi, SRP uyumlu bir sınıfın yalnızca bir veya iki durum değişkenine sahip olması gerektiği fikrini açıkça reddediyorum. Böyle ince bir ambalajın nadiren gerçekten yararlı bir şey yapması beklenebilir. Yani bununla aşırıya kaçmayın.

SRP'yi kontrol etme yöntemim, bir sınıfın her yöntemini (sorumluluğunu) kontrol etmek ve aşağıdaki soruyu sormaktır:

"Bu işlevi uygulama şeklimi değiştirmem gerekecek mi?"

Farklı şekillerde (bir yapılandırma veya koşul türüne bağlı olarak) uygulayacağım bir işlev bulursam, bu sorumluluğu yerine getirmek için ekstra bir sınıfa ihtiyacım olduğunu kesin olarak biliyorum.

İşte Nesne Jimnastiği'nin 8. kuralından bir alıntı :

Çoğu sınıf tek bir durum değişkenini işlemekten sorumlu olmalıdır, ancak iki tane gerektirecek birkaç tane vardır. Bir sınıfa yeni bir örnek değişkeni eklemek derhal o sınıfın uyumunu azaltır. Genel olarak, bu kurallar altında programlama yaparken, tek bir örnek değişkeninin durumunu koruyanlar ve iki ayrı değişkeni koordine eden iki tür sınıf olduğunu göreceksiniz. Genel olarak, iki tür sorumluluğu karıştırmayın

Bu (biraz idealistc) görünüm göz önüne alındığında, yalnızca bir veya iki durum değişkeni içeren herhangi bir sınıfın SRP'yi ihlal etme olasılığının düşük olduğunu söyleyebilirsiniz. Ayrıca, ikiden fazla durum değişkenlerini içeren herhangi bir sınıf olduğunu söyleyebiliriz olabilir SRP ihlal etmektedir.

Bir olası uygulama (Java'da). Dönüş türleriyle özgürlükler aldım ama her şeyden önce soruyu cevapladığını düşünüyorum. TBH Rapor sınıfının arabiriminin bu kadar kötü olduğunu düşünmüyorum, ancak daha iyi bir ad sıralı olabilir. Muhafız ifadelerini ve kısalık konusundaki iddiaları dışladım.

EDIT: Ayrıca sınıf değişmez olduğunu dikkat edin. Yani bir kez yaratıldığında hiçbir şeyi değiştiremezsiniz. Bir setFormatter () ve setPrinter () ekleyebilir ve çok fazla sorunla karşılaşamazsınız. IMHO'nun anahtarı, somutlaştırıldıktan sonra ham verileri değiştirmemektir.

public class Report
{
    private ReportData data;
    private ReportDataDao dao;
    private ReportFormatter formatter;
    private ReportPrinter printer;


    /*
     *  Parameterized constructor for depndency injection, 
     *  there are better ways but this is explicit.
     */
    public Report(ReportDataDao dao, 
        ReportFormatter formatter, ReportPrinter printer)
    {
        super();
        this.dao = dao;
        this.formatter = formatter;
        this.printer = printer;
    }

    /*
     * Delegates to the injected printer.
     */
    public void printReport()
    {
        printer.print(formatReport());
    }


    /*
     * Lazy loading of data, delegates to the dao 
     * for the meat of the call.
     */
    public ReportData getReportData()
    {
        if (reportData == null)
        {
            reportData = dao.loadData();
        }
        return reportData;
    }

    /*
     * Delegate to the formatter for formatting 
     * (notice a pattern here).
     */
    public ReportData formatReport()
    {
        formatter.format(getReportData());
    }
}

Örneğinizde, SRP'nin ihlal edildiği açık değildir. Belki de rapor nispeten basitse kendisini biçimlendirip yazdırabilmelidir:

class Report {
  void format() {
     text = text.trim();
  }

  void print() {
     new Printer().write(text);
  }
}

Yöntemler o kadar basit ki, sahip olmak ReportFormatterya da ReportPrintersınıflar için mantıklı değil . Arayüzdeki tek göze çarpan problem, getReportDatadeğer olmayan nesneye sorma isteğini ihlal etmesidir.

Öte yandan, yöntemler çok karmaşıksa veya bir biçimi biçimlendirmek veya yazdırmak için birçok yol varsa Report, sorumluluğu devretmek mantıklıdır (ayrıca daha test edilebilir):

class Report {
  void format(ReportFormatter formatter) {
     text = formatter.format(text);
  }

  void print(ReportPrinter printer) {
     printer.write(text);
  }
}

SRP, felsefi bir kavram değil, bir tasarım ilkesidir ve bu nedenle üzerinde çalıştığınız asıl koda dayanır. Anlamsal olarak, bir sınıfı istediğiniz kadar sorumluluklara bölebilir veya gruplandırabilirsiniz. Bununla birlikte, pratik bir ilke olarak, SRP, değiştirmeniz gereken kodu bulmanıza yardımcı olmalıdır . SRP'yi ihlal ettiğiniz belirtileri:

• Sınıflar o kadar büyüktür ki, kaydırma veya doğru yöntemi aramak için zaman kaybedersiniz.
• Sınıflar çok küçüktür ve aralarında atlama veya doğru olanı bulmak için zaman harcıyorsunuz.
• Bir değişiklik yapmak zorunda kaldığınızda, bu kadar çok sınıfı etkiler, takip edilmesi zordur.
• Bir değişiklik yapmanız gerektiğinde, hangi sınıfların değişmesi gerektiği belirsizdir.

Bunları adları iyileştirerek, benzer kodu birlikte gruplandırarak, çoğaltmayı ortadan kaldırarak, katmanlı bir tasarım kullanarak ve sınıfları gerektiği gibi böldüğünde / birleştirerek bunları yeniden düzenleyerek düzeltebilirsiniz. SRP'yi öğrenmenin en iyi yolu, bir kod tabanına daldırmak ve ağrıyı uzaklaştırmaktır.

Tek Sorumluluk İlkesi , uyum kavramıyla büyük ölçüde bağlantılıdır . Oldukça uyumlu bir sınıfa sahip olmak için, sınıfın örnek değişkenleri ve yöntemleri arasında ortak bağımlılığa sahip olmanız gerekir; yani, yöntemlerin her biri mümkün olduğunca çok sayıda örnek değişkeni üzerinde işlem yapmalıdır. Bir yöntem ne kadar çok değişken kullanırsa sınıfına o kadar bağlı olur; maksimum uyum genellikle ulaşılamaz.

Ayrıca, SRP'yi iyi uygulamak için iş mantığı alanını iyi anlarsınız; her soyutlamanın ne yapması gerektiğini bilmek. Katmanlı mimari, her katmanın belirli bir şey yapmasını sağlayarak SRP ile de ilişkilidir (Veri Kaynağı Katmanı veri sağlamalıdır vb.).

Yöntemleriniz tüm değişkenleri kullanmasa bile kaynaşmaya geri dönersek, bunlar birleştirilmelidir:

public class MyClass {
    private Type1 var1;
    private Type2 var2;
    private Type3 var3;

    public Type3 method1() {
        //use var1 and var3
    }  

    public void method2() {
        //use var1 and var2
    }

    public Type1 method3() {
        //use var2 and var3
    }
}

Örnek değişkenlerinin bir kısmının yöntemlerin bir bölümünde kullanıldığı ve değişkenlerin diğer kısmının yöntemlerin diğer bölümünde kullanıldığı aşağıdaki kod gibi bir şey olmamalıdır (burada iki sınıfınız olmalıdır. değişkenlerin her bir parçası).

public class MyClass {
    private Type1 var1;
    private Type2 var2;
    private Type3 var3;
    private TypeA varA;
    private TypeB varB;

    public Type3 method1() {
        //use var1 and var3
    }  

    public void method2() {
        //use var1 and var2
    }

    public TypeA methodA() {
        //use varA and varB
    }

    public TypeA methodB() {
        //use varA
    }
}