Innere Werte, Teil 1: Symmetrie
Qualität ist das beste Rezept, hieß es einst in einer Fernsehwerbung. Neben extern beobachtbarer Qualität besitzt eine Architektur hoffentlich auch innere Werte. Was darunter zu verstehen ist, sollen meine nächsten Threads illustrieren. In diesem ersten Teil geht es um Symmetrie.
- Dr. Michael Stal
Qualität ist das beste Rezept, hieß es einst in einer Fernsehwerbung. Neben extern beobachtbarer Qualität besitzt eine Architektur hoffentlich auch innere Werte. Was darunter zu verstehen ist, sollen meine nächsten Threads illustrieren. In diesem ersten Teil geht es um Symmetrie.
Innere und äußere Schönheit
Es gibt eine ganze Reihe von Definitionen für Qualität. Für mich ist Qualität in Bezug auf Softwarearchitektur der Grad, mit dem das Softwaresystem eine gewünschte Eigenschaft erfüllt. Qualität kann zuweilen sehr subjektiv sein wie beispielsweise bei Ergonomie, aber manchmal auch objektiv und messbar wie zum Beispiel bei der Antwortzeit.
- Externe Qualität bezieht sich auf nichtfunktionale Eigenschaften des Systems. Beispiele: Verfügbarkeit, Änderbarkeit.
- Interne bzw. innere Qualität beschreibt die Einfachheit des Verwendens einer Codebasis oder Architektur. "Verwenden" ist in diesem Zusammenhang sehr vielschichtig und kann sich unter anderem auf Verstehen, Ändern, Erweitern von Codebasis bzw. Architektur beziehen. In gewisser Weise spiegelt der Begriff Schönheit ebenfalls interne Qualität wieder. Metriken versuchen übrigens interne Qualität messbar zu machen, was ihnen nicht immer gelingt, aber das ist eine andere Geschichte.
Es gibt verschiedene Facetten interner Qualität. Im vorliegenden ersten Teil beschäftige ich mich mit Symmetrie.
Arten von Symmetrie
Es gibt verschiedene Varianten von Symmetrie.
- Strukturelle Symmetrie merkt man sich am besten mit der Eselsbrücke "Wo eine öffnende Klammer ist, darf eine schließende Klammer nicht fehlen". Zum Beispiel erwarten wir intuitiv nach einem FileOpen() ein FileClose(), nach einem BeginTransaction() ein Commit() oder Rollback(). Analysieren wir das AbstractFactory-Muster unter Symmetrieaspekten, wundern wir uns darüber, warum es dort ein create() aber kein delete() gibt. Wenn das Erzeugen eines Objekts so komplex ist, dass wir es hinter create() verstecken müssen, gilt es dann nicht auch für das Zerstören?
- Funktionale Symmetrie ist ein anderer Begriff für konzeptionelle Integrität. Wenn wir zur Lösung eines Problems ein bestimmtes Design(pattern) verwenden, sollten wir für jedes andere Auftreten dieses Problems dieselbe Lösung nutzen. Andernfalls müsste man zum Verstehen der Architektur/Codebasis immer mehrere Lösungsansätze verstehen. Negativbeispiel: In der Klassenbibliothek Microsoft Foundation Classes (MFC) gab es gut ein Dutzend verschiedener String-Klassen, was zu sehr komplexen Entwürfen führen konnte.
Auch Asymmetrie hat ihren Platz
Ist also Symmetrie immer der bessere Ansatz, das heißt der Ansatz mit der höchsten internen Qualität? Nein, denn manchmal kann Asymmetrie die einzige Option oder sogar die bessere Lösung sein.
- Strukturelle Asymmetrie - Eine Ressource muss nicht notwendigerweise von dem freigegeben werden, der sie akquiriert hat. Beispiel: verteilte Systeme.
- Funktionale Asymmetrie - Es könnte sinnvoll sein, verschiedene Lösungen für das gleiche Problem zu nutzen. Beispiel: Das Observer-Pattern für Ereignismeldungen in einer Geschäftsanwendung, aber eine festverdrahtete Liste von Beobachtern in einem eingebetteten System, um dynamische Änderungen zu vermeiden.
Symmetrie ist also ein Indikator für gute Interne Qualität, aber kein Beweis.
Suchen Sie doch einmal in ihrem eigenen Design nach Symmetrie und Asymmetrie und bewerten sie die entsprechenden Lösungsansätze. ()
