Tek sorumluluk ilkesi

Tek sorumluluk ilkesine aykırı bir sınıf tasarımını gösteren UML diyagramı

Tek sorumluluk ilkesi (TSİ), SOLID yazılım geliştirme ilkelerinden biridir. Bu ilke, bir yazılım bileşeninin yalnızca bir sorumluluğa ve dolayısıyla bir değişiklik nedenine sahip olması gerektiğini savunur. Başka bir ifadeyle, bir sınıf yalnızca tek bir aktörün (kullanıcı ya da işlevsel gereksinim kümesinin) beklentilerine hizmet etmeli, farklı nedenlerle değişebilecek işlevleri bir arada barındırmamalıdır.

Terim ilk olarak Robert C. Martin tarafından ortaya atılmış ve "Bir sınıfın değişmesi için yalnızca bir nedeni olmalıdır." şeklinde ifade edilmiştir.

Tarihçe

Tek sorumluluk ilkesi, yazılım mühendisliğinde modülerlik anlayışının gelişimiyle birlikte şekillenmiştir. David L. Parnas, 1972 yılında yayımladığı "On the Criteria To Be Used in Decomposing Systems into Modules" adlı makalesinde, sistemlerin akış diyagramı temelli değil, değişmesi muhtemel kararları yalıtacak biçimde modüllere ayrılması gerektiğini savunmuştur. Bu görüş, daha sonra SRP'nin temellerinden biri olarak kabul edilmiştir.

Edsger W. Dijkstra ise 1974 yılında "The Separation of Concerns" kavramını ortaya koyarak, yazılım bileşenlerinin birbirinden bağımsız sorumluluklara sahip olması gerektiğini vurgulamıştır.

İlkenin Uygulaması

Bir yazılım bileşeninin birden fazla sorumluluğu üstlenmesi, değişikliklerin birbirini etkilemesine neden olabilir. Bu durum hem bakımı zorlaştırır hem de hatalara açık bir yapı oluşturur. TSİ, bu türden etkileşimleri önlemek için sınıfların ve modüllerin tek bir göreve odaklanmasını önerir.

• Olumsuz örnek

Aşağıdaki sınıf, hem bordro hesaplaması yapar, hem de veritabanına kayıt işlemi gerçekleştirir. Bu iki işlev farklı nedenlerle değişeceğinden TSİ ihlal edilmektedir:

public class Calisan {
    public double maasHesapla() {
        // Maaş hesaplama mantığı
    }

    public void kaydet() {
        // Veritabanına kaydetme işlemi
    }

    public String calismaSaatleriniRaporla() {
        // Denetim raporu oluşturma
    }
}

Bu sınıf; finans (maaş), BT (veritabanı) ve operasyon (çalışma saati) gibi farklı iş birimlerinin beklentilerini bir arada barındırdığı için birden fazla nedene göre değişmek zorundadır.

• Doğru örnek

Aşağıdaki yapı, her sorumluluğu ayrı sınıflara ayırarak ilkeye uygun şekilde tasarlanmıştır:

public class MaasHesaplayici {
    public double maasHesapla(Calisan c) {
        // Maaş hesaplama mantığı
    }
}

public class CalisanDeposu {
    public void kaydet(Calisan c) {
        // Veritabanına kaydetme işlemi
    }
}

public class ZamanRaporlayici {
    public String calismaSaatleriniRaporla(Calisan c) {
        // Denetim raporu
    }
}

Bu tasarımda her sınıf yalnızca tek bir işlevden sorumludur. Böylece herhangi bir değişiklik, sadece ilgili sınıfı etkiler.

Önemi

TSİ, yazılım sistemlerinde değişime karşı dayanıklı, sürdürülebilir ve okunabilir bir yapı oluşturulmasını sağlar. Bu yaklaşım; yüksek içsel tutarlılığa (cohesion) sahip bileşenlerin oluşturulmasına, farklı nedenlerle değişen yapıların ayrılmasına ve hataların sınırlandırılmasına yardımcı olur.

Ayrıca Bakınız

• Agile Software Development, Principles, Patterns, and Practices - Google Books - Robert C. Martin'in yazılım mühendisliği ilkelerini ve "Tek Sorumluluk İlkesi"ni açıkladığı eseri.
• On the Criteria To Be Used in Decomposing Systems into Modules - ACM Digital Library - David L. Parnas'ın yazılım bileşenlerinin modüllere ayrılmasına dair önerilerini içeren önemli makale.
• On the Role of Scientific Thought - ACM Digital Library - Edsger W. Dijkstra'nın, yazılım mühendisliğinde “Ayrık Kaygılar” (Separation of Concerns) ilkesini tanıttığı makale.
• Patterns of Enterprise Application Architecture - Amazon - Martin Fowler'ın yazılım mimarisi üzerine önemli bir kitabı, özellikle modülerlik ve sorumluluk ayrımı üzerine derinlemesine bilgiler içerir.
• Clean Code Blog - Robert C. Martin'in yazılım geliştirme üzerine önerilerini paylaştığı blog.