SOLID prensiplerinin “S”si olan Single Responsibility Prensibi(SRP) yani Tek Sorumluluk Prensibi isminden de anlaşılacağı üzere bir modülün veya bir nesnenin tek bir sorumluluğu olması gerektiğini anlatır. Bu prensibin amacı kodların daha sürdürülebilir ve okunabilir bir yapıda yazılmasıdır.
SRP’nin Avantajları:
- Her bir bileşenin tek bir sorumluluğunun olması kodun daha anlaşılır ve okunabilir olmasını sağlar.
- Bir sorumluluğun değiştirilmesi gerektiğinde sadece ilgili sınıfı etkiler ve bu sayede esnek bir yapı sağlar.
- Gelecekte de proje büyüdükçe her bileşenin tek sorumluluğu olması karmaşıklığı azaltarak bakım sürecini kolaylaştırır.
Örnekle Anlatım:
İlk olarak SRP’ye uymayan bir kullanım ile başlayalım. E-posta göndermek amacıyla yazılmış bir EmailService sınıfımızın olduğunu düşünelim. Aynı zamanda da her eposta gönderdiğimizde bu gönderinin log kaydını tutmak istiyoruz, bunun için de bir LogActivity metodu yazmış olalım.
public class EmailService
{
public void SendEmail(string recipient, string subject, string message)
{
// Eposta göndermek için çalışacak olan kod
// ...
// Eposta gönderme aktivitesini loglayacak olan metod
LogActivity($"{recipient} kullanıcısına eposta gönderildi - Konu: {subject}");
}
private void LogActivity(string activity)
{
// Loglama yapacak kod
// ...
}
}
Bu kodda sizin de gördüğünüz gibi SRP’yi bozan bir durum var, EmailService sınıfının sorumluluğu e-posta göndermekti, ancak log kaydı tutmak için eklediğimiz metod bizim sınıf için planladığımız sorumluluğun dışına çıkmasına sebep oldu.
Bu durumdan kurtulmak için loglama işlemini yapacak ayrı bir sınıf oluşturabiliriz, böylece EmailService sınıfı sorumluluğu dışarısında bir işlem bulundurmamış olur. Örneğin kodu şu şekilde düzenleyebiliriz;
public class EmailService
{
private readonly EmailLogger emailLogger;
public EmailService(EmailLogger emailLogger)
{
this.emailLogger = emailLogger;
}
public void SendEmail(string recipient, string subject, string message)
{
// Eposta göndermek için çalışacak olan kod
// ...
// Log tutmak için gereken metod
emailLogger.LogEmailActivity(recipient, subject);
}
}
public class EmailLogger
{
public void LogEmailActivity(string recipient, string subject)
{
// Loglama yapacak kod
// ...
}
}
Sınıfımızı 2 ayrı sınıfa böldük ve artık iki sınıfımızın da değişmesi, güncellenmesi için yalnızca birer sebep var bu şekilde sorumlulukları ayırarak kodun SRP’ye uygun olmasını sağladık.
Şu ana kadar avantajlardan bahsettik ancak tabii ki SRP’yi uygulamaya çalışırken bazı sorunlarla da karşılaşmak mümkün. Sorumlulukları birbirinden ayırmak isterken bu işlemi abartırsak ve her iş için ayrı bir sınıf tanımlamak istersek karmaşıklığı arttırarak işlerimizi daha çok zorlaştırabiliriz. Bunun önüne geçmek için de internette var olan örnekleri inceleyip pratik yaparak daha çok tecrübe edindikçe daha iyi bir fikir edinebileceğinizi düşünüyorum.
Önceki yazılar:
Sonraki yazılar:
Open-Closed Prensibi
Liskov Substitution Prensibi
Interface Segregation Prensibi
Dependency Inversion Prensibi