Seite wählen

Das Interface Segregation Prinzip besagt, dass es besser ist viele kleinere Interfaces zu haben als wenige große.


Je nach Anforderung kann kleines Interface auch etwas anderes bedeuten. Man muss den jeweiligen Fall genau analysieren. Es macht Sinn die Methoden, die in einem Interface definiert werden in Rollen zu unterteilen. Das Extrem ist es für jede Methode ein Interface zu erstellen was besser ist als ein paar wenige interfaces zu haben, die viele Methoden definieren.

Ich führe mal ein langweiliges Beispiel an, und zwar das von einer XMLDocumentType Klasse. Diese implementiert ein Interface namens DocumentType mit den Methoden read() und write(). 
Nun möchte ich aber einen ScreenDocumentType einbauen, welches die Daten einfach nur auf dem Schirm ausgibt und bekanntlich nicht lesen kann. 

Anstatt nun einen zweiten Vererbungsbaum zu erstellen mit einem ScreenDocumentType interface, splitte ich besser das Interface in Rollen auf und implementiere ein Interface zum Lesen (canRead) und eins zum Schreiben (canWrite). Und unser ScreenDocumentType lasse ich nur das interface zum Schreiben implementiert.

Das ist natürlich ein einfaches Beispiel, an dem man den Nutzen vielleicht nicht sofort erkennen kann, aber in komplexen Systemen wirkt sich das aus, da weniger monolithische unflexible Strukturen entstehen, sondern eher kleine flexible Einheiten, die miteinander kombinierbar sind und vor allem, die keinen eigenen neuen Vererbungsbaum benötigen.
Beispiel Code hier: https://github.com/DesertCoderz/InterfaceSegregation