Ich hatte vor einiger Zeit schon von der Angst vor Logik erzählt. Das ist aber bei Weitem nicht das einzige, wovor einige sich in der OO-Programmierung und im objekt-orientierten Design fürchten. Ein weiteres, vor Allem bei größeren Anwendungen auftretendes Phänomen ist die Angst vor Asymmetrie – oder auch anders ausgedrückt das quasi bedingungslose Streben nach Symmetrie.

Symmetrie im Sinne von objekt-orientiertem Design kann in vielfältiger Weise auftreten. Ein prominentes Beispiel ist die Symmetrie über Schichten hinweg. Da beginnt man trivial mit einem UserAccountDTO und einem UserAccountDAO, bewegt sich dann auf den Business-Layer und erstellt eine UserAccount-Klasse um schlußendlich auf der Präsentationsschicht ein UserAccountController und UserAccountView zu erstellen. Diese Verfahrensweise “fördert” den “Symmetrie-Effekt”, ist aber nicht die einzige Ursache für Design-Symmetrien. Wie dem auch sei, im Ergebnis hat man ein geradezu perfekt symmetrisches Design des UserAccounts über alle Ebenen hinweg geschaffen (Anmerkung: Bei diesem Beispiel der “Layer-Symmetrie” spricht man auch öfter von “linearem Design”).

Auf den ersten Blick ist an so einer Symmetrie ja auch nicht viel auszusetzen: Alles ist ordenlich strukturiert, man findet sich zurecht und kann, mit Unterstützung der Symmetrie, schnell Abhängigkeiten des Systems oder von einzelnen Klassen finden. Dies ist augenscheinlich bei größeren Anwendungen ein Vorteil, denn ähnliche Strukturen und Verfahrensweisen erleichtern nunmal das Verständnis und die Wartung von großen Codeständen.

Jedoch ist Design-Symmetrie ein zweischneidiges und besonders scharfes Schwert. Es gibt einige Entwickler und sogar Architekten, die solche Symmetrien bedingungslos fordern und auf Teufel komm’ raus einzuhalten versuchen. Manche bewußt, manche sogar unbewußt, weil es “woanders ja auch so gemacht ist” oder “schnell von der Hand” geht.

Genau dort setzt sie ein, die Angst vor Asymmetrie. Denn es ist durchaus denkbar und überdies sinnvoll, sich für jedes Geschäftsobjekt oder -szenario Gedanken darüber zu machen, wie man es konzipiert. Dieser Entwurf kann und soll auch hinterfragen dürfen, ob vorhandene infrastrukturelle Systeme oder Konventionen dem gegebenen aktuellen Problem genügen oder nicht. Im Klartext: Konzeptionelle Symmetrie ist kein Zwang, sondern eine vorteilhafte Erscheinung, die aber im Allgemeinen bei Weitem nicht das Gewicht einer funktionalen Anforderung hat.

Um beim obigen Beispiel zu bleiben: Wäre ein “UserAccount” physisch auf der Datenbank auf mehrere Tabellen verteilt (z.B. Accounts, Users, UserSettings) und wäre demnächst z.B. eine User-Setting-Verwaltung angedacht, so wäre es sicherlich erwägenswert, statt mit einem JOIN über diese Tabellen einen UserAccountDAO zu erzwingen einfach drei DTO’s und DAO’s zu erstellen, die dann vom Businessobjekt (dem UserAccount) verwendet werden. Natürlich hängt so eine Entscheidung stark vom Kontext und den Anforderungen ab, aber ich hoffe, ich konnte mit dem Beispiel den Kerngedanken von “Symmetrie vs. Asymmetrie” etwas verdeutlichen.

Ich persönlich empfinde asymmetrische Designs (mit einigen Symmetrien oder Analogien) sogar “schöner”, zumal sie ein deutliches Indiz für starke Objektorientierung sind. In asymmetrischen Konzepten ist die Kohäsion zumeist deutlich stärker, die abstrakte Klassifikation der Objekte ist klar und die Vererbungshierarchien sind zuweilen kürzer. Im Endeffekt sind in meinen Augen solche asymmetrischen Muster in Software-Designs ein erster rudimentärer Ansatz hin zur Adaption von permakulturellem Denken in die Konzeption von Softwarearchitekturen und -systemen.

Mein Fazit: Keine Angst vor Asymmetrie! Auch asymmetrische Strukturen können schön und vor Allem nachhaltig effizient sein.