Birbiriyle ilişkili olmayan birçok metodu ihtiva eden büyük bir interface sınıf yerine, birbiriyle ilişkili (cohesive) metotların yer aldığı birden fazla interface sınıfı daha makbuldür.
ISP uygulanmadığı taktirde, birden fazla sorumluluğu olan interface sınıflar oluşur. Zaman içinde yüklenen yeni sorumluluklarla bu interface sınıflar daha da büyür ve kontrol edilemez bir hale gelebilir. Bunun bir örneğini resim 1 de görmekteyiz.
Resim 1 de yer alan Connector interface sınıfı bünyesinde JMS (Java Message Service) için gerekli iki metot bulunmaktadır: commit ve rollback. Bu metodlarin RMIConnector implementasyonunda implemente edilmeleri anlamsız olur. Büyük bir ihtimalle RMIConnector sınıfında bu metotların implementasyonu kod 1 de yer aldığı şekilde olacaktır.
package shop; public class RMIConnector implements Connector { public void commit() { throw new RuntimeException("not implemented"); } public void rollback() { throw new RuntimeException("not implemented"); } }
Kod 1 de yer alan yapı LSP ile uyumlu değildir. Connector sınıfını kullananlar RuntimeException oluşabileceğini göz önünde bulundurmak zorunda bırakılmaktadırlar.
ISP uygulandığı taktirde resim 1 de yer alan Connector interface sınıfını yok ederek, yerine sorumluluk alanları belli iki yeni interface sınıf oluşturabiliriz. Resim 2 de bu çözüm yer almaktadır.
Programcı olarak bir interface sınıfa birden fazla sorumluluk yüklememek için, interface sınıfın sistemdeki görevini iyi anlamamız gerekmektedir. Bu sadece bir sorumluluk alanı olan bir interface sınıf oluşturmamızı kolaylaştıracaktır.
Bu yazıyı PDF dosyası olarak aşağıdaki linkten edinebilirsiniz.
Interface Segregation Principle (ISP) -Arayüz Ayırma Prensibi (39,0 KiB, 5.613 yükleme)
EOF (End of Fun)
Özcan Acar
Tasarım Prensipleri kategorisinden son yazılar
- Sorumluluk Sahibi Olmak - August 20th, 2012
- SOLID - December 30th, 2011
- Stable Abstractions Principle (SAP) – Stabil Soyutluk Prensibi - October 26th, 2011
- Stable Dependencies Principle (SDP) – Stabil Bağımlılıklar Prensibi - October 26th, 2011
- Acyclic Dependency Principle (ADP) – Çevrimsiz Bağımlılık Prensibi - October 26th, 2011
- Common Closure Principle (CCP) – Ortak Kapama Prensibi - October 26th, 2011
- Common Reuse Principle (CRP) – Ortak Yeniden Kullanım Prensibi - July 24th, 2010
- Reuse-Release Equivalence Principle (REP) - Tekrar Kullanım ve Sürüm Eşitliği - December 9th, 2009
- Dependency Inversion Principle (DIP) - Bağımlılıkların Tersine Çevrilmesi Prensibi - October 29th, 2009
- Liskov Substitution Principle (LSP) – Liskov'un Yerine Geçme Prensibi - October 29th, 2009
hakdogan
17 Kasım 2009Özcan bey değerli çalışmalarınızı ilgi ile takip ediyorum ve katkılarınızın paylaşımınızın devamını diliyorum…
Pingback: SOLID - Kurumsal Java Yazılımı
Ahmet Refik ÖZBEK
06 Aralık 2013Özcan Bey JMSConnector interface sınıfında sadece commit ve rollback metotlarını oluştursak ve bu sınıfı uygulamak isteyen sınıflar hem JMSConnector hem de RMIConnector interface sınıfını uygulasa daha iyi olmaz mı?
Özcan Acar
10 Aralık 2013Bu durumda JMSConnector semantik anlamda tam tesekküllü olmaz. Hem JMSConnector interface sinifini, hem de RMIConnector interface sinifini implemente eden bir sinif nedir? Bence birden fazla sorumluluk altina giren ve iki isi birden yapmaya calisan bir siniftir. Tek sorumluluk prensibine göre siniflarin tek bir nedenden dolayi degistirilmeleri dogaldir.