Tek Sorumluluk İlkesi ile Endişelerin Ayrılması arasındaki fark nedir

a) SRP ve SoC arasındaki fark nedir ? Belki de bu SRP ise, sınıf düzeyinde uygulanır SoC de uygulanabilir sistem , alt , modül , sınıf veya fonksiyon seviyeleri.

b) cevabı ise : a) o zaman evet mi SoC uygulanan sınıf düzeyinde bir eşanlamlısı SRP ?

teşekkür ederim

Tek Sorumluluk İlkesi, kodunuzun sadece 1 şey yapmasıyla ilgilidir ve tüm işlevleri 1 belirli bir şey yapmak için tasarlanan birkaç sınıfta bölebilirsiniz. Örnek, doğrulama, bazı iş mantığı yapma, bir modeli zenginleştirme, veri alma, veri güncelleme, gezinme vb. İçin belirli bir sınıftır.

Endişelerin Ayrılması, kodunuzun diğer sınıflara / sistemlere sıkı sıkıya bağlı olmamasıyla ilgilidir. Kodunuzdaki arabirimleri kullanmak çok yardımcı olur, bu şekilde sınıfları / sistemleri kodla gevşek bir şekilde birleştirebilirsiniz. Bunun bir artı tarafı da kodunuzu birim olarak test etmenin daha kolay olmasıdır. Bunu başarmanıza yardımcı olabilecek çok sayıda (IoC) çerçeve var, ancak böyle bir şeyi elbette kendiniz de uygulayabilirsiniz.

SRP'ye sahip olmayan bir SoC örneği

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;

    public Foo(IValidator validator, IDataRetriever dataRetriever)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return ValidBusinessLogic();
            }
        }
        return InvalidItems();
    }

    private object DoSomeFancyCalculations(object item)
    {
        return new object();
    }
    private NavigationObject ValidBusinessLogic()
    {
        return new NavigationObject();
    }

    private NavigationObject InvalidItems()
    {
        return new NavigationObject();
    }
}

Gördüğünüz gibi, bu kod sınıflara veya diğer sistemlere sıkıca bağlı değildir, çünkü bir şeyler yapmak için sadece bazı arayüzleri kullanır. Bu bir SoC açısından iyidir.

Gördüğünüz gibi bu sınıf bazı süslü şeyler yapan 3 özel yöntem de içeriyor. Bir SRP açısından bakıldığında, bu yöntemler muhtemelen kendi sınıflarına yerleştirilmelidir. 2 tanesi bazı INavigation sınıfına uyan navigasyon ile bir şeyler yapıyor. Diğeri bir öğe üzerinde bazı süslü hesaplamalar yapar, bu muhtemelen bir IBusinessLogic sınıfına yerleştirilebilir.

Böyle bir şeye sahipken, ikinizde de SoC ve SRP var:

public class Foo
{
    private readonly IValidator _validator;
    private readonly IDataRetriever _dataRetriever;
    private readonly IBusinessLogic _businessLogic;
    private readonly INavigation _navigation;

    public Foo(IValidator validator, IDataRetriever dataRetriever, IBusinessLogic businessLogic, INavigation navigation)
    {
        _validator = validator;
        _dataRetriever = dataRetriever;
        _businessLogic = businessLogic;
        _navigation = navigation;
    }

    public NavigationObject GetDataAndNavigateSomewhereIfValid()
    {
        var data = _dataRetriever.GetAllData();

        if(_validator.IsAllDataValid(data))
        {
            object b = null;
            foreach (var item in data.Items)
            {
                b = _businessLogic.DoSomeFancyCalculations(item);
            }

            if(_validator.IsBusinessDataValid(b))
            {
                return _navigation.ValidBusinessLogic();
            }
        }
        return _navigation.InvalidItems();
    }
}

Elbette tüm bu mantığın GetDataAndNavigateSomewhereIfValidyönteme dahil edilmesi gerekip gerekmediğini tartışabilirsiniz . Bu kendiniz karar vermeniz gereken bir şey. Bana göre bu yöntem çok fazla şey yapıyor gibi görünüyor.

SRP'nin sadece sınıf düzeyinde uygulanmasına gelince, Robert C. Martin adlı kitaplarında (bildiğim kadarıyla konsept ile gelmediğinde popülerleştiğini) şöyle ifade eder:

Temiz Kod, sayfa. 138 : "Tek Sorumluluk İlkesi (SRP), bir sınıfın veya modülün değiştirmek için bir ve yalnızca bir nedeni olması gerektiğini belirtir ."

Çevik Prensipler, Desenler ve Uygulamalar'da C #, sayfa 116 : "[...] ve bir modülün ya da bir sınıfın değişmesine neden olan kuvvetlerle uyumu ilişkilendirin ."

Vurgu madeni.

In APPP o SRP hakkında daha uzunluğunda konuşur ve sınıf düzeyinde neredeyse tamamen duruldu. Sınıf seviyesine odaklanmış gibi görünse de, prensibin modüllere ve diğer üst düzey yapılara da yönlendirildiğini hissediyorum.

Bu nedenle, sorunuzda önerdiğiniz gibi SRP'yi sınıf düzeyinde SoC olarak nitelendirmem.

Burada bu terminolojiler arasındaki farkı net bir şekilde açıklayan kısa bir video bulabilirsiniz. https://www.youtube.com/watch?v=C7hkrV1oaSY

Endişelerin ayrılması (SoC). Mümkün olduğunca az işlevsellik ile uygulamanızı farklı özelliklere bölün. (Microsoft).

“Endişe” = “farklı özellik” = “ayrı bölüm”

“Endişe” hem yüksek hem de düşük seviyelerde çalışır

Tek sorumluluk ilkesi , her modülün veya sınıfın, yazılım tarafından sağlanan işlevselliğin tek bir parçası üzerinde sorumluluğa sahip olması gerektiğini ve bu sorumluluğun tamamen sınıf tarafından kapsüllenmesi gerektiğini belirtir. Tüm hizmetleri bu sorumlulukla dar bir şekilde uyumlu olmalıdır. (Wikipedia tanımı)

“Sorumluluk” = “değişim nedeni”

neyi değiştirmek “Yazılım tarafından sağlanan işlevin tek bir kısmı” = Temel Birim

Sonuç

Tek Sorumluluk İlkesi temel birimlerde çalışır -> düşük seviyede çalışır

Endişelerin Ayrılması hem yüksek hem de düşük seviyelerde çalışır

SRP ve SoC endişelerin ayrılması için birlikte çalışır. Düşük seviyede tamamen aynı

İşte bu ilkeleri anladım.

Endişelerin Ayrılması (SoC) - bir yazılım sistemini daha küçük modüllere bölmekle ilgilidir, bu modüllerin her biri tek bir endişeden sorumludur. Bu durumda bir endişe, bir yazılım sisteminin bir özelliği veya kullanım durumudur. Bir modül, iyi tanımlanmış bir API'ye (arayüz) sahiptir ve bunun sonucunda tüm sistemi yüksek oranda bağdaştırır. İki ana tip vardır: yatay ve dikey.

Tek Sorumluluk İlkesi (SRP) - bir sistemin her bir yapı taşının (bir sınıf, bir modül, bir nesne veya hatta bir işlev olabilir) yalnızca tek bir sorumluluğu olması gerektiğini belirten bir tasarım ilkesidir. Robert C. Martin. Martin bir sorumluluğu değişim nedeni olarak tanımlar. Genel olarak, bu sınıfı büyük ve sıkı bir şekilde birleştiren çok işlevli, hatta bazen ilgisiz işlevleri yerine getirmek yerine işlevselliğin tek bir parçası üzerinde sorumluluğu olan tek bir sınıfa / nesneye sahip olmak çok daha iyidir. “Tanrı nesnesi” denir.

Ayrıca bu ilkeleri blog yayınımda daha ayrıntılı olarak açıkladım, lütfen bir göz atın.

https://crosp.net/blog/software-architecture/srp-soc-android-settings-example/