Interface Segregation Principle

Problem

Antag at du har udviklet en RandomNumberGenerator klasse du er ret tilfreds med. Klassen tjener sit formål og kan gentagne gange præsentere en “tilfældig” række af de samme tal. Men, du indser at kravene til generatoren ændrer sig således at den på tværs af kald ikke længere kan nøjes med at returnere den samme række af tal (for hvor tilfældigt er det?), men fra gang til gang må præsentere en ny tal række.

Undersøges litteraturen finder vi ud af at pseudo random number generators benytter sig af en “seed” værdi til at opnå de forskellige talrækker og det er derfor fristende at nedarve den eksisterende klasse og lade den implementere et nys indført ISeedable interface som netop kan stille med en seed værdi.

Overtrædelse af ISP

Problemet er blot, at vi med denne løsning overtræder ISP princippet idet vores RandomNumberGenerator klasse ikke har brug for seed værdien, men bliver tvunget til at afhænge af ISeedable pga. den nedarvede SeededRandomNumberGenerator implementation.

En mulig løsning

Der er i virkeligheden flere måder hvorpå vi kan genoprette ISP overtrædelsen, men een af måderne er ved at huske på reglen:

Adskilte klienter betyder adskilte interfaces

Seeder klassen har i ovenstående eksempel brug for at videregive sine seed værdier via ISeedable interfacet. SeededRandomNumberGenerator klassen har brug for RandomNumberGenerator klassen (“interfacet”) i sin implementation.

Men, de to klasser, Seeder og SeededRandomNumberGenerator, er adskilte hvorfor deres interfaces også bør være adskilte!

Fix af ISP overtrædelse

Vi bryder med den tvungne arv af ISeedable og benytter kun interfacet i SeededRandomNumberGenerator, hvor der er behov for det.

Andre løsninger kunne være brugen af Adapter design pattern’et med delegering som anført i [1].

Referencer

[1] “Agile, Principles, Patterns and Practices in C#”, Martin/Martin