Interface Segregation (ISP) Prensibi

interface segregation prensibi

Bir önceki makale Liskov Substitution Prensibinde de yine bu prensibe aslında ışık tutmuş olduk. Solid prensiplerinin dördüncü maddesi Interface Segregation prensibi temel olarak şişman interface’leri hedef almaktadır.

No code should be forced to depend on methods it does not use.

Robert C. Martin

Bir arayüz (interface) düşünün ki; loglama, performans, v.b. işlemlerin tümünü bünyesinde barındırmış olsun. Bu arayüzü gerçekleyen sınıfların tümünün ihtiyacı olsun veya olmasın bu özellikleri gerçeklemesine mahkum bırakılsın. İşte şişman arayüzlerden kastımız tam olarak bu oluyor. Bu arayüzlerin kendisiyle ilgili olan kısımlarının ufak parçalara bölünmesi ve yalnızca ihtiyaç duyacak sınıflar tarafından gerçeklenmesi hedeflenmektedir.

Konuyu bir örnekle pekiştirelim. Senaryoya göre basit kullanıcı işlemlerinin gerçekleştirileceği bir sistem tasarlanması bekleniyor; buna göre sistemde yönetici ve son kullanıcı olmak üzere iki tür kullanıcı olacak.

  • E-posta bildirimlerinin yalnızca son kullanıcılara gönderilmesi,
  • Log işlemlerinin yalnızca yönetici rolündeki kullanıcılara uygulanması beklenmektedir.

Normalde kullanıcılar tek bir tabloda tutulur; ancak biz örneğin pekiştirilmesi amacıyla ayrı varlıklar (entity) oluşturacağız.

Tasarladığımız sistem senaryoya her ne kadar uydurulabiliyor olsa da; beklenen bu değildi. Her iki kullanıcı tipi de tüm işlemleri gerçekleyebiliyor. Gelin kodumuzu refactor edelim, buna öncelikle şişman arayüzümüzden başlayalım.

Ufak parçalara ayırdığımız arayüzleri, beklenen şekilde uygulayalım.

Bu sayede kodumuzun artık ihtiyacı olmayan fonksiyonları gerçeklemesine gerek kalmıyor ve daha esnek hale gelmiş oluyor.

You may also like...

Bir cevap yazın

E-posta hesabınız yayımlanmayacak.