Static Factory Method
Kategorie Allgemein Pattern
Was will er jetzt schon wieder die meisten Factory Methoden werden doch static implementiert, zumindest meistens
Wikipedia spukt diese Beschreibung aus ->
„Static Factory Method“: Einzelne static-Methode, die ein Objekt eines Typs oder Unter-Typs zurückliefert. Kein „virtual constructor“ - Sinn der Sache: Zentraler, klassenbasierter Access Point für Objekterzeugung analog zu new. Erfordert manchmal Einführung einer einzelnen Klasse nur als „Factory Method Holder“. Beispiele:
das ist nicht, dass worüber ich eigentlich heute schreiben möchte ....
Was will er jetzt schon wieder die meisten Factory Methoden werden doch static implementiert, zumindest meistens
Wikipedia spukt diese Beschreibung aus ->
„Static Factory Method“: Einzelne static-Methode, die ein Objekt eines Typs oder Unter-Typs zurückliefert. Kein „virtual constructor“ - Sinn der Sache: Zentraler, klassenbasierter Access Point für Objekterzeugung analog zu new. Erfordert manchmal Einführung einer einzelnen Klasse nur als „Factory Method Holder“. Beispiele:
- Java: java.util.Collections.singletonMap()
- Java: javax.xml.parsers.DocumentBuilderFactory.newInstance()
das ist nicht, dass worüber ich eigentlich heute schreiben möchte ....
Meistens fängt es ja so an..... man will
sich eine Klasse bauen...... ich nehme einfach mal eine Zahlen-Menge. Die
Klasse soll den Namen haben MyIntSet
also ungefähr so
public class MyIntSet{
public MyIntSet();
public void add(int x);
}
bis auf Kleinigkeiten, korrekt
Jetzt überlegt man sich, es wäre ja cool einen Konstruktur zu haben, bei dem man gleich einen ganzen Bereich angeben kann, von Zahlen, welche dann in der Menge sind, so von 1..5....
Also wird man einen weiteren Konstruktor bauen....
public MyIntSet(int min, int max);
Dann überlegt man sich, dass man evtl. alle durch 2 teilbaren, oder 3 teilbaren Zahlen in einem Gewissen Bereichen haben möchte....
Also weiteren Konstruktor
public MyIntSet(int min, int max, int factor);
Am Ende des Tages hat man dann 35.000 Konstruktoren, welche sich in der Signatur unterscheiden müssen!
Einfacher geht es erst gar keinen public Konstruktor zur Verfügung zustellen, sondern nur static factory methods, in diesem Beispiel
public static MyIntSet CreateRangeSet(int min, int max)
public static MyIntSet CreateRangeSetByFactor(int min, int max, int factor);
weiters kann man jetzt neue "Konstruktoren" mit der gleichen Signatur erstellen, z.B.:
public static MyIntSet CreateRageSetPrime(int min, int max)
und anhand des Namens, kann man leicht erkennen, dass hier eine Menge mit den Primzahlen zwischen Min und Max erstellt wird.
Vorteile der static factory methods:
* Die Methoden haben Namen und es können "gleiche Signaturen" benutzt werden
* Die Methoden müssen nicht unbedingt ein "neues" Objekt erzeugen
* Die Methoden können abgeleitete Klassen zurückgeben!
* Die Methoden können bei parametrisierten Typen, den Schreibaufwand reduzieren
Also Happy "Static Factory Methods" !!!!
Nein, so schnell nicht, denn es gibt auch Nachteile
* z.B. in Java kann von Klassen, welche keinen public oder protected Konstruktor haben nicht abgeleitet werden
* man kann die "static factory methods" nicht wirklich von anderen statischen Methoden unterscheiden
So dann viel Spaß, schönes Wochenende, gutes neues Jahr.....
und wenn mal wieder ein Architekt vorbeikommt, dann kann man ja erst mal eine Diskussion über die Verwendung von "static factory methods" vom Zaume brechen
Gruß JJR
also ungefähr so
public class MyIntSet{
public MyIntSet();
public void add(int x);
}
bis auf Kleinigkeiten, korrekt
Jetzt überlegt man sich, es wäre ja cool einen Konstruktur zu haben, bei dem man gleich einen ganzen Bereich angeben kann, von Zahlen, welche dann in der Menge sind, so von 1..5....
Also wird man einen weiteren Konstruktor bauen....
public MyIntSet(int min, int max);
Dann überlegt man sich, dass man evtl. alle durch 2 teilbaren, oder 3 teilbaren Zahlen in einem Gewissen Bereichen haben möchte....
Also weiteren Konstruktor
public MyIntSet(int min, int max, int factor);
Am Ende des Tages hat man dann 35.000 Konstruktoren, welche sich in der Signatur unterscheiden müssen!
Einfacher geht es erst gar keinen public Konstruktor zur Verfügung zustellen, sondern nur static factory methods, in diesem Beispiel
public static MyIntSet CreateRangeSet(int min, int max)
public static MyIntSet CreateRangeSetByFactor(int min, int max, int factor);
weiters kann man jetzt neue "Konstruktoren" mit der gleichen Signatur erstellen, z.B.:
public static MyIntSet CreateRageSetPrime(int min, int max)
und anhand des Namens, kann man leicht erkennen, dass hier eine Menge mit den Primzahlen zwischen Min und Max erstellt wird.
Vorteile der static factory methods:
* Die Methoden haben Namen und es können "gleiche Signaturen" benutzt werden
* Die Methoden müssen nicht unbedingt ein "neues" Objekt erzeugen
* Die Methoden können abgeleitete Klassen zurückgeben!
* Die Methoden können bei parametrisierten Typen, den Schreibaufwand reduzieren
Also Happy "Static Factory Methods" !!!!
Nein, so schnell nicht, denn es gibt auch Nachteile
* z.B. in Java kann von Klassen, welche keinen public oder protected Konstruktor haben nicht abgeleitet werden
* man kann die "static factory methods" nicht wirklich von anderen statischen Methoden unterscheiden
So dann viel Spaß, schönes Wochenende, gutes neues Jahr.....
und wenn mal wieder ein Architekt vorbeikommt, dann kann man ja erst mal eine Diskussion über die Verwendung von "static factory methods" vom Zaume brechen
Gruß JJR
| Permalink | 
Kommentare
wenn man gleich ein richtiges Factory-Pattern anwendet sollten die beiden Nachteile (zumindestens der zweite) weg sein.
Wenn ich es richtig verstanden habe, sind die normalen "static factory methods" dem entgegen direkt in der betreffenden Klasse(?)... hmm, da hätte ich etwas Bauchschmerzen was die spätere Umarbeitung (neudeutsch: Refactoring
Grüße,
Sebastian
Erstellt von Sebastian Stricker um 09:28:28 PM am 01/31/2010 | - Website - |
stimme zu, dass man gleich ein Factory-Pattern implementieren könnte. Hat aber aus meiner Sicht, den Nachteil, dass man ein Interface extrahiert und pflegen muß, welches evtl. nie von einer weiteren Klasse implementiert wird. Falls es doch zu einer weiteren Implementierung kommt, kann man das Interface schnell extrahieren und die Factory-Methoden sind ja auch schon bekannt, also sollte sich der Refactoring-Aufwand in Grenzen halten. Wenn man nach dem Motto handelt, "Starte einfach, kompliziert wird es von allein!", dann sollte es ein guter Ansatz sein
Gruß JJR
P.S.: agile nor not agile, wie schon Shakespeare anmerkte
Erstellt von JakeJBlues um 09:55:16 PM am 01/31/2010 | - Website - |
ja ein Interface benötigt man dann auf jeden Fall - korrekto
Dabei fällt mir ein, dass ich neulich mal zu einem C#-Architekturvortrag war, wo jemand das "Contract-First" Vorgehen erklärt und auch heftig angepriesen hat... als ich anmerkte, dass ein Interface pro Klasse evt. überflüssiger Müll sei exakt wegen dem von dir besagtem Pflegeaufwand ohne Nachnutzung durch weitere Klassen... war ich irgendwie unbeliebt bei dem Vortragenden
Grüße,
Sebastian
Erstellt von Sebastian Stricker um 10:17:34 PM am 01/31/2010 | - Website - |
wahrscheinlich war es ein LOA siehe { Link }
Vielleicht sollte ich noch die Anmerkung einbauen: keine Klasse ohne Interface
Gruß JJR
Erstellt von JakeJBlues um 10:29:43 PM am 01/31/2010 | - Website - |