3. Meinungen zur Implementierung

Meinungen zur Implementierung

  • A

    Hallo,

    ich habe heute eine abstrakte factory implementiert und bin mir noch sehr unsicher, was ich davon halen soll.
    Bin über Kritik dankbar.
    main.cpp

    AbstractFactory& factory1=ConcretFactory1::getInstance();
	factory1.CreateA();
	factory1.CreateB();
	factory1.CreateN();

	AbstractFactory& factory2=ConcretFactory2::getInstance();
	factory2.CreateA();
	factory2.CreateB();
	factory2.CreateN();

    AbstractFactory.h

    class AbstractProductA;
class AbstractProductB;
class AbstractProductN;

class ConcretFactory1;
class ConcretFactory2;

class AbstractFactory
{
//friend ConcretFactory1;
//friend ConcretFactory2;

public:
	// The creator functions 
	virtual AbstractProductA *CreateA(void) const =0;
	virtual AbstractProductB *CreateB(void) const =0;
	virtual AbstractProductN *CreateN(void) const =0;
protected:
	AbstractFactory();
	~AbstractFactory();
private:
	// Not implemented
	AbstractFactory(AbstractFactory const &);
	AbstractFactory & operator=(AbstractFactory const &);
};

#endif // ABSTRACT_FACTORY_H

    ConcretFactory1.h

    #ifndef CONCRET_FACTORY_1_H
#define CONCRET_FACTORY_1_H

#include "AbstractFactory.h"

class ConcretFactory1 : public AbstractFactory
{

public:
	AbstractProductA *CreateA(void)const{std::cout <<"\n F1::CreatA"; return 0;};
	AbstractProductB *CreateB(void)const{std::cout <<"\n F1::CreatB"; return 0;};
	AbstractProductN *CreateN(void)const{std::cout <<"\n F1::CreatN"; return 0;};
	static ConcretFactory1& getInstance(void){static ConcretFactory1 _Instance;return _Instance;};
private:
	ConcretFactory1():AbstractFactory(){std::cout <<"\nConcretFactory1()";};
	~ConcretFactory1(){std::cout <<"\n~ConcretFactory1()";};
	// Not implemented
	ConcretFactory1(ConcretFactory1 const &);
	ConcretFactory1 & operator=(ConcretFactory1 const &);

};

#endif //CONCRET_FACTORY_1_H

    Die zweite konkrete Fabrik schaut gleich aus, nur eben den einser durch nen zweier ersetzt.

    Was mich konkret stört ist, dass ich im Grunde zwar Laufzeitpolymorphismus benutze, es aber durch dir referenz nicht wirklich schön anwenden kann...
    Ich wollte eigentlich exmplizit den Pointer vermeiden.

    Gruß

    0
  • K

    Welches Problem soll deine Factory loesen?

    0
  • B

    AlexanderKiebler schrieb:

    Was mich konkret stört ist, dass ich im Grunde zwar Laufzeitpolymorphismus benutze, es aber durch dir referenz nicht wirklich schön anwenden kann...
    Ich wollte eigentlich exmplizit den Pointer vermeiden.

    Welche Referenz? Wieso kannst du damit keine Polymorphie anwenden?
    Mich stört konkret an deiner Fabrik, dass sie gar nichts erzeugt ausser Nullen 😉 Ich vermute (man kann hier ja gar nicht über die tatsächliche Implementierung sehen), dass mich auch das Singleton und die Zeiger, die die Methoden zurückgeben stören.

    0
  • A

    Ja, ich gebe erstmal noch nullen zurück... das liegt daran, dass ich mir
    einen designpattern katalog in mein privates Wickipedia einpflegen möchte.
    Und zu diskret darf ich da nicht werden. =)....

    Die Zeiger und der Sigelton sind explizit gewollt und sind auch gut so. Es ist nicht aufgabe der Factory, ein Zusammengebautes Objekt auch zu zerstören.
    Das muss das client objekt machen.

    Aber ich glaube es ist schöner Zeiger von den konkreten Typen zurückzugeben.
    Also in der Form:

    class ConcretProductA;
class ConcretProductB;
class ConcretProductN;

class ConcretFactory1;
class ConcretFactory2;

class AbstractFactory
{

public:
    // The creator functions
    virtual ConcretProductA *CreateA(void) const =0;
    virtual ConcretProductB *CreateB(void) const =0;
    virtual ConcretProductN *CreateN(void) const =0;
protected:
    AbstractFactory();
    ~AbstractFactory();
private:
    // Not implemented
    AbstractFactory(AbstractFactory const &);
    AbstractFactory & operator=(AbstractFactory const &);
};

#endif // ABSTRACT_FACTORY_H

    ConcretFactory1.h

    #ifndef CONCRET_FACTORY_1_H
#define CONCRET_FACTORY_1_H

#include "AbstractFactory.h"

class ConcretFactory1 : public AbstractFactory
{

public:
	ConcretProductA *CreateA(void)const{std::cout <<"\n F1::CreatA"; return 0;};
	ConcretProductB *CreateB(void)const{std::cout <<"\n F1::CreatB"; return 0;};
	ConcretProductN *CreateN(void)const{std::cout <<"\n F1::CreatN"; return 0;};
	static ConcretFactory1& getInstance(void){static ConcretFactory1 _Instance;return _Instance;};
private:
	ConcretFactory1():AbstractFactory(){std::cout <<"\nConcretFactory1()";};
	~ConcretFactory1(){std::cout <<"\n~ConcretFactory1()";};
	// Not implemented
	ConcretFactory1(ConcretFactory1 const &);
	ConcretFactory1 & operator=(ConcretFactory1 const &);

};

#endif //CONCRET_FACTORY_1_H

    Die referenz passt glaube ich doch auch ganz gut. Wenn ich weiter programmiere,
    dann wird es passen habe ich mir überlegt. Das liegt daran, dass ein konkretes Produkt nur explizit eine Factoryfunktion benutzt und das auch darf.

    0

  • knivil schrieb:

    Welches Problem soll deine Factory loesen?

    Ich find das ist hier immer noch die interessanteste aller Fragen...

    Wie soll man ein Design beurteilen wenn man nichtmal weiß wofür es eigentlich gut sein soll!?

    0
  • C

    AlexanderKiebler schrieb:

    Wickipedia

    Das ist wirklich nett von dir, dass du eine Enzyklopädie für Wickie Fans einrichten möchtest. So etwas habe ich schon lange gesucht!

    Ansonsten schließe ich mit mal knivil und dot an: Man macht doch keine Factory nur weil's schön aussieht. oO

    0
  • A

    Für die wirklich wichtige Frage brauch in noch Zeit... =(...

    Ich vermute, dass man das mit Templates besser machen kann...

    0
  • A

    Hmm okay,

    also habe das mal fertig implementiert....

    So wie es jetzt ist, kann man die Produktfamilie zur Laufzeit ändern.

    client client_app;

	client_app.Execute();
	for(unsigned int x=0;100>x;x++)
	{
		client_app.select_prod_famlily(x%2);
		client_app.Execute();
	}

    Damit läßt sich sehr schön arbeiten.
    Der Code artet aber echt aus für größere Sachen...

    0
  • K
     

    AbstractFactory& factory1=ConcretFactory1::getInstance(); 
    factory1.CreateA(); 
    factory1.CreateB(); 
    factory1.CreateN();

    Also ich habe ja generell ein ... Problem (ist wohl uebertrieben) mit Factories: Welchen Vorteil hat dein Beispiel in der die Factory 3 Objekte erzeugt gegenueber einfachen Konstruktor- oder Funktionsaufrufen? Oder anders herum gefragt: Warum brauchst du eine Factory, welches anwendungsspezifische Problem loesen sie?

    0
  • A

    Also im Grunde genommen habe ich mit der abstrakten Factory getrennt:

    Was wird benutzt,
    Und wie wird es benutzt.

    Der Client benutzt irgendwelche Objekte, und er weiß nur wie er sie benutzt.
    Die konkreten objekte dahinter können aber beliebig zur Laufzeit ausgetauscht werden. Welche Objekte gemeinsam funktionieren ist Aufgabe der konkreten Factory.

    Ich findes, dass das Sinn macht. Wenn man Probleme trennt, kann man sich besser darauf focusieren.

    0
  • K

    Die konkreten objekte dahinter können aber beliebig zur Laufzeit ausgetauscht werden.

    Nein, koennen sie nicht. Sie muessen zumindest ein gemeinsames Interface besitzen, d.h eine gemeinsame Basisklasse. Der "Austausch" kann auf viele Arten geschehen, indem Basisklassenzeiger verwendet werden.

    Darueber hinaus halte ich die Intention fuer fraglich. Ich erzeuge ein Objekt A mittels CreateA, tausche zur Laufzeit in der Factory etwas aus, erzeuge ein Objekt B ebenfalls mit CreateA. Nun sind aber A und B vom Typ her verschieden, obwohl ich sie auf die gleiche Art und Weise erzeugt habe, also den gleichen "Konstruktor" aufgerufen habe. Also ich mache von der Client-Sete her das gleiche, bekomme aber trotzdem was verschiedenes. Das halte ich nicht fuer gut.

    Naechstes Problem: Ich will einen Unit-Test schreiben. Deine Klasse bekommt die Factory als Parameter im Konstruktor uebergeben und erzeugt ihre Member. Fuer einen Unit-Test muss ich die Implementation, des Konstruktors kennen, welche Methoden der Factory benutzt werden, welchen Zustand die Factory hat ... . Das sind alles Implementationsdetails, die fuer einen Unit-Test garnicht von belang sein sollten. Ihn zu schreiben wird wesentlich aufwendiger und fehleranfaelliger.

    Ich findes, dass das Sinn macht. Wenn man Probleme trennt, kann man sich besser darauf focusieren.

    Das ist allgemeines BlaBla und kann ueberall gesagt werden.

    0
  • A

    Ich glaube wir benötigen ein Bildchen. 🙂

    http://sourcemaking.com/files/sm/images/patterns/Abstract_Factory_example1.gif

    [EDIT: Das bildchen ist nicht ganz so schön, aber hab auf die kürtze nichts besseres gefunden]

    [EDIT: Hab ne schönere Grfik gefunden]
    http://t1.gstatic.com/images?q=tbn:ANd9GcS2KwweB3MZx5GDWs7G6Dlr-Qh697sem53hPxUVWg3FzYUssa5clQ

    schau mal da, also das Pattern hat schon seinen Sinn.

    Dass die Objekte ein gemeinsames Interface haben.... na ja das ist klar.
    Das steht ja so im Muster. Das war meine Aussage "Und wie wird es benutzt"

    "Die konkreten objekte dahinter können aber beliebig zur Laufzeit ausgetauscht werden." Ja okay, das ist wohl nicht ganz richtig ausgedrückt. Ich hoffte, dass ich für Objekt"e" den plural verwendet habe genügt... aber wohl nicht. Ich habe aber explizit hinzugefügt:
    "Welche Objekte gemeinsam funktionieren ist Aufgabe der konkreten Factory. "
    Ich denke da wirds dann eindeutig.

    In Deinem Beispiel hast du den Fehler gemacht, dass du mi CreateA lediglich
    A1, A2,A3... etc erzeugen kannst, je nach dem ob du die Konkrete Factory 1,2,3... etc benutzt...

    0
  • E

    In C++ kann man halt recht oft die ganzen "Javastyle"-Designpattern zum Teufel jagen. Würde da immer etwas darüber nachdenken.

    0
  • A

    *ggg* Genau, deswegen hab ich das auch aus einem Design Pattern buch wo gand dick und fett C++ drauf steht. *lach*

    Aber gut jetzt... Was micht viel mehr stört ist, dass sich der code total aufbläht.... .

    Aber das mit dem Unit Test, finde ich ein gutes Argument..... ja das stimmt....
    wobei man da ja jede Produktvariante getrennt testen kann...

    0
  • K

    Ich glaube wir benötigen ein Bildchen.

    Ich weiss, was das Factory-Pattern ist.

    Was micht viel mehr stört ist, dass sich der code total aufbläht....

    Waran das wohl liegt ...

    Design Pattern buch wo gand dick und fett C++ drauf steht.

    Klar koennen die Design-Pattern auch in C++ umgesetzt werden. Aber ob das immer sinnvoll ist, bezweifle ich.

    In C++ kann man halt recht oft die ganzen "Javastyle"-Designpattern zum Teufel jagen. Würde da immer etwas darüber nachdenken.

    Danke! Ich weiss nun, das ich keine Einzelmeinung vertrete.

    0
  • A

    Hmm na ja wahrscheinlich kann man da getrennter Meinung sein.

    Habe sie öfter gesehen, und finde sie sehr gut.

    Wegen deom Code Aufblähen werde ich mich mal an eine generische implementierung machen. Aber ohne sie hier rein zu stellen.

    0
  • K

    Jon Bentley sagt sinngemaess: Software engineering dient dazu, Komplexitaet zu beherrschen aber nicht zu erzeugen.

    Du erzeugst Komplexitaet. Allein schon deine Factory ohne Grund zu benutzen. Sie fuehrt zu Codebloat. Ein selbstverschuldetes Problem. Um dieses zu Loesen, erhoehst du den Komplexitaetsgrad weiter, indem du einen generischen Ansatz verfolgst. Du magst vielleicht nicht abschaetzen, wohin das fuehrt. Deswegen warne ich dich.

    0
  • A

    In erster Linie implementiere ich ein Designpattern welches sich doch einiger popularität erfreut.

    Und den Code werde ich in mein Wicki einpflegen um ihn wenn ich ihn brauche zur Hand zu haben.

    Dadurch dass du das zu behandelnde Problem genausowenig kennst wie ich, ist es echt zimlich ins blaue geschossen ob ich unnötige komplexität erzeuge...
    Das kann man doch so garnicht vorhersagen. Ich würde das akzeptieren, wenn ich ein konkretes Problem hätte, und ein einfacheres Muster das Slebe problem lösen würde.... Aber so... habe ich ausschließlich ein pattern implementiert was auch mein Ziel war. Du scheinst nicht zu verstehen, dass ich dieses Muster implementiert habe, und nicht nach einem Muster zu einem Problem suche.
    Das sind nunmal zweipaar stiefel.

    0
  • B

    Ethon schrieb:

    In C++ kann man halt recht oft die ganzen "Javastyle"-Designpattern zum Teufel jagen. Würde da immer etwas darüber nachdenken.

    Abstract Factory ist eines der GoF Pattern. Das Buch ist 1994 erschienen und da waren die meisten Muster schon bekannt, es war nur eine Katalogisierung. Diese Muster stammen also mit Sicherheit nicht aus der Java Community, denn die erste öffentliche Java Version kam nach GoF 😮 . Es gibt in Java, C++, C# und anderen Sprachen sicherlich einige Anwendungsfälle für eine GoF Abstract Factory. Ich muss allerdings sagen, dass ich das exakte Muster auch nur ein paar wenige Male angewendet habe. Es scheint vielleicht auf den ersten Blick etwas sehr offentsichtliches, praktisches, häufig anzuwendendes zu sein, wirklich sinnvolle Anwendungen begegnen einem aber in der Tat eher selten.
    Egal in welcher Sprache, man sollte zunächst immer möglichst einfache Lösungen anstreben. Gedanken über Flexibilität und Erweiterbarkeit kann man sich machen, wenn man sie benötigt. Nicht wenn man vermutet sie zu benötigen.

    0
  • A

    Hmm ja das passt... So sehe ich das auch...
    Das zu viel Argument ist auch einer meiner ersten Gedanken gewesen... das stimmt.
    Trotzdem habe ich es mir eben zum einpflegen mal vorgenommen für deses We...

    Also keine Angst, ich bevorzuge die einfachen Muster den komplexen, wenn sie das problem genauso lösen. Klaro.... Aber ich wollte keine Fallstudie machen.
    Ich möchte ein Katalog mit Codestückchen für mich die ich zumindest teilweise so wiederverwenden kann, oder eben abgewandelt.

    0
  • K

    also mit Sicherheit nicht aus der Java Community, denn die erste öffentliche Java Version kam nach GoF

    Der Ursprung ist natuerlich nicht in der Java-Welt zu suchen. Es wird dort haeufig und gern angewandt, gerade auch ohne Not.

    ich bevorzuge die einfachen Muster den komplexen

    Und hier hast du schon verloren, da du in Mustern denkst bzw. das Problem dort hineinpresst. Den gleichen Fehler haben viele mit Objektorientierung und Vererbung gemacht, aber nicht jedes Problem ist ein Objekt und Vererbung selten eine Loesung.

    PS: Ja es ist Religion, ich versuche dich vor der Hoelle zu bewahren. Abschliessend:

    The Tao Of Programming: Book 4 - Coding schrieb:

    Thus spake the master programmer:

    ``A well-written program is its own heaven; a poorly-written program is its own hell.''

    0
Anmelden zum Antworten