Orthogonalität in der Softwareentwicklung

Orthogonalität

In der Softwareentwicklung wird ein System als orthogonal betrachtet, wenn durch Ändern einer seiner Komponenten nur der Status dieser Komponente geändert wird.

Stellen Sie sich zum Beispiel ein Programm mit drei Variablen vor: a, b und c. Das Ändern des Werts von a sollte den Wert von b oder c nicht ändern, vorausgesetzt, sie sind unabhängig.

Diese Eigenschaft ist beim Debuggen eines Programms besonders wichtig, da die Anzahl der beweglichen Teile eines Programms eingegrenzt werden muss, um die Hauptursache des Problems zu ermitteln.

Siehe das folgende Zitat aus Eric S. Raymonds „Art of UNIX-Programmierung“:

Orthogonalität ist eine der wichtigsten Eigenschaften, die dazu beitragen können, auch komplexe Designs kompakt zu gestalten. In einem rein orthogonalen Design haben Operationen keine Nebenwirkungen. Jede Aktion (ob es sich um einen API-Aufruf, einen Makroaufruf oder eine Sprachoperation handelt) ändert nur eine Sache, ohne andere zu beeinflussen. Es gibt nur eine Möglichkeit, jede Eigenschaft des von Ihnen gesteuerten Systems zu ändern.

Orthogonalität ist ein Software-Design-Prinzip zum Schreiben von Komponenten, bei dem das Ändern einer Komponente keine Auswirkungen auf andere Komponenten hat. Es ist die Kombination von zwei anderen Prinzipien, nämlich starker Zusammenhalt und lockerer Kopplung.

Es ist eigentlich ein Begriff aus der Mathematik entlehnt. Beispielsweise sind zwei Linien orthogonal, wenn sie senkrecht sind. Beim Software-Design sind zwei Komponenten orthogonal, wenn eine Änderung der einen die andere nicht beeinflusst.

Die Anwendung dieses Konzepts auf Klassen oder andere Codeabschnitte führt zu einer geringeren Kopplung. Um orthogonal zu sein, können zwei Klassen nicht voneinander abhängen. Sie können auch keine globalen Daten gemeinsam nutzen. Das Ändern der Interna einer Klasse wirkt sich nicht auf die andere Klasse aus. Komponenten sollten unabhängig sein und nur eine einzige Verantwortung haben.

Stellen Sie sich eine Methode vor, die eine Liste von Zahlen aus einer Datei liest und sie in sortierter Reihenfolge zurückgibt. Jetzt ändern sich die Anforderungen und die Nummern befinden sich in einer Datenbank. Wenn Sie diese Methode ändern, um auf die Datenbank zuzugreifen, ändert sich der Clientcode. Wenn dies zwei verschiedene Methoden wären, würde eine neue Quelle die Sortiermethode nicht beeinflussen. Nur der Client-Code müsste die Quelle der Zahlen kennen.

Starker Zusammenhalt

Innerhalb einer Softwarekomponente sollte der Code stark verbunden sein. Dies ist ein Hinweis darauf, dass der Code korrekt aufgeteilt ist.

Wenn eine Komponente zwei oder mehr relativ getrennte Teile hatte, kann dies darauf hinweisen, dass sich diese Teile in einer anderen Komponente oder allein befinden sollten.

Lose Kopplung

Zwischen Softwarekomponenten sollten nur wenige Verbindungen bestehen. Wenn zwei Komponenten stark gekoppelt sind, kann dies darauf hinweisen, dass sie eine Komponente sein müssen oder dass sie unterschiedlich in mehrere Komponenten unterteilt werden müssen.