Arayüzlerin Ayrımı Prensibi (ISP: Interface Segregation Principle)

Merhaba her türlü prensibi en iyi şekilde öğrenerek; nesne yönelimli programlamanın kral adayı olan sevgili dostlarım (yuh, Bu nasıl bir giriş!). Bu yazımda sizlere SOLID’in I’si olan Interface Segregation Prensibini (ISP) anlatacağım. Aslında bu prensibi ilk bakışta SRP (Single Responsibility Principle) ilkesinin Interface üzerine uygulanması olarak düşünebilirsiniz. Yanılmış da olmazsınız. Fakat ben yine de konuyu,…

26/09/2013 by turkayurkmez

Merhaba her türlü prensibi en iyi şekilde öğrenerek; nesne yönelimli programlamanın kral adayı olan sevgili dostlarım (yuh, Bu nasıl bir giriş!).

Bu yazımda sizlere SOLID’in I’si olan Interface Segregation Prensibini (ISP) anlatacağım. Aslında bu prensibi ilk bakışta SRP (Single Responsibility Principle) ilkesinin Interface üzerine uygulanması olarak düşünebilirsiniz. Yanılmış da olmazsınız. Fakat ben yine de konuyu, biraz detaylarına inerek (tabii sizi de sıkmamaya çalışarak) ele alacağım. Hadi başlayalım öyleyse.

 

ISP’nin genel tanım cümlesini ele alarak başlayalım: “nesneler, ihtiyaç duymadıkları metotların bulunduğu Interface’lere bağlı olmaya zorlanmamalıdır”.

Bu prensibi de basit bir örnek üzerinden anlatsam hiç de fena olmaz sanırım.

Efendim günümüzde, “akıllı cep telefonu” dediğimiz bir kavram var artık. Yani, numara çevirip sohbet etmek ve SMS göndermenin yanı sıra çok daha fazla iş yapan cihazlar. Fotoğraf ve video çekebiliyor, sosyal ağlara bağlanabiliyor, e-postalarınızı kontrol edebiliyorsunuz. Fakat bu yetenekler birbirlerinden tamamen izole edilmiş durumda öyle değil mi? Kesinlikle birbirlerine karışmıyorlar! Yani düşünsenize yolda yürürken harika bir görüntü ile karşılaşıyorsunuz; fotoğraf çekmek için akıllı telefonunuzu alıyorsunuz. Fakat o da ne! Tam fotoğraf çekmek üzereyken akıllı cihazınız size çevrilmesi gereken numarayı soruyor! Hiç de hoş bir durum olmazdı.

Bu örnekte de gördüğünüz üzere, telefonun o anki modülü (örneğin kamera) sadece ilgili Interface ile iletişim halinde kalacaktır. Bu sayede siz, daha geliştirilebilir bir mimari oluşturmuş oldunuz. Şimdi de gelelim gerçek bir kod örneğine…

Senaryomuz, bir sosyal mesajlaşma platformu olsun. Bu platformun üyeleri birbirlerine sesli, görüntülü veya sadece metin mesajı gönderebilirler. Sizde mimari açıdan bir interface tasarlamanın uygun olduğuna karar verdiniz ve aşağıdaki gibi bir interface oluşturdunuz:

Ardından da Mesaj sınıfınızı bu Interface’i implemente ederek oluşturdunuz:

Sorun:

Yine her şey yolunda gözüküyor olabilir. Ancak mesaj nesnesi her zaman bir resme ya da videoya sahip olacak mı? Yani istemci-sunucu arasında trafikte olacak bu nesne, sadece metin mesajı içeriyorsa ImageWidth, MovieDuration gibi özellikleri kullanmama gerek var mı sizce? Evet, bence de yok! IMessage interface’ini biraz daha sadeleştirerek bu mimari sorunu çözebiliriz sanırım.

Çözüm:

IMessage interface’inin birçok amaca hizmet ettiğini görebiliyoruz. Şimdi tek yapmamız gereken, bu amaçları birbirinden ayırmak.

  1. Tüm mesajlaşmalar From, To ve MessageBody özelliklerini içermek zorunda.
  2. Resim içeren mesajlar, AttachImage metodunu ve ImageWidth, ImageHeight özelliklerini ve taşımak zorunda.
  3. Video içeren mesajlar, AttachMovie metodunu ve MovieDuration özelliğini içermek zorunda.

O halde işte çözüm:

Böylelikle; sadece ihtiyaç duyulan interface’lere bağlı olan nesneler geliştirme şansım var. Şöyle ki:

Artık elinizde daha geliştirilebilir bir tasarım var! Ayrı interface’ler ve daha temiz bir mimari…

Yorumlarınızı bekliyorum dostlar.

 

 

 

 

 

 

 

 

 

 

Leave a Reply

7 Comments

  • Selcuk GURAL

    Sade, anlaşılması-hazmedilmesi kolay bir yazı olmuş her zaman ki gibi. Tam bi Evli ve şişman adam makalesi olmuş 🙂

  • turkayurkmez

    Bir resim eksikti… Düzeltildi…

  • Sedat

    Bana Interface Injection'i andirdi. Boyle bir mimari uzerinde yol cikmak, gereksiz methodlari kullanilmayacak siniflardan ayiklamak ve bu methodlari gereksiz yere implement etmekten yazilimciyi kurtarmak icin cok akillica bir yontem.

    Ellerine saglik.

  • Kaan

    Dependency injection'dan tek farkı iki ayrı class oluşturuluyor sanırım . Fakat neden böyle birşeye ihtiyaç duyulsun o tarafını anlayamıyorum. Diyelim gereksiz bir method var , kullanılmayacaksa kullanılmaz. Bunun performans tarafında kayda değer bir getirisi var mı ? İkincisi iki ayrı sınıf , bu iki ayrı sınıfa implemente olmuş iki ayrı interface var . Bu neyi kolaylaştırıyor ? İki ayrı interface'i de implemente eden tek bir sınıfı sadece ihtiyacımız olan methodları içeren interface'den türetsek bi derece … Beni aydınlatabilirseniz sevinirim hocam .

  • mehmet

    İlginç çünkü bu derece interface ayrılan bir örnekte aslında zaten class düzeyine inmiş olunmuyor mu ? Belki örnek yazı içinde anlaşılması için dar kapsamda verildiğinden öyle görünüyor.Emeğiniz için teşekkürler. Güzel anlatmışsınız.

  • En heyecanlı yerinde resim 404 veriyor 🙂
    Elinize sağlık.