İçeriğe geç →

Solid Nedir ve Single Responsibility Principle (SRP)

solid
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 kullanmamız gerektiği düşüncesine gelirsek:

Bağımlılık Yönetiminin(Dependency Managament) kötü oluşturulmuş olduğu bir projede, esnetile bilirliğin(Rigidity: yeni eklentilere ve geliştirmelere açık olması) 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. 🙂

srp
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 (Rigidity) 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:

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:

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.

Bu makale toplam (5597) kez okunmuştur.

63
0



Kategori: Nesne Yönelimli Programlama (Object Oriented Programming) Tasarım Prensipleri (Design Principles)

3 Yorum

  1. Ali Ali

    Okuduğum en güzel yazılardandı hocam 🙂 Blogunuzu 1.5 yıldır takip ediyorum bugün boş vakit oldu yorum atma isteği geldi 🙂

    Bu yazı ben üniversitedeyken okuduğum bir yazıydı.

    Bugün hala 15-20 bin satırlık tek dosyalar üzerinden çalışılan projeler var.

    Mail göndermesi de kullanıcı silmesi de yazı eklemesi de tek class üzerinde işliyor.

    Bu yazıyı okuyana kadar yani iş hayatından önce ben de öyle yapıyordum.

    Tabi okunabilirlik derken abartanı da gördüm. Örneğin;

    class UserAccount
    {
    public User CreateUser()
    {
    }
    }

    class UserDeleteAccount
    {
    public UserDelete DeleteUserAccount()
    {
    }
    }

    Gibi. Tamam okunabilir belki ama bütünlüğü nasıl sağlayacaksınız gibi sorunlar çıkıyor.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.