Tek Sorumluluk İlkesi işlevler için geçerli midir?

Robert C. Martin'e göre, SRP şunları söylüyor:

Bir sınıfın değişmesi için asla birden fazla sebep olmamalıdır .

Bununla birlikte, Temiz Kod , bölüm 3: İşlevler kitabında aşağıdaki kod bloğunu gösterir:

    public Money calculatePay(Employee e) throws InvalidEmployeeType {
        switch (e.type) {
            case COMMISSIONED:
                return calculateCommissionedPay(e);
            case HOURLY:
                return calculateHourlyPay(e);
            case SALARIED:
                return calculateSalariedPay(e);
            default:
                throw new InvalidEmployeeType(e.type);
        }
    }

Ve sonra şunu belirtiyor:

Bu işlevle ilgili birkaç sorun vardır. Birincisi, büyük ve yeni çalışan türleri eklendiğinde büyüyecek. İkincisi, açıkça birden fazla şey yapar. Üçüncüsü, Tek Sorumluluk İlkesini (SRP) ihlal ediyor çünkü değişmesi için birden fazla neden var . [benimkini vurgula]

İlk olarak, SRP'nin sınıflar için tanımlandığını düşündüm, ancak fonksiyonlar için de geçerli olduğu ortaya çıktı. İkincisi, bu fonksiyonun değişmek için birden fazla nedeni var mı? Değiştiğini sadece Çalışan değişikliği nedeniyle görebiliyorum.

Tek Sorumluluk İlkesinin sıklıkla gözden kaçırılan bir ayrıntısı, "değişim nedenlerinin" kullanım senaryosu aktörleri tarafından gruplandırılmasıdır ( burada tam bir açıklama görebilirsiniz ).

Bu nedenle, örneğinizde, calculatePayher yeni çalışan türü gerektiğinde yöntemin değiştirilmesi gerekecektir. Bir tür çalışanın diğeriyle ilgisi bulunmayabileceğinden, bu değişiklikleri bir arada tutarsanız prensip ihlal edilebilir, çünkü değişiklik sistemdeki farklı kullanıcı gruplarını (veya kullanım örneği aktörlerini) etkileyecektir.

Şimdi, ilkenin işlevler için geçerli olup olmadığı hakkında: Tek bir yöntemde bir ihlali olsa bile, bir sınıfı birden fazla nedenden ötürü değiştiriyorsunuzdur, bu yüzden hala SRP ihlalidir.

176. sayfada 12.Bölüm: Ortaya Çıkma, başlıklı bölümde Asgari Sınıflar ve Yöntemler , bir miktar düzeltme sağlayarak, şunları belirterek:

Sınıflarımızı ve yöntemlerimizi küçültmek için çok fazla küçük sınıf ve yöntem oluşturabiliriz. Bu kural, fonksiyonumuzu ve sınıf sayımlarımızı da düşük tuttuğumuzu gösteriyor

ve

Yüksek sınıf ve yöntem sayıları bazen anlamsız dogmatizmin sonucudur.

Açıkçası, SRP'yi takip etmek için calculatePay()yukarıdaki gibi mükemmel ince masum küçük yöntemleri parçalamak için dogmatizmden bahsediyor .

Bay Martin, SRP'yi bir işleve uyguladığında, SRP tanımını dolaylı olarak genişletmektedir. SRP genel bir prensibin OO'ya özgü bir ifadesi olduğundan ve işlevlere uygulandığında iyi bir fikir olduğu için, bununla ilgili bir sorun görmüyorum (ancak açıkça tanım).

Ben de değiştirmek için birden fazla neden görmüyorum ve SRP'yi "sorumluluklar" veya "değişim nedenleri" açısından düşünmenin faydalı olduğuna inanmıyorum. Esasen SRP'nin ele aldığı şey, yazılım varlıklarının (işlevler, sınıflar, vb.) Bir şey yapması ve iyi yapmasıdır.

Tanımıma bir göz atarsanız, SRP'nin normal ifadelerinden daha az belirsiz değildir. SRP'nin olağan tanımlarıyla ilgili sorun, çok belirsiz olmaları değil, aslında belirsiz olan bir şey hakkında çok spesifik olmalarıdır.

Ne yaptığına bakarsanız calculatePay, açıkça tek bir şey yapıyor: türe göre gönderme. Java, tür tabanlı dağıtım yapmanın yerleşik yollarına sahip olduğundan calculatePay, yetersiz ve deyimsiz olduğundan, yeniden yazılmalıdır, ancak belirtilen nedenlerle değil.

Haklısın @Enrique. Sınıfın bir işlevi veya yöntemi ne olursa olsun, SRP bu kod bloğunda yalnızca bir şey yaptığınız anlamına gelir.

'Değiştirme nedeni' ifadesi bazen biraz yanıltıcı olabilir, ancak değiştirirseniz calculateSalariedPayveya calculateHourlyPaynumaralandırmanız Employee.typebu yöntemi değiştirmeniz gerekir.

Örneğinizde işlev:

• çalışanın türünü kontrol eder
• parayı türe göre hesaplayan başka bir işlevi çağırır

Bence bu doğrudan bir SRP ihlali değildir, çünkü Çalışan ve yöntemler zaten varsa, anahtar durumlar ve çağrılar daha kısa yazılamaz. Her neyse, açık bir kapalı-kapalı prensibi (OCP) ihlalidir, çünkü çalışan türlerini eklerseniz 'case' ifadelerini eklemeniz gerekir, bu yüzden kötü bir uygulamadır: refactor.

'Para'nın nasıl hesaplanması gerektiğini bilmiyoruz, ancak en kolay yol Employeearayüz ve bazı somut uygulamalara sahip olmaktır.getMoney yöntemlerle . Bu durumda, tüm fonksiyon gereksizdir.

Hesaplamak daha karmaşıksa,% 100 SRP olmayan ziyaretçi kalıbı da kullanılabilir, ancak bir anahtar durumundan daha fazla OCP.