Solid Nedir ve Single Responsibility Principle (SRP)

Merhaba arkadaşlar.

Bir kaç makale serisi boyunca, SOLID prensipleri üzerinde durmayı planlıyorum. Öncelikle ilk prensibimiz olan Single Responsibility‘e geçmeden, kısaca SOLID kavramı nedir bir tanımaya çalışalım.

SOLID, Robert Martin‘in sunumu ile ortaya çıkan bir Dependency Managament(Bağımlılık Yönetimi) biçiminin, 5 adet ilkesinin baş harflerinden oluşan prensiplerdir.

Bunları sıralayacak olursak eğer:

• Single Responsibility
• Open Closed
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Klasik tanımları bir kenara bırakacak olursak ve neden bu SOLID prensiplerine ihtiyacımız olduğu veya neden kullanmamız gerektiği düşüncesine gelirsek:

Bağımlılık yönetiminin(Dependency managament) kötü oluşturulmuş olduğu bir projede, genişletilebilirliğin neredeyse mümkün olmaması, sabit(Immobility: geliştirilen modüllerin tekrar kullanıma uygun olmaması) ve kırılgan(Fragility: yapılacak olan bir değişikliğin, başka kısımları etkilemesi) bir yapının olmasından dolayı projemizin hayat sigortasının sınırlı olması ve sürdürülebilirliğinin olmaması durumudur diye açıklayabiliriz.

Bu sebepler genel olarak SOLID prensiplerinin ortaya çıkış noktasıdır ve biz kısaca:

“Projemizin sürdürülebilirliğinin olması, yani yeni teknoloji ve eklentilere açık olması, yapılacak bir değişikliğin farklı yerleri etkilemeyip, geliştirmelere açık olmasıdır da” diyebiliriz.

Evet, bu kadar hızlı bir SOLID nedir kavramından sonra ilk prensiplerimizden birisi olan Single Responsibility yani tek sorumluluk manasına gelen prensibimizi incelemeye başlayabiliriz. 🙂

Single Responsibility prensibindeki asıl amaç: bir class veya function’a sadece ve sadece tek bir sorumluluğu yerine getirmesine dayanmaktadır.

Birden fazla sorumluluklar bir class veya function’a yüklendiğinde kod aşırı büyüyor ve karmaşık bir hale geliyor. Karmaşık ve aşırı büyük bir kodun yönetimi zordur ve bu seviyede kırılganlığı (Fragility) ortaya çıkar. Aynı zamanda esnekliği (Extendability) bi okadar da azdır.

Kendisi ile ilgili sorumlulukları yerine getirmediği için, yapacağımız en ufak değişiklikler başka yerleri etkileyebilir ve yeniden kullanılabilirliğini de düşürmüş oluruz.

Yalnızca kendi sorumluluğunu getirecek şekilde parçalara böldüğümüzde ise, hem yönetimini kolaylaştırmış olup hemde yeniden kullanabilirliğini sağlarız.

Şimdi basit bir örnekle açıklayalım:

public class User
{
    public void ChangeUserName()
    {
        //Kullanıcı adını değiştirir
    }

    public void ChangeEmailAddress()
    {
        //Email adresini değiştirir
    }

    public void SendAnEmail()
    {
        //Email gönderir
    }
}

“User” işlemlerinin yapıldığı bir class düşünelim. İçerisinde “ChangeUserName“, “ChangeEmailAddress” ve “SendAnEmail” metotlarının olduğunu varsayalım.

İlk bakıldığında her ne kadar normal gözükse de aslında hatalı bir tasarımdır. “ChangeUserName” ve “ChangeEmailAddress” metotları “User” class’ının sorumlulukları olabilir ama “SendAnEmail” metotu sorumluluğu içinde değildir.

Bu şekildeki bir tasarımla artık “SendAnEmail” metotunun başka yerlerde kullanılabilirliğini (Reusability) engellemiş olduk.

Doğru bir tasarım yapmak gerekirse:

public class User
{
    public void ChangeUserName()
    {
        //Kullanıcı adını değiştirir
    }

    public void ChangeEmailAddress()
    {
        //Email adresini değiştirir
    }
}

public class EmailHelper
{
    public void SendAnEmail()
    {
        //Email gönderir
    }
}

“User” class’ına sadece kendi sorumluluğunu verdik ve email işlemlerini “EmailHelper” isminde bir class’da topladık. (Bu helper class’ları proje yapınıza ve nerelerde ortak kullanacağıza göre değişiklik gösterebilir. Ben bu senaryo için bu şekilde uygun gördüm.) Artık email ile ilgili işlemlerimiz “EmailHelper” class’ın sorumluluğunda gerçekleştirilecek.

Bu şekildeki kullanımlarda hem kodumuzun kontrolü daha kolaylaşıyor hem de tekrar kullanılabilirliği (Reusability) artıyor.

Kısaca basit bir örnek üzerinden tanımlamış olduk. Umarım bu basit örnek, real-world projelerinizde ki yaklaşımlarınızı düşünürken, bir class’a veya bir function’a yükleyeceğiniz sorumlulukları tekrardan basit bir şekilde nasıl gözden geçirebileceğinize yardımcı olur.

Takipte kalın.