Samstag, 31. August 2013

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.

Im Folgenden beschreibe ich eine mögliche Struktur für einen Entwurfsmusterkatalog in einem Wiki. Die Einstiegsseite bildet eine Aufzählung aller im Team verwendeten Entwurfsmuster.

ID Name Zweck Problem
1


Der Name des Entwurfsmuster bildet einen Link auf eine genauere Beschreibung des Entwurfsmusters. Dies Beschreibung kann einen Link auf die Wikipedia oder einen Entwurfsmusterkatalog enthalten. Außerdem sollten ein Klassendiagramm und eine tabellarische Erläuterung zu allen Klassen vorhanden sein.

Diese Beschreibung sollte am Besten von dem Mitglied im Team vorgenommen werden, das am Anfang der Diskussion die größten Schwierigkeiten mit diesem Entwurfsmuster hatte. Alle anderen Teammitglieder sollten ein Review durchführen und ihre Kritik äußern. Am Ende wird ein gefestigter Wissensstand im Wiki abgelegt und das Entwurfsmuster kann mit einer hohen Produktivität eingesetzt werden.

Die weitere Diskussion in unserem Team führte uns geradewegs zum Abstact Factory Pattern. Wir versuchten gemeinsam die Tabelle auszufüllen und detaillierte Beschreibungen zu erstellen.

ID Name Zweck Problem
1 Abstract Factory Es sollen zusammengehörende Mengen von Objekten zur Verfügung gestellt werden. Es müssen zusammengehörende Mengen von Objekten, die miteinander in Beziehung stehen, instanziiert werden.


Der Link auf den Namen der Abstract Factory führt uns zur detaillierten Beschreibung. Diese konnten wir jedoch erst erstellen, nachdem auch dem letzten Teammitglied klar war, wozu die Abstract Factory gut ist und wie sie das gestellte Problem löst.

In unserem Beispiel existieren drei Systeme, die jeweils aus einer A-Komponente und einer B-Komponente zusammengesetzt werden. System1 wird beispielsweise mit Hilfe der A1-Komonente und der B1-Komponente zusammengestellt. Zwei Komponenten sind zwar nicht gerade eine große Menge, aber wir wollen uns das Problem in diesem Fall auch nur verdeutlichen. Für jedes System gibt es eine spezifische A-Komponente und eine spezifische B-Komponente.

   

public interface A {
     void execute();
   }

   public class A1 implements A {
     @override
     public void execute() {
       System.out.println("Die A1 Funktionalität wird ausgeführt");
     }
  } 



Für die konkrete A2- und die A3-Komponente sieht der Code genauso aus. Auch die B-Komponenten werden so abgebildet. Erzeugt werden die Komponenten nun in einer konkreten System-Faktory, die die abstrakte Factory implementiert.

   

public interface AbsFactory {
 A getAComponent();
 B getBComponent();
}

public class System1Factory implements AbsFactory {
 @override
 public A getAComponent() {
  return new A1();
 }
 @override
 public B getBComponent() {
  return new B1();
 }
}



Die System2Factory und die System3Factory sind natürlich ähnlich wie die abgebildete System1Factory aufgebaut, nur dass die entsprechenden A- und B-Komponenten erzeugt werden. Zum Schluss muss das Ganze noch von einem Client verwendet werden.

   

public class Client {
 private AbsFactory factory;
 public Client(AbsFactory factory) {
  this.factory = factory;
 }
 public void executeAComponent() {
  factory.getAComponent().execute();
 }
 public void executeBComponent() {
  factory.getBComponent().execute();
 }
}



Dem Client könnte nun über Dependency Injection die entsprechende SystemFactory injiziert werden. Eine entsprechende UML-Grafik verdeutlicht das Gesamtsystem.


Zum Schluss möchte ich noch einmal betonen, dass das Negieren von Wissenslücken im Team zu erheblichen Ausfällen in der Produktivität führt. Dieser Fakt darf in der Realität nicht unterschätzt werden. Eine der wichtigsten Aufgaben ist es deshalb, eine Fehlerkultur aufzubauen, in der das Zugeben von Fehlern nicht zum Abstrafen führt, sondern zu einer Weiterentwicklung im Team und dass das Zugeben von Nichtwissen zum gemeinsamen Wissensaustausch führt.

Es wird noch ein konkretes Beispiel für die Abstract factory nachgeliefert.

vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

1 Kommentar:

  1. zwei Bemerkungen:

    1.
    ich finde es sehr gut, dass Du in Deiner Nachlese (http://easyrequirement.blogspot.de/2013/09/das-factory-pattern-glaube-und.html) das Pattern anhand eines konkreten Beispiels für den Lernenden plastischer und damit greifbarer machst

    2.
    Du hast eine extrem wichtige Abschluss-Bemerkung geschrieben:
    "Zum Schluss möchte ich noch einmal betonen, dass das Negieren von Wissenslücken im Team zu erheblichen Ausfällen in der Produktivität führt. Dieser Fakt darf in der Realität nicht unterschätzt werden. Eine der wichtigsten Aufgaben ist es deshalb, eine Fehlerkultur aufzubauen, in der das Zugeben von Fehlern nicht zum Abstrafen führt, sondern zu einer Weiterentwicklung im Team und dass das Zugeben von Nichtwissen zum gemeinsamen Wissensaustausch führt."

    Ich durfte schon viele Teams dabei begleiten, KnowHow z.B. beim Erlernen von Patterns, Test-Vorgehen (TDD, ...) und Continuous Delivery-Strategien aufzubauen.

    Bei den Teams, die in einem "sicheren" Kontext "Fehler sind Chancen für Verbesserungen" wirken und lernen können, waren beispielsweise die Code-Qualität deutlich höher oder die technische Schulden-Last sehr viel geringer.

    Bei den anderen Teams, die sich in einer Blaming-Kultur bewegen mussten, spiegelte sich diese Kultur extrem in den Arbeitsergebnissen wieder - negativ, mit kaum nachhaltigem Mindset, die Bug-Tracker-Listen wurden länger und länger...

    CU
    Boeffi

    AntwortenLöschen