Architektur Antipattern

Definition

Das Architektur Antipattern big ball of mud bezeichnet ein System, das keine erkennbare Architektur besitzt.

Wer hat's erfunden?

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated.

(Brian Foote und Joseph Yoder, 1999)

Wer hat schon mud, aber das kennen wir:

• unregulated growth
• repeated, expedient repair
• all the important information becomes global

Den großen ball of mud finden wir hoffentlich selten, aber Teile davon sehen Entwickler täglich. Möchte man das Antipattern auflösen, dann ist eine mögliche Lösung das Facade Pattern.

Facade Pattern

Das Facade Pattern beschreibt ein Muster, bei dem ein Objekt eine vereinfachte Schnittstelle für eine Menge an Unterobjekten bereitstellt.

1. Wenn man eine facace über eine library stülpt, dann ist die Anwendung der Library-Methoden oft einfacher.
2. Die Library-Methoden sind verständlicher.
3. Die Abhängigkeiten außerhalb der facade sind überschaubarer.
4. Das Interface des Systems kann durch die facade besser designt werden.

mud -> facade -> refactoring

1. Eine Facade wird über den mud gestülpt.
2. Sukzessive werden Funktionen, die durch die Schnittstelle der facade definiert werden, durch refactoring ersetzt.
3. Wenn alle Schnittstellen-Funktionen refactored sind, kann der mud gelöscht werden und die facade aufgelöst werden.

Problematisch bei dem Vorgang ist zum einen das finden und Definieren der Schnittstellen nach außen und zum Anderen die Analyse der inneren Logik, die es nachzubilden gilt.

Definition

Das Architektur Antipattern gas factory bezeichnet unnötig komplexe Architektur-Entwürfe.

Die Beurteilung, wann ist eine Software-Architektur unnötig komplex, ist subjektiv. Die Entscheidung, was ist in diesem Zusammenhang unnötig komplex muss in der Gemeinschaft des Projekts getroffen werden.

Nachteile von unnötig komplexen Entwürfen

• Die Benutzung des Codes ist kompliziert.
• Überflüssiger Code wird mitgeschleppt.
• Er muss gepflegt und getestet werden.
• Er verlängert die Entwicklungszeit.
• Er ist schwer verständlich.
• Der Abhängigkeitsgrad innerhalb und außerhalb der gasfactory ist meist sehr hoch.

Wie kommt es zu komplexen Entwürfen

• Es werden Libraries gebaut, die für zu viele Zwecke entworfen werden (schweizer Taschenmesser, multi purpose libraries).
• Irgendwann könnte man das doch mal brauchen.
• Wenn ich die Funktion baue, dann muss die schon das auch noch können.
• Es ist schwierig, etwas später hinzuzufügen! Wirklich? Unit Tests!
• Es ist reizvoll, neue Technologien auszuprobieren.

KISS

Keep it simple and stupid.

YAGNI

You ain't gonny need it.

oder auch: big hairy object, the blob

Definition

Das Architektur Antipattern god object beschreibt ein Objekt, das zu viel weiß und macht.

big hairy object = überladene Schnittstelle ohne zu viel Kontrolle

The blob object eats the entire object oriented architecture.

Quelle: https://sourcemaking.com/antipatterns/the-blob

ein Gottobjekt ...

• ist in sich komplex.
• hat viele Unterobjekte.
• implementiert die Kommunikation der Unterobjekte.
• ist zu komplex für unit testing.
• hat eine sehr gute Leistung,
• verbraucht aber viel Speicherplatz.
• widerspricht dem Prinzip der strukturierten Programmierung.

strukturierte Programmierung

• Hierbei werden große Probleme (Aufgaben) in kleinere zerlegt.
• Die kleinen Probleme können unabhängig entwickelt werden.
• Durch das scoping ist die Entwicklung einfacher.

working against the blob

• Objekt-orientiertes Design wird angewendet.
• Wenn schon refactored wird, dann sollte der Transfer zum Objekt-orientierten Design durchgezogen werden.
• Schon die Anforderungs-Analyse (durch den Entwickler) muss verbessert werden.
• Anstelle der bottom up Design-Methode wird die top down Methode angewendet.

refactoring

Quelle: https://sourcemaking.com/antipatterns/the-blob

Definition

Das inner plattform Antipattern beschreibt ein System, das durch weitreichende Konfigurationen eine schwache Kopie der Plattform erreicht.

Beispiele

• Eigene String Bibliotheken bilden String- oder Datums-Operationen der Programmiersprache nach.
• Es gibt Firefox Addons, die den File-Browser nachbilden.

Nachteile

• Die Vereinfachung der Systemfunktionen wird oft nicht erreicht.
• Das Ziel, durch die Abstraktion Unabhängigkeit vom System zu bekommen, ist oft überflüssig und scheinheilig.
• Die Pflege des zweiten Systems ist aufwendig.
• Das Plattform-System ist oft langsamer, da mehrere Systemfunktionen zusammengefasst werden, die nicht immer alle notwendig sind oder eingesetzt werden müssen.
• Das Plattform-System ist manchmal undurchsichtiger.

Gegenmaßnahmen

• Es werden gleich die Systemfunktionen verwendet.
• Die Problematik, die zur Entwicklung der plattform geführt hat, muss genauer analysiert werden.
• Man sollte die bestehenden Systeme besser kennen lernen, bevor man neues programmiert.
• Auch wenn es manchmal weh tut: Weiterbildung, die eigene und andere (spread the knowledge)

Definition

Von dem Antipattern spaghetticode spricht man, wenn der Quellcode eine oder mehrere der folgende Eigenschaften hat:

• verworrene Kontrollstrukturen
• viele Sprungbefehle (goto, falscher Einsatz von Exceptions)
• monolithischer Block
• prozessorientierte Methoden
• wenige Parameter, viele globals

Nachteile

• Der Code ist schwer verständlich.
• Das bug fixing ist schwierig.
• Ab einem gewissen Zeitpunkt ist eine Neuentwicklung leichter als eine Erweiterung.

Wie entsteht spaghetticode?

• Ohne Plan wird einfach drauf los programmiert.
• Die Erweiterung des Codes findet ohne refactoring statt.

Gegenmaßnahmen zum spaghetticode?

• Prävention!
• Das bug fixing und neue features müssen ein refactoring einschließen.
• Objekt-orientierte Programmierung wird angewendet.
• Eine Erweiterung des Codes inklusive refactoring ist einfacher mit Unittests.
• Exceptions dürfen nicht als quasi-Kontrollstruktur Zweck-entfremdet werden.
• Es wird domain driven design angewendet.

domain driven design

Softwareentwicklung scheitert häufig nicht an der Technik, sondern an interdisziplinärer Kommunikation.

Da Entwickler und Fachleute mit unterschiedlichen Terminologien arbeiten, gibt es Verständnisprobleme.

Definition

Unter Domain Driven Design (DDD) versteht man eine Herangehensweise an die Entwicklung von Software, bei der die Implementierung mit dem zu entwickelnden Modell verbunden wird.

Der Focus beim Entwickeln wird auf das Fachgebiet und die damit verbundene Logik gesetzt.

Ziel ist unter anderem eine gemeinsame Sprache von Entwicklern und den requirements-engineers.

Definiiton

A fat client deeply married to a fatter database is too rigid and inflexible for growth.

http://wiki.c2.com/?SumoMarriage

typische Anzeichen

• Die Anzahl der Spalten in den Tabellen der Datenbank ist sehr hoch.
• Es gibt komplexe Datenbank Prozeduren (stored procedures).

Nachteile

• Die Datenbank ist schwer portierbar.
• Jede Erweiterung macht das System schwerfälliger.
• Die Logik ist nicht mehr nur über den Code erkennbar.
• Die Datenbank- und Code-Skills sind nicht immer gleich verteilt.

Gegenmaßnahmen

• Es muss genau abgewägt werden, was und wie viel der Business-Logik in die Datenbank(-Struktur) gepackt wird.
• Die Datenbank-Struktur sollte so weit wie möglich normalisiert werden.
• Es muss genau überlegt werden, wie die Datenbank-Abfragen auf die Datenbank-Kapseln und auf Domain-Objekte verteilt werden.
• Die Datenbank-Änderungen müssen eine Entsprechung im Code haben.

It depends!

Im Umgang mit der Verteilung von Business Logik auf Code und Datenbank ist viel Erfahrung notwendig.

[1] http://laputan.org/mud

[2] https://tommcfarlin.com/design-patterns-for-refactoring-facade/

[3] http://www.rogoit.de/webdesign-typo3-blog-duisburg/anti-pattern-the-gas-factory/

[4] http://devmethodologies.blogspot.de/2013/12/the-gas-factory-anti-pattern.html

[5] https://sourcemaking.com/antipatterns/the-blob

[6] https://sourcemaking.com/antipatterns/spaghetti-code

[7] http://wiki.c2.com/?SumoMarriage

[8] http://daraff.ch/2011/02/wie-viel-businesslogik-gehort-in-die-datenbank/

[9] https://www.heise.de/developer/artikel/Domain-driven-Design-erklaert-3130720.html