FAQ Page: ISP Principle

Das ISP Principle hilft Embedded-Entwicklern, robuste, wartbare und testbare Software zu schreiben. Gerade bei der Arbeit mit Hardware, RTOS, oder Low-Level-Treibern sorgt die saubere Aufteilung von Interfaces für bessere Testbarkeit und geringere Fehleranfälligkeit. Wenn du in deinem Projekt auf große, unübersichtliche Interfaces triffst: Zerlege sie. Spezialisiere sie. Und befolge das ISP Principle.

Durch die Einhaltung des ISP Principle wird Unit-Testing deutlich einfacher. Für jede Funktionalität kann ein eigenes Mock-Interface verwendet werden: Damit lassen sich einzelne Module isoliert testen – ein großer Vorteil bei CI/CD in Embedded-Projekten.

In der Embedded-Softwareentwicklung bringt das ISP Principle einige Vorteile – aber auch Herausforderungen:

Typische Anzeichen für die Verletzung des ISP Principle:

Wenn man das ISP Principle nicht einhält, entstehen typische Probleme: Gerade in sicherheitskritischen Embedded-Systemen (z. B. Medizintechnik, Automotive, Luftfahrt) kann das schwerwiegende Folgen haben.

Auch wenn C oder C++ keine Interfaces im klassischen Sinne wie Java oder C# kennen, kann man das ISP Principle mit Abstraktionen und Pointer-zu-Funktionen oder reinen abstrakten Klassen umsetzen: Beispiel (C++): Statt eines „Mega-Interfaces“ wie: trennt man die Verantwortlichkeiten auf – genau das ist der Kern vom ISP Principle.

Das ISP Principle besagt: „Clients should not be forced to depend on interfaces they do not use.“(„Klassen sollten nicht gezwungen sein, Schnittstellen zu implementieren, die sie nicht benötigen.“) Mit anderen Worten: Ein Interface soll nur das enthalten, was für seinen Verwender wirklich notwendig ist. Große, „fette“ Interfaces führen dazu, dass Klassen unnötige Abhängigkeiten und Methoden…