SOLID SAM

Ohne sauberes Softwaredesign mündet jedes hinreichend lange Softwareprojekt in eine unwartbare Katastrophe. Jetzt, in diesem Moment, werden Unsummen an Geld aufgrund schlechten Softwaredesigns vernichtet. Sei es, weil Abertausende Entwickler Spaghetti-Code in Softwaredesign-Monolithen zu verstehen versuchen, anstatt neue Features zu entwickeln. Sei es, weil Code-Änderungen in Produkten etliche Seiteneffekte nach sich ziehen, oder schlicht und ergreifend, weil Entwickler aufgrund von Stress und Burn-out erkranken oder gar ihren Job an den Nagel hängen. Denn so macht Softwareentwicklung nun wirklich keinen Spaß.

Motivation

Dieser Beitrag soll dem ein Ende bereiten. Ich stelle euch SOLID SAM vor - ein leicht einprägsamer Entwicklungsansatz, welcher durch den konsequenten Einsatz von Single Abstract Methods (SAM)s eine hohe Codequalität auch in stressigsten Projektsituationen garantiert. Denn man kann beides haben: Extrem schnelle Feature-Entwicklung und zugleich hohe Qualität auf Softwaredesign-Ebene – eben mit SOLID SAM.

Der Mehrwert davon ist, dass es die Anwendung der SOLID-Prinzipien in drei Sätzen ermöglicht. Anstatt das Akronym SOLID Buchstabe für Buchstabe und an Beispielen durchzugehen, was in allen von mir gefundenen (Online-)Artikeln/Beiträgen der Fall war, soll dieser Beitrag die Erklärung quasi auf den Kopf stellen: Es werden zunächst die drei Sätze präsentiert, und erst danach wird erklärt, warum dies automatisch zu SOLIDem Softwaredesign führt.

Die nicht gerade bescheidene Hoffnung dahinter ist recht einfach: Dass dieser Artikel für Leserinnen und Leser einen Wendepunkt in ihrem Leben darstellt. Bereitete der Job vor der Lektüre des Textes Magenschmerzen und war der Chef sauer, brennen die Leser:innen danach für ihren Job, stehen morgens voller Elan auf, und auch der Chef ist am Ende glücklich.

Softwaredesign

Zunächst aber kurz zur Definition des Begriffs „Softwaredesign“. Hierzu hat David Tielke bereits alles gesagt, was es zu sagen gibt (Bild 1). Softwaredesign beschäftigt sich mit der Softwarestruktur auf Klassenebene.

Davids felderprobte Composite-Components-Architektur fußt auf sauberem Softwaredesign, da es eine – wenn auch keine hinreichende, so doch wenigstens notwendige – Bedingung für saubere Softwarearchitektur ist. Daher kann der vorliegende Artikel gewissermaßen als Propädeutik für Davids Composite Components 2.0 gesehen werden.

SOLID SAM

Kommen wir nun aber zum eigentlichen Thema, zu SOLID SAM. Ich möchte mit einem Bild starten, da es mehr als tausend Worte sagt.

Was fällt in Bild 2 auf? Richtig, wir haben nur Interfaces mit einer Methode und implementierende Klassen mit einer (public) Methode. Das führt uns auf direktem Wege zu SOLID SAM und den drei dazugehörigen Sätzen, die da lauten:

• Nutze Paare an einmethodigen Interfaces und Klassen.
• Lasse alle Klassen auf Interfaces zeigen.
• Füge neue Funktionalitäten durch das Einhängen neuer Paare hinzu.

Wer diese drei Sätze beherzigt, ist automatisch SOLID unterwegs:

• Single-Responsibility: Jede Klasse hat eine Hauptaufgabe, vorgegeben durch das implementierte, einmethodige Interface.
• Open-Closed: Wir hängen neue Funktionalitäten durch neue Paare an einmethodigen Interfaces und zugehörigen Klassen ein. Ein Beispiel: Klasse D soll ab sofort irgendetwas validieren, bevor es sein Resultat zurückgibt. Also führen wir Interface E und Klasse E mit jeweils einer (public) Methode ein, welche die Validierung übernimmt, und lassen Klasse D auf Interface E zeigen. Die bestehende Logik von Klasse D wird nicht angefasst, sondern nur um eine weitere Codezeile ergänzt, die die einzige Methode von Interface E aufruft.
• Liskov: Da wir nur gegen Interfaces gehen und von der Vererbung die Finger lassen, können wir nicht böse überrascht werden. Sieht man sich allein die Wikipedia-Beispiele für die Verletzung dieses Prinzips an, wird klar, dass alles Übel daher rührt, dass (ableitende) Klassen von der Implementierung konkreter (Super-)Klassen Gebrauch machen. Aber in unserem Mantra kennt jede Klasse nur Interfaces und kümmert sich ausschließlich um ihren eigenen Kram. Abstrakte Komposition statt konkreter Vererbung.
• Interface Segregation: Geschenkt, denn Interfaces können nicht weniger als eine Methode haben.
• Dependency Inversion: Ebenfalls geschenkt, weil alle Klassen auf Interfaces zeigen.

Das war es auch schon! Jetzt seid ihr an der Reihe – macht euch die Hände schmutzig und wendet SOLID SAM an! Und sollte die Frage „Wohin mit all den ganzen Interfaces und Klassen?“ aufkommen, empfehle ich die Lektüre der „Composite Components 2.0 Architektur“ in [1] und den nachfolgenden Teilen der dotnetpro-Artikelserie, die vorgibt, wie man die Komponenten (== Assemblies in C#) schneidet, in denen man die Klassen und Interfaces für eine maximal gute Qualität auf Softwarearchitektur-Ebene verstaut.

SOLID SAM als Meta-Entwurfsmuster 

In gewisser Weise lässt sich SOLID SAM als Meta-Entwurfsmuster betrachten. Was meine ich damit? Wenn man sich einige der UML-Diagramme von Entwurfsmustern wie Decorator, State oder Observer ansieht, wird man feststellen, dass die grundlegenden Bausteine oft Interfaces mit nur einer Methode (oder sehr schlanke Interfaces) und Klassen sind, die auf diese Interfaces zeigen. Und in der Tat, in meiner beruflichen Praxis bemerke ich oft rückblickend, dass ich durch die Anwendung von SOLID SAM einige Entwurfsmuster oder interessante Mischungen dieser ganz unbewusst und wie von selbst implementiere. 

Zugegeben, manchmal sind Interfaces mit nur einer Methode übertrieben, z. B. wenn wir APIClients und Repositories implementieren, die CRUD-Operationen ausführen, oder bei DTOs. Aber bei einem Großteil der Geschäftslogik, mit der ihr und ich regelmäßig zu tun habt, bin ich positiv überrascht, wie oft SOLID SAM funktioniert. 

Falls ihr Feedback oder Fragen haben, meldet euch gerne – bis zum nächsten mal, alles Gute und viel Spaß bei der Anwendung des hier Gelernten.

Danksagung

Themenspecial Composite Components

In unserem Themenspecial erfährst Du alles rund um Composite Components. Das Architekturprinzip ist gerade in Zeiten von KI ein Garant für die Minimierung der technischen Schulden und des Wildwuchses bei der Softwareentwicklung. 

Durch die strickte Trennung von Interface und Implementierung lässt sich die KI opitimal steuern und im Zaum halten. Gleichzeitig bleibt das Design weiterhin auch für Menschen lesbar und verstehbar. Lerne, wie du mit Composite Components arbeitest.

Lade dir das Themenspecial mit allen Inhalten zu Composite Components herunter. 

[1] David Tielke, Was ist Architektur?, dotnetpro 12/2019, Seite 43 ff., www.dotnetpro.de/A1912DDD 8