Das Factory Pattern – Glaube und Wirklichkeit – Teil 2

Praktisches Beispiel 2.1.2

Artikelübersicht
1. Teil	Das Factory Pattern – Glaube und Wirklichkeit – Teil 1
2. Teil	Das Factory Pattern – Glaube und Wirklichkeit – Teil 2.
3. Teil	Das Factory Pattern – Glaube und Wirklichkeit – eine konkrete Nachlese.

Im letzten Post hatte sich unser Team ein genaues Verständnis zur Static Factory Method und zum Factory Method Pattern der GoF erarbeitet. Wertvolle Informationen konnten wir auch aus den Kommentaren zum letzten Post gewinnen. Dafür möchte ich mich ausdrücklich bedanken. Damit dieses Wissen nicht verfällt, ist es gut, wenn es an einem zentralen Ort dokumentiert wird. Man könnte ein Wiki aufbauen, in dem alle Entwurfsmuster beschrieben sind, die sich das Team gemeinsam erarbeitet hat. Über die Zeit wird das eine erstaunliche Menge. Deshalb ist eine immer wiederkehrende Struktur in Form eines Katalogs anzuraten.

Quelltext zum Praktischen Beispiel 1.5

Wie angekündigt werde ich heute eine Version vorstellen, die ein weiteres Refactoring erfahren hat. Für die Anregung dazu möchte ich Rusi danken. Sein Codereview hat mich dazu veranlasst den Code noch einmal zu überarbeiten. In seinem überarbeiteten Code hat er die Klasse StartConditions in Operation aufgehen lassen. Auch bemerkte er die schwere Testbarkeit von OrderGenerator durch den new-Operator für die Klasse StartConditions. Dadurch konnten in der execute-Methode der Klasse Operation auch die Parameter entfallen. Ein weiterer Hinweis von Rusi war, dass für den ParameterParser eine Methode, statt drei, im Interface genügt. Mich haben diese Hinweise überzeugt und deshalb habe ich den Code überarbeitet. Nachzulesen ist der alte Code im Post Reengineering - Neu, strukturiert und auf lange Sicht schneller.

Schon Vorhandenes nutzen wäre schneller gewesen

Praktisches Beispiel 1.5

Artikelübersicht
1. Teil	Reengineering - Die Analyse des Altcodes.
2. Teil	Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil	Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil	Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil	Schon Vorhandenes nutzen wäre schneller gewesen. Beispielcode
6. Teil	Reengineering – Am Ende gab es nur noch eine Schnittstelle.

Mehrfach haben wir schon auf Apache Commons CLI library hingewiesen. Endlich befassen wir uns mit der Verwendung von Open Source. Welche Schritte müssen wir gehen? Was müssen wir tun? Gibt es Gefahren? Diese und andere Fragen streifen unstrukturiert durch unser Hirn und bedürfen eines geordneten Weges.

Organisationsstrukturen

These: Systemkontextanalyse öffnet die Augen für optimale Software

Artikelübersicht
1. Teil	Kontextaspekt Stakeholder.
2. Teil	Nutzerrollen, Personas und extreme Charaktere.
3. Teil	Organisationsstrukturen.

Die beiden letzten Posts dieser Reihe (Teil 1 und Teil 2) beschäftigten sich mit dem Stakeholder an sich oder mit virtuellen Ausprägungen, um mit Gedankenmodellen arbeiten zu können. Im ersten Teil Kontextaspekt Stakeholder haben wir jedoch auch schon Stakeholder zu Gruppen zusammengefasst. Diese Zusammenfassungen sind in der Realität besonders in Organisationsstrukturen anzutreffen. Eine Firma ist eine Organisation. Die Firma besteht aus Abteilungen, Projektgruppen oder Teams. Ein Team kann sich aus Subteams zusammensetzen. Schlussendlich besteht ein Team oder ein Subteam genau wie eine Abteilung oder eine Projektgruppe immer aus Einzelpersonen.

Von den Funktionsgruppen zu logischen Komponenten

These: Gut kommunizierte Software ist ein Segen für die Zukunft.

Artikelübersicht
1. Teil	Ordnung für Use Cases und User Stories durch Funktionsgruppen.
2. Teil	Von den Funktionsgruppen zu logischen Komponenten.
3. Teil	Von der logischen Komponente zur technischen Komponente.

Im letzten Post dieser Reihe ist eine Möglichkeit beschrieben worden, Funktionalität in weitere Funktionsgruppen zu bündeln. Des Weiteren konnten wir Funktionsgruppen mit Hilfe von Funktionsgruppen in einer Hierarchie ordnen. Funktionsgruppen einer bestimmten Ebene können wir dabei als funktionale Komponenten auffassen. Stellen wir uns eine Software vor, in der man bestimmte Testuntersuchungen ausführen möchte. Die gesamte Funktionalität des Erstellens dieser Tests wird in einer Funktionsgruppe konzentriert, Testausführung und Testauswertung sind weitere Funktionsgruppen.

Das Factory Pattern – Glaube und Wirklichkeit – Teil 1

Praktisches Beispiel 2.1.1

Artikelübersicht
1. Teil	Das Factory Pattern – Glaube und Wirklichkeit – Teil 1
2. Teil	Das Factory Pattern – Glaube und Wirklichkeit – Teil 2.
3. Teil	Das Factory Pattern – Glaube und Wirklichkeit – eine konkrete Nachlese.

Ein Entwicklungsteam, welches auf der Höhe der Zeit ist, verwendet Entwurfsmuster (Design Pattern). Programmierer stehen oft vor wiederkehrenden Problemen, für die schon lange exzellente Lösungen gefunden wurden. Diese Lösungen wurden in Lösungsschablonen niedergeschrieben und allen Programmierern zum Abschreiben freigegeben. Man muss das Rad also nicht zweimal erfinden. Trotz der durchklingenden, unbestrittenen Vorteile, kann der Gebrauch von Entwurfsmustern sehr problematisch sein. Weil man Entwurfsmuster anwenden soll, wendet man sie überall an, auch da, wo sie nicht hingehören. Weil man sie nicht richtig verstanden hat, wendet man sie falsch an. Einige haben sie verstanden und andere nicht. Die Anderen nimmt man auf dem Weg zum guten Code nicht mit und stellt sie in einer dunklen Ecke ab. Am Ende führt dieses teamfeindliche Verhalten zum Stillstand und reißt die Produktivität und die Laune in den Keller.

Reengineering - Neu, strukturiert und auf lange Sicht schneller

Praktisches Beispiel 1.4

Artikelübersicht
1. Teil	Reengineering - Die Analyse des Altcodes.
2. Teil	Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil	Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil	Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil	Schon Vorhandenes nutzen wäre schneller gewesen
6. Teil	Reengineering – Am Ende gab es nur noch eine Schnittstelle.

Ignorieren wir einfach die Apache Commons CLI library und gehen wir davon aus, es gibt keine Implementierung für unser Vorhaben. Dann müssten wir uns hinsetzen und anhand der Anforderungen und des Architekturentwurfs codieren. An diesem Punkt kehren wir in der Diskussion an unseren Ausgangspunkt zurück. Die Mehrheit ist vielleicht meiner Meinung, dass wir jetzt in der Lage sind, einen qualitativ hochwertigeren Code zu schreiben. Doch das Schreiben von Software außerhalb universitärer Strukturen ist auch ein ökonomischer Prozess. Und genau diese Ökonomie steht in Frage. Haben wir nicht viel mehr Zeit verbraucht?

Am 12. August sind es 100 Tage

Allgemeines

Am 12. August sind es 100 Tage, in denen ich Posts in meinem Blog publiziere. Ich habe mich verpflichtet, alle 5 Tage einen Post einzustellen. Inzwischen weiß ich, Ok, ich schaffe es, aber es ist viel Arbeit. Da stellt sich die Frage, warum tue ich das?

Es ist an der Zeit, die Gründe offen zu legen, soweit das noch nicht geschehen ist. Die Thesen, die Inhalte der Posts verfolgen natürlich eine erkennbare Absicht. Ich möchte in Teams, in denen man motiviert an eine Aufgabe gehen kann, systematisch Software entwickeln. Dieser offensichtlichen Tatsache möchte ich weitere, vielleicht verdeckte Gründe, hinzufügen, so dass ein vervollständigtes Bild entsteht.