Buradasın
SOLID Prensipleri: Single Responsibility Principle (SRP) Eğitimi
youtube.com/watch?v=VVRCrZsvtP8Yapay zekadan makale özeti
- Kısa
- Ayrıntılı
- Bu video, bir eğitmen tarafından sunulan yazılım tasarım prensiplerinden biri olan Single Responsibility Principle (SRP) hakkında kapsamlı bir eğitim dersidir.
- Videoda SRP prensibi, günlük hayattan örneklerle açıklanarak, bir sınıfın veya metotun mümkün mertebe tek bir sorumluluğa odaklı inşa edilmesi gerektiği vurgulanmaktadır. Eğitmen, birden fazla sorumluluğu üstlenmiş yapıların yönetilebilirliğini zayıflattığını, maliyet artırdığını ve test sürecini zorlaştırdığını örneklerle anlatmaktadır. Ayrıca, veritabanı bağlantısı gibi işlemlerin tek bir sınıfta toplanması gerektiği, ancak personları getiren fonksiyonun bu sınıfın dışında olması gerektiği gibi pratik uygulamalar da gösterilmektedir.
- Video, tek sorumluluk prensibine uygun ve aykırı sınıf tasarımlarını karşılaştırarak doğru kodlama yaklaşımını göstermekte ve bir sonraki derste Open Closed Principle'ın inceleneceği bilgisiyle sonlanmaktadır.
- Tek Sorumluluk Prensibi Tanıtımı
- Bu derste yazılım prensipleri serisinin ilk bölümü olan Tek Sorumluluk Prensibi (Single Responsibility Principle) ele alınacaktır.
- Tek Sorumluluk Prensibi, gerçek hayattan alınan ve yazılım süreçlerinde uygulanan aklın yolu bir olmanın sonuçlarıdır.
- Günlük hayatta bir kişi aynı anda birden fazla iş yapamaz, bu durumda risk artar ve öngörülemez sonuçlar ortaya çıkabilir.
- 01:26Tek Sorumluluk Prensibinin Önemi
- Tek Sorumluluk Prensibi, bir şeyin tek bir sorumluluğa odaklı şekilde inşa edilmesinin ilkesini dayatmaktadır.
- İnsanlık, aynı anda birden fazla işi yapmanın maliyetinin hiç yapmamaktan daha fazla olduğunu ve risk oranının arttığını bilmektedir.
- Verimli çalışabilmek için her zaman tek bir işe, tek bir sorumluluğa odaklı çalışmak gerekir.
- 03:33Tek Sorumluluk Prensibinin Yazılım Tasarımında Uygulanması
- Yazılım süreçlerinde de inşa edilen kodların mümkün mertebe tek bir sorumluluğa odaklanmış şekilde inşa edilmesi önerilmektedir.
- Tek Sorumluluk Prensibi, tasarımlarında bir sınıfın mümkün mertebe tek bir sorumluluğa odaklı inşa edilmesi gerektiğini ilke olarak savunmaktadır.
- Geliştirilen sınıflar tek bir işe, tek bir sorumluluğa odaklı şekilde geliştirilmelidir.
- 05:03Tek Sorumluluk Prensibinin Değerlendirilmesi
- Bir sınıfın değiştirilmesi gereken birden fazla sebebi, motivasyonu veya gerekçesi varsa, bu durum ilgili sınıfın birden fazla sorumluluğu olduğu anlamına gelir.
- SRP'ye uygunluk durumu, bir sınıfın değiştirilmesi gereken birden fazla sebebiyet durumuyla ters orantılıdır.
- Birden fazla değişiklik sebebiyle bir sınıfa müdahale ediliyorsa, bu sınıfın birden fazla sorumluluk sahibi olduğu anlaşılır ve parçalanması gerekir.
- 07:30Tek Sorumluluk Prensibinin Genel Sloganı
- SRP, bir sınıfın değişmesi için tek bir nedeni olması gerektiğini ifade etmekte ve inşa edilen kodun bu hassasiyetle üretilmesini savunmaktadır.
- İdeal tasarım her sınıfın tek bir sorumluluğu olmasıdır.
- Bir sınıf veya metot aynı anda birden fazla sorumluluk üstlenmemelidir, sorumluluklar mümkün mertebe parçalanmalıdır.
- 09:36Tek Sorumluluk Prensibi
- Bir sınıf veya metot işlevsel olarak birden fazla işi yürütüyorsa, bu istenmeyen bir durumdur.
- Günlük hayatta bir insan aynı anda birden fazla iş yükünü kaldıramaz ve verim düşer, benzer şekilde yazılım süreçlerinde de birden fazla sorumluluğun tek bir yapıda toplanması doğru değildir.
- Birden fazla sorumluluğun söz konusu olduğu yapılarda herhangi bir sorumluluktaki değişiklik, ilgili yapının üstlendiği diğer sorumlulukların insicamını bozabilir veya yürütülmelerini engelleyebilir.
- 11:29Tek Sorumluluk Prensibinin Uygulanması
- Bir sınıf hem aritmetik hem de metinsel işlemler gerçekleştiriyorsa, bu doğru bir sınıf olmayacaktır ve bu işlemler farklı sınıflara ayrılması gerekir.
- Metot seviyesinde birden fazla sorumluluk ele alındığında, bir problem meydana geldiğinde diğer işlemlerin yürütülmesi engellenebilir.
- İdeal davranış, sorumlulukları ayırmaktır; her bir sorumluluğu farklı bir metoda veya sınıfa ayırmalısınız.
- 14:50Kırılgan Tasarımlar
- Birden fazla sorumluluk üstlenmiş yapıların ortaya çıkarabileceği problemler "kırılgan tasarımlar" olarak nitelendirilmelidir.
- Bir yapının tek başına birden fazla işi üstlenmesi yönetilebilirlik açısından şık bir tasarım değildir.
- Futbol örneğinde olduğu gibi, her bir futbolcu sahada bulunduğu bölgeye hakim olmalıdır; tek bir sorumluluk üstlenirse daha verimli çalışır.
- 17:02Tek Sorumluluk Prensibi
- Yazılım sürecinde her sorumluluk bir işi, her iş bir amacı temsil etmektedir.
- Birden fazla sorumluluk müdahalesi varsa yapı paramparça olur, tek bir aklın ürünü olmaz ve yönetilebilirliği zayıf olur.
- Tek sorumluluk prensibinde, bir bölgede yapılan müdahale sadece o bölgeyi etkiler, diğer bölgeleri etkilemez.
- 19:46Tek Sorumluluk Prensibinin Önemi
- Kodlarımızı mümkün mertebe tek bir sorumluluğa, tek bir gayeye hizmet edecek şekilde oluşturmalıyız.
- Her sorumluluk özünde bir değişim merkezidir çünkü yazılım süreçlerinde sorumlulukları şekillendiren gereksinimler değişken özellik göstermektedir.
- Bir sınıfın birden fazla sorumluluğu varsa, her gereksinim değişikliğinde ekstra maliyete sebebiyet verecektir.
- 22:45Tek Sorumluluk Prensibinin Uygulanması
- Veritabanı örneğinde, veritabanı işlemleri ile person işlemleri tek bir sınıfta tanımlanmamalıdır.
- Veritabanı ile alakalı member'lar database sınıfında, person ile ilgili işlem yapan member metodu ise personal service gibi bir sınıfa alınmalıdır.
- Her sınıf tek bir sorumluluğa odaklı bir şekilde çalışması gerekir, aksi takdirde kodlama süreci doğru olmayacaktır.
- 25:35İdeal Olmayan Kod Yapısı
- Veritabanı bağlantısı ve koparan fonksiyonlar veritabanı ile ilgili doğrudur.
- Veritabanının state'ini veren bir propertiy de veritabanı ile ilgilidir.
- Veritabanından personları getiren fonksiyon veritabanı ile ilgili değil, veritabanı kullanan bir operasyondur ve bu operasyonun database'de olması akıllıca değildir.
- 26:08İdeal Kod Yapısı
- Veritabanı ile ilgili işlemler orijinal sınıfın dışında, ilgili sınıflarda tasarlanmalıdır.
- Person servis sınıfı, person ile ilgili veri ekleme, silme, güncelleme gibi işlemleri barındırmalıdır.
- Database sınıfı sadece veritabanı ile ilgili işlem yaparken, person servis sadece person ile ilgili işlem yapmalıdır.
- 27:44Metot Seviyesinde Ayrım
- Metot seviyesinde de mümkün mertebe fiziksel olarak ayrım ortaya koymak en doğru yaklaşım olacaktır.
- Veritabanına bağlanmak ve bağlantıyı kesmek ayrı iki iş olduğundan, bunları ayrı metotlar üzerinden gerçekleştirmek gerekir.
- Single Responsive Principle, bu şekilde hareket etmeyi önerir.