SOLID -Single Responsibility Principle-Tek Sorumluluk İlkesi (SRP)
SOLID, nesne tabanlı yazılım geliştirmede en popüler tasarım ilkelerinden biridir. Aşağıdaki beş tasarım ilkesi için anımsatıcı bir kısaltmadır:
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Hepsi geniş çapta kullanılıyor ve bilmeye değer. Ama serilerimin bu ilk yazısında, SOLID ilkeleriyle ilgili olarak, birinciye odaklanacağım:
S - Single Responsibility Principle-Tek Sorumluluk İlkesi (SRP)
Robert C. Martin şöyle tanımlar:
Bir sınıfın değişmesi gereken tek ve tek bir nedeni olmalıdır.
Robert C. Martin veya onun popüler kitaplarını hiç duymamış olsanız bile, muhtemelen bu prensibi duymuş ve kullanmış olmalısınız. Çoğu geliştiricinin sağlam ve sürdürülebilir yazılım oluşturmak için uyguladığı temel ilkelerden biridir. Bunu sadece sınıflara değil aynı zamanda yazılım bileşenlerine ve mikro servislere de uygulayabilirsiniz .
Tek sorumluluk ilkesinin faydaları
Bu tasarım prensibine daha derin dalmadan önce en önemli soruları ele alalım: Neden kullanmalı ve bunu görmezden gelirseniz ne olur?
Tek sorumluluk ilkesi argümanı nispeten basittir: yazılımınızın uygulanmasını kolaylaştırır ve gelecekteki değişikliklerin beklenmedik yan etkilerini önler.Bir sınıfın değişmesi gereken tek ve tek bir nedeni olmalıdır.İhtiyaçlar değiştiğinde, bu kodun bir miktar rekonstrüksiyona tabi tutulması gerektiğini, yani sınıfların değiştirilmesi gerektiğini gösterir. Bir sınıfın sahip olduğu daha fazla sorumluluk, daha fazla değişim isteğini alacaktır ve bu değişikliklerin uygulanması daha zor olacaktır. Bir sınıfın sorumlulukları, bir diğeriyle birleştirilir, çünkü sorumluluklardan birindeki değişiklikler, diğer sorumlulukların bu sınıf tarafından düzgün bir şekilde ele alınması için ek değişikliklere yol açabilir.
-
Sorumluluk nedir?
Bir sorumluluk, değişim sebebi olarak tanımlanabilir. Kodumuzun bir kısmının potansiyel olarak bir sorumluluk olduğunu düşündüğümüzde, onu sınıftan ayırmayı düşünmeliyiz. İnsanların toplumlarında daha aktif olmalarına yardımcı olan bir projede çalıştığımızı ve sistemin sosyal medya entegrasyonuna sahip olması gerektiğini varsayalım. Sosyal medya entegrasyon sorumluluğunu sistemin diğer bölümlerinden ayırmak iyi bir fikir olacaktır, çünkü her zaman dışsal değişiklikler için hazırlanmalıyız.
Hepimiz şartların zaman içinde değiştiğini biliyoruz. Her biri de en az bir sınıfın sorumluluğunu değiştirir. Sınıfınızın sahip olduğu daha fazla sorumluluk, daha sık değiştirmeniz gerekir. Eğer sınıfınız birden fazla sorumluluk alıyorsa, artık birbirinden bağımsız değillerdir.
Sorumluluklarından biri değiştiği anda sınıfınızı değiştirmeniz gerekir. Belli ki, sadece bir sorumluluğu varsa değiştirmek zorunda olmanız gerekenden daha sık görülür.
Bu büyük bir sorun gibi görünmeyebilir, ancak aynı zamanda değişen sınıfa bağlı olan tüm sınıfları veya bileşenleri de etkiler. Değişikliğinize bağlı olarak, değişimlerinizden doğrudan etkilenmese de bağımlılıkları güncellemeniz veya bağımlı sınıfları yeniden derlemeniz gerekebilir. Sadece sınıfınız tarafından uygulanan diğer sorumluluklardan birini kullanırlar, ancak yine de bunları güncellemeniz gerekir.
Sonunda, sınıfınızı daha sık değiştirmeniz gerekiyor ve her değişiklik daha karmaşık, daha fazla yan etkiye sahip ve olması gerekenden çok daha fazla iş gerektiriyor. Bu nedenle, her bir sınıfın sadece bir sorumluluğu olduğundan emin olarak bu problemlerden kaçınmak daha iyidir.
Anlaşılması daha kolay
Tek sorumluluk ilkesi bir başka önemli fayda sağlar. Sadece bir sorumluluğu olan sınıflar, yazılım bileşenleri ve mikro servisler, her şey için bir çözüm sağlayanlardan daha açıklamak, anlamak ve uygulamaktan daha kolaydır. Bu, hataların sayısını azaltır, geliştirme hızınızı geliştirir ve bir yazılım geliştiricisi olarak hayatınızı kolaylaştırır.
Tasarımınızı doğrulamak için basit bir soru
Ne yazık ki, tek sorumluluk ilkesini takip etmek çoğu zaman olduğundan çok daha kolay geliyor.
Yazılımınızı daha uzun bir süre içinde kuruyorsanız ve bunları değişen gereksinimlere uyarlamanız gerekiyorsa, en kolay ve en hızlı yaklaşım, yeni bir sınıf veya bileşen yazmak yerine mevcut kodunuza bir yöntem veya işlev ekliyor gibi görünebilir. Ancak bu genellikle sorumluluktan daha fazlasıyla sınıflara neden olur ve yazılımı sürdürmeyi daha da zorlaştırır.
Herhangi bir değişiklik yapmadan önce basit bir soru sorarak bu problemlerden kaçınabilirsiniz: Sınıf / bileşen / mikroservisinizin sorumluluğu nedir?
Cevabınız “ve” kelimesini içeriyorsa, büyük olasılıkla tek sorumluluk ilkesini ihlal ediyorsunuz demektir. Öyleyse geri adım atıp mevcut yaklaşımınızı yeniden düşünün.
Bu prensibi anlamaya ve yorumlamaya en iyi örnek aşağıdaki ekran görüntüsü olabilir.
Resmi özetleyecek olursak ,Prensibe uyan ve uymayan olarak resmi özetleyebiliriz.
Automobile adlı class’ımız mevcut ve kötü kullanımda tüm işlemler bu class üzerinden yürütülmekte.Doğru kullanım ise bu class parçalanarak ilgili metodlar ilgili class üzerinde konumlandırılarak kullanımı ve yorumlaması iyi konuma getirilmiştir.
Özet:
Tek sorumluluk ilkesi, nesne yönelimli programlamanın en yaygın kullanılan tasarım ilkelerinden biridir. Sınıflara, yazılım bileşenlerine ve mikro servislere uygulayabilirsiniz.
Bu ilkeyi uygulamak için, sınıfınızın birden fazla sorumluluğa sahip olmasına izin verilmez, örneğin, varlıkların yönetimi veya veri türlerinin dönüştürülmesi gibi. Bu, sorumluluklar arasında gereksiz, teknik bir bağlantıyı önler ve sınıfınızı değiştirmeniz için gereken olasılıkları azaltır. Ayrıca, her değişikliğin karmaşıklığını azaltır, çünkü etkilenen bağımlı sınıfların sayısını azaltır.