Konfigurator

[Javt]

Hi,

Ich hab folgenden Programmaufbau:
Eine "Application"-Klasse, eine "MailImpl"-Klasse, ein "Mail"-Interface und eine "Configurator"-Klasse.
"MailImpl" ist eine konkrete Implementierung des Interface "Mail". Die Konfigurator-Klasse instanziiert "Application" und eine konkrete Implementierung des Interface "Mail". Die Klasse "Application" verwendet dann die konkrete Implementierung "MailImpl".

Die Implementierung, die eine Konfiguratorklasse verwendet hängt doch wie der Name der Klasse schon sagt von der Konfiguration des Benutzers ab. Wenn ich also eine andere Implementierung haben will, so muss ich ja im Grunde nur eine andere Konfiguration vornehmen. Wieso soll also denn "Configurator" nicht eine konkrete Implementierung von "IMail" instanziieren , sondern eine Mail-Factory? Wenn der Configurator eine Factory instanziieren soll, kann ich doch den Configurator gleich sein lassen und nur eine Factory-Klasse verwenden.

lg

 

[SlaterB]

> Wieso soll also denn "Configurator" nicht eine konkrete Implementierung von "IMail" instanziieren , sondern eine Mail-Factory?

wieso drückst du etwas halb abweisend als Frage aus was vorher nicht genannt wurde?
nenne doch erstmal die Aussage mit Quelle/ Begründung usw.
"hier steht: eine Mail soll von einer Mail-Factory erzeugt werden, ich dagegen.."

meine Ansicht:
der Configurator wählt zwischen 5 Dingen, kennt diese aber nicht im Detail,
jede Variante hat ihre eigene komplizierte Initialisierung, das kann im jeweiligen package versteckt geschehen,
der Configurator muss am Ende auch gar nicht wissen, welche Klasse kontret raus kommt,
evtl. selbst bei konkret einer von 5 Varianten intern noch variabel je nach was auch immer, Rückgabe des Interface reicht

aus Konfiguration die eindeutige Factory zu bestimmen reicht ebenso

 

[Javt]

Hi,

Das was ich einfach wissen will, wieso nicht einfach folgendes machen:
Der Konfigurator initialisiert eine konkrete Implementierung.
sondern:
Der Konfigurator intialisiert eine Factory, der wiederum die konkrete Implementierung initialisiert. Wo liegen jetzt die Vor und Nachteile?

Und was ich noch nicht verstehe ist: Der Konfigurator kann doch je nachdem, was für eine Konfiguration momentan vorliegt, unterschiedliche Implementierungen liefern oder? Was ich damit z. B. meine ist: Der Konfigurator überprüft dynamisch die Einstellungen, die getroffen wurden und gibt in Abhängigkeit davon dann eine konkrete Implementierung zurück.

lg

 

[SlaterB]

eine Factory ist generell nützlich, manche Objekte erfordern eine gewisse Initialisierung,
Factories gehören explizit nicht dazu, manchmal gar nur statische Methode, aber um bei OO zu bleiben,
um verschiedene Factorys in einer Variable zu haben auch als Objekt,

die Initialisierung eines Objekts der komplizierten Klassen besteht aus vielen Befehlen,
das kann im Konstruktor passieren, manchmal aber nicht angebraucht, Factories sind für sich sinnvoll, Punkt!

bei 5 Mails gibt es 5 Factories, die sind alles unabhängig entwickelt, den Code kann man in eine Klasse schreiben oder eben getrennt,

unabhängig vom Ort der mglw. vorhandenen 5 Factories ist der Configurator eine mglw. andere Klasse, hat eigene Aufgaben,
wählt vielleicht 30 Dinge aus und ist lang genug, da will man nicht komischen Mail-Pop3-Auth-Code haben,
der Configurator ruft die Factories auf und das läuft

zu wenig Klassen ist öfter kritisch als zu viele Klassen

 

[Javt]

Kann ich das dann so verstehen:
Eine "Configurator" oder "Factory"-Klasse liefert eine ganz bestimmte Implementierung (Instanz). Es ist fest in die Klasse hineinkodiert. D. h. eine "Configurator" oder "Factory"-Klasse kann also nicht durch if-else bzw. switch-Abfragen abhängig von Benutzereinstellungen eine andere Implementierung liefern, sondern nur eine fest und hart hineinkodierte Implementierung?

lg

 

[nillehammer]

Kommt drauf an, wie Du Deine Factory-Methode baust. Sie könnte intern properties laden und davon abhängig eine Implementierung zurück geben. Sie könnte auch einen Methodenparameter dafür auswerten. Factory-Methoden müssen nicht unbedingt so stumpfe Einzeiler sein, um den Konstruktoraufruf wegzukapseln.
Fiktives Beispiel für eine Factory-Methode mit Parameter:

public static <E> List<E> create(int estimatedSize) {

  if(estimatedSize <= Byte.MAX_VALUE) 
    return new TinyListImpl<E>();

  if(estimatedSize >= (Integer.MAX_VALUE /2))
    return new HugeListImpl<E>();

   return new RegularListImpl<E>();
}

 

[SlaterB]

und der Satz
"eine "Configurator" [..]-Klasse kann also nicht durch if-else bzw. switch-Abfragen abhängig von Benutzereinstellungen eine andere Implementierung liefern"
passt ja nun überhaupt nicht wenn der Configurator genau dafür da ist zwischen den 5 Implementierungen nach Einstellungen zu wählen..
(aber ohne unbedingt jeweils wirklich die Implementierungsklassen zu kennen und zu benutzen, man kann auch wählen und doch nur allgemein die Factories aufrufen)