Meinungen zur Implementierung
-
*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...
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.''
-
brotbernd schrieb:
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.Ich nenne es "Java-Pattern", weil es in Java schön umzusetzen ist und deswegen auch häufig gemacht wird. In Java ist es halt cool mit new und Polymorphie herumzuscheißen, weil es nicht anders geht und keine Performance kostet.
In C++ geht es mir schon gehörig auf den Senkel, überall alles in unique_ptr s zu stopfen (und andauernd moven zu müssen, wenn der Besitz abgegeben wird), weil einfach kein GC da ist, außerdem kostet die ganze Laufzeit-Dynamik viel, die möglicherweise doch "Compilezeit-Dynamik" ersetzbar wäre.
Gängig in C++ ist es halt, alles was zur Compilezeit entscheidbar ist, per Template dynamisch zu machen.
-
Ja,
"Gängig in C++ ist es halt, alles was zur Compilezeit entscheidbar ist, per Template dynamisch zu machen. "
Das finde ich auch ein sehr guter einwand. Wobei das auf die Implementieruing abziehlt. Ich bin auch an einer Lösung mit statischem Polymorphismus interessiert.
Und um ehrlich zu sein wollte ich heut noch eine Implementierung wagen.
-
Ethon schrieb:
...außerdem kostet die ganze Laufzeit-Dynamik viel, die möglicherweise doch "Compilezeit-Dynamik" ersetzbar wäre.
Das kostet beides was. Die Laufzeit-Dynamik kosten dem Anwender (meistens kaum spürbar) Zeit, "Compilezeit-Dynamik" kostet dem, der die Entwicklung bezahlen muss Geld.
Ethon schrieb:
Gängig in C++ ist es halt, alles was zur Compilezeit entscheidbar ist, per Template dynamisch zu machen.
Das ist mit Sicherheit nur in kleineren Projekten oder Projekten mit speziellen Anforderungen gängig. Oder bei Leuten, die Spaß am Kompilieren haben.
-
Ethon schrieb:
Gängig in C++ ist es halt, alles was zur Compilezeit entscheidbar ist, per Template dynamisch zu machen.
Nein, ist es nicht. Zumindest mache ich das nicht. Das zur Laufzeit aufzulösen ist zwar etwas langsamer, aber selbst bei 100 Funktionsaufrufen ist das ziemlich irrelevant. (Auch bei mehr.) Irgendwann fängt es natürlich an sich bemerkbar zu machen, aber das sind dann meistens eh recht kritische Stellen an denen man optimiert.
Ich würde mir zwar wünschen statische Interfaces zu haben, aber bis man das ordentlich benutzen kann, muss man noch auf Concepts + Module warten. Dann geht's aber richtig los.
