Abstraktion im Software Engineering

Diskussionen über Abstraktion können sehr abstrakt sein. Doch was bedeutet Abstraktion genau, und was haben Entwickler und Architekten davon.

Diesmal ein etwas philosophisch angehauchter Gedankengang über das Thema Abstraktion. Anlass war eine Diskussion zu einem meiner letzten Posts. Dort gab es einen regen Gedankenaustausch bezüglich Abstraktion im Allgemeinen und guter Abstraktion im Speziellen. Besonderer Dank an Ommadawn für die guten Anregungen.

Laut Wikipedia ist Abstraktion in der Informatik definiert als die Zielsetzung einer

praktikablen Reduktion der Duplikation von Information in einem Programm (üblicherweise mit Fokus auf Information) durch Nutzung von Abstraktionen der Programmiersprache oder von Bibliotheken.

Das bedeutet zum Beispiel, dass jede Klasse oder jede Prozedur eine Abstraktion repräsentiert. Vereinfacht ausgedrückt, haben wir es also mit dem DRY-Prinzip (Don't Repeat Yourself) zu tun.

Webopedia sieht darüber hinaus eine enge Beziehung von Abstraktion zu Kapselung und zum Geheimnisprinzip. Durch diese Definition ist allerdings noch nichts gewonnen, obwohl sie faktisch richtig ist.

Geht man das Thema pseudophilosophisch an, gibt es folgende Definition (Wikipedia).

Abstraktion in seiner hauptsächlichen Bedeutung definiert den konzeptionellen Prozess, der generelle Regeln und Konzepte aus der Verwendung und der Klassifikation konkreter Beispiele, Wortverwendungen, Prinzipien, oder anderer Methoden ableitet. "Abstraktion" ist das Ergebnis dieses Prozesses – ein Konzept  als Superkategorisierungsbegriff für alle untergeordneten Konzepte, das verwandte Konzepte zu einer Gruppe, einem Feld oder einer Kategorie verbindet.

Insgesamt lässt sich also sagen: Die Gruppierung verwandter Konzepte zu einer übergeordneten Kategorie ist Abstraktion und hilft beim Entwurf, unnötige Reduktion zu vermeiden. Insofern sind wir jetzt also schlauer, aber nicht viel.

Wir haben es bei der Softwareentwicklung ständig mit Abstraktion zu tun. Nicht umsonst herrscht in unserer Disziplin eine Inflation an Metaphern wie Klasse, Baum, Fenster, Sprint. Oft wird bei Diskussionen über Metaphern die Erkenntnis "Ein Bild sagt mehr als 1000 Worte" in den Raum geworfen. An dieser Stelle sei aber erwähnt, dass das Ganze auch umgekehrt funktioniert: "Ein Wort sagt mehr als 1000 Bilder". Beide Aussagen haben aber denselben Hintergrund. Eine als Metapher formulierte Abstraktion steht stellvertretend für eine ganze Kategorie konzeptionell verwandter Objekte.

Wann aber sind Abstraktionen sinnvoll und wann nicht?

Das beste Beispiel einer sinnvollen Abstraktion sind meiner Ansicht nach Softwaremuster. Nehmen wir das Observer-Muster. Sobald es im Entwurf auftaucht, wissen wir, was damit gemeint ist. Das erleichtert die Einarbeitung in eine Architektur, weil man nicht mehr in die Details gehen muss. Das Design erschließt sich somit dank guter Metaphern recht schnell. Patterns bilden gleichsam die Substantive einer Sprache.

Die Abstraktion muss natürlich in den Kontext passen und in sich stimmig sein. Ein Observer-Muster, das in eine Architektur gezwängt wird, obwohl der Anwendungskontext nicht passt, wirkt deplatziert und arbeitet dem Architekturverständnis entgegen. Ein Singleton-Muster mag zwar anwendbar sein, führt aber zu globalen Zuständen und damit zu schlechter durchschaubaren Designs.

Im Optimalfall bilden Abstraktionen eine verständliche Sprache. Abstraktion ist keine Insel, sondern  dann besonders effektiv, wenn sie mit anderen Abstraktionen harmonisch zusammenwirken kann. Etwa Observer als Bestandteil von Model View Controller. Oder die Kombination aus Forwarder-Receiver, Proxy und dem Broker Pattern.

Die gewählten Abstraktionen und Metaphern sollten eine runde Geschichte ohne logische Brüche erzählen. Aus demselben Grund sollte eine Vererbungshierarchie für die anvisierte Zielgruppe – Entwickler, Tester – gut nachvollziehbar und nutzbar sein.

Nicht bei Patchworks

Für Patchwork-Architekturen gilt das per Definition nicht. Nur zu dumm, dass auch die allerbesten Architekturen ohne kontinuierliche Pflege zu Patchworks erodieren. Architekturabstraktionen vor negativen Einflüssen zu schützen, kostet hohen Aufwand, und nicht jede Organisation ist bereit, diesen zu spendieren. Das lässt sich übrigens auch bei Programmiersprachen beobachten, die ihrerseits nur so von Abstraktionen strotzen.

Der idiomatische Ansatz ist insbesondere für Frameworks, Bibliotheken, Klassen, Komponenten relevant, weil diese Entitäten als Blaupausen oder Bausteine von Anwendungen dienen. Damit herrschen hohe Erwartungen hinsichtlich deren einfacher Verwendbarkeit. Dem Konsumenten dieser Artefakte muss sich deren Bedeutung möglichst gut erschließen. Das Principle of least Surprise sollte immer den Ton angeben. Schließlich will keiner einen Hammer kaufen, zu dem er erst die Bedienanleitung lesen muss. Frameworks wie .NET oder das JDK gehören hier zu den Musterknaben. 

Lässt sich die Güte einer Abstraktion objektiv beurteilen? Nur teilweise. Automatisieren lässt sich diese Beurteilung aber nicht, solange Werkzeuge die Semantik nicht verstehen. Und wie steht es mit einer subjektiven Einschätzung? Das funktioniert, sollte aber in einem festgelegten Anwendungskontext erfolgen. Etwa in puncto Verständlichkeit und Handhabbarkeit des Entwurfs.  

Eine Abstraktion sollte also in ein harmonisches Gefüge von Abstraktionen eingebettet sein. Zudem sollten Abstraktionen relativ zum Anwendungskontext selbsterklärend sein. Abstraktion ist die Grundlage einer idiomatischen Sprache, die sich einer Zielgruppe gut und nahezu selbsterklärend erschließt. ()