Interface Segregation Principle
Interface'ler sınıflarla anlaşmalı bir şekilde çalışırlar. Bir sınıfa implement edilen bir interface, o sınıfa uygulanmak zorundadır. Böyle durumlarda Interface'de fazlalıklar ve eksiklikler olabilir. Bu durumda interface'leri ayırmak bu sorunumuza çözüm sağlayacaktır. ISP prensibi bu mantık ile hemen hemen her farklı yetenek için bir interface tanımlamasını önerir.
Interface içinde her türlü metodu ve işlemi barındırmamız, interface'i implement edecek sınıfta kullanmak bize Dummy(sahte) Code olarak adlandırdığımız niteliksiz olarak yer işgal edecek ve bir nevi fazla sorumluluğu olan interface'ler oluşturmuş olacağız. Bu durumda hem "Single Responsibility" prensibine hem de "NotImplementException" dolu metotlar oluşturacağı için "Liskov Substution" prensibine uymamış olacağız.
Bu durumda interface'in elemanlarını işlevlerine göre gruplamak ve bunları farklı interface'ler içinde barındırmak uygulama açısından daha iyi olacaktır. Böylece sınıfların implement ettikleri interface'ler için gereksiz elemanların kullanımının zorunluluğunu ortadan kaldırmış olacaktır.
Örnek bir senaryo üzerinden konuyu ele alırsak "IUser" adında bir interface yaratalım ve içinde "Add()" ve "Get()" adında iki metodumuz olsun. Şimdi bu interface'i implement eden "Admin" ve "User" adında iki tane sınıfımız olsun. Senaryomuzda Admin ekleme ve okuma yapabilecekken User sadece okuma yapabilecektir.
Eğer böyle bir yaklaşımla geliştirme yaparsak "User" için "Add()" metodu gereksiz olacaktır. Bu durumda ISP'yi uygularsak yani IUser arayüzünü parçalayıp alt arayüzler oluşturursak daha temiz bir koda sahip oluruz.
Artık User sadece Get() işlemi yapabilirken Admin her iki işlemi birden yapabilecek konuma gelmiştir. Yani her class sadece ihtiyacı olduğu interface aracılığı ile türetilmiştir.
Yorumlar
Yorum Gönder