Design-Pattern-Sammlung.

[dali]

Stud84 schrieb:

ich hab mehr als genug verstanden um zu wissen, wann ein kommentar sinnlos ist..
deiner war es..

Nein, war er ganz und gar nicht. Er wollte damit halt andeuten, wenn auch nicht auf ganz offensichtliche Art und Weise, dass dein Vorhaben nur geringfügig Sinn macht, weil eine "Bibliothek für Patterns" sich nur auf ganz wenige anwenden lässt.

Teilsteils... Es gibt schon viele Patterns die man abstrakt formulieren kann nicht so wie du andeutest nur dieses eine

[Prof84]

dali schrieb:

Stud84 schrieb:

ich hab mehr als genug verstanden um zu wissen, wann ein kommentar sinnlos ist..
deiner war es..

Nein, war er ganz und gar nicht. Er wollte damit halt andeuten, wenn auch nicht auf ganz offensichtliche Art und Weise, dass dein Vorhaben nur geringfügig Sinn macht, weil eine "Bibliothek für Patterns" sich nur auf ganz wenige anwenden lässt.

Teilsteils... Es gibt schon viele Patterns die man abstrakt formulieren kann nicht so wie du andeutest nur dieses eine

Und welche? Der gesamte Loki-Port ist bei der Anwendung in Wirklichkeit nur eine Instanz!

Hier wäre Hume's Meinung sehr wertvoll ...

[DocJunioR]

DocJunioR schrieb:

Ich wünsche mir eine Sammplung von Design-Pattern-Implementierungen in C++.
Diese sollten auch möglichst allgemeingültig sein.

Wo steht, dass ich auf biegen und brechen alle Patterns umgesetzt haben möchte?

Außerdem: Was nützen mir tolle Vorlagen, wenn ich sie doch wieder eintippen muss?
Natürlich muss man sie immer etwas anpassen, aber die Basisklassen bleiben ja die Gleichen- und auch deren Nutzung..

BTW: ich habe nie was gegen konstruktive Kritik. Allerdings find ich ehrlich gesagt in den letzten 2 Jahren einige Mitglieder dieses Forums zum K* * * *.
Dumme Sprüche klopfen wirkt vielleicht in nem B-Movie, aber in der Realität sollte man sich doch evtl. auf einen etwas freundlicheren Ton einigen.

Wenn wir das Thema nun wieder sachlich aufgreifen würden. Bin ja immer bereit, dazu zu lernen..

[Stud84]

Wo steht, dass ich auf biegen und brechen alle Patterns umgesetzt haben möchte?

Natürlich hast du nicht gesagt alle, aber darum gehts ja auch nicht. Es geht darum, dass du vielleicht 5 oder 6 Patterns, irgendsowas in der Größenordnung eben, in einer Bibliothek anbieten kannst, von über 25. Bei dieser Zählung hab ich aber schon mehr oder weniger nutzlose Implementierungen wie deine CommandHistory a.k.a. Stack mitgezählt.

Außerdem: Was nützen mir tolle Vorlagen, wenn ich sie doch wieder eintippen muss?

Was nützen mir tolle Taschenrechner, wenn ich doch wieder selbst denken muss?

Du hast einfach nicht verstanden, oder willst eben nicht verstehen, dass sich Design Patterns nicht mit in Bibliotheken zur Verfügung gestellten Komponenten oder Funktionen vergleichen lassen. Das sind vollkommen unterschiedliche Dinge, die auf einer ganz anderen Ebene der Programmierung abspielen.

[DocJunioR]

der stack war garnicht das pattern das ich hier implementiert habe, sondern das Command Pattern..

[Stud84]

der stack war garnicht das pattern das ich hier implementiert habe, sondern das Command Pattern..

Ach, die Klasse Comamnd ist also deine große Leistung? Ich will aber nicht zwangsweise char* für die Datenspeicherung benutzen müssen und ich will auch nicht, dass irgendwas ausgegeben wird. Denn dass sind bereits alles benutzerdefinierte Aktionen oder Eigenschaften, die das Command Pattern nicht vorschreibt.

So müsste das aussehen:

class Command {
    public:
        virtual void doCommand() = 0;
        virtual void undoCommand() = 0;

        virtual ~Command();
};

Was du also anbieten könntest, ist ein lediglich ein abstraktes Interface und genau deswegen werd ich mir auch eine zusätzliche Bibliothek dazulinken. Womit wir wieder darauf zurückkommen, dass alles, was du anbieten kannst, ein Stack ist.

[Jester]

Prof84 schrieb:

Und welche? Der gesamte Loki-Port ist bei der Anwendung in Wirklichkeit nur eine Instanz!

Das hast Du prima erkannt, daß bei der Anwendung alles bloß instanziiert wird. Ist nur leider völlig irrelevant.

Loki bietet zum Beispiel eine Factory an, die recht allgemein geschrieben ist.
Dennoch stimmt es natürlich, daß Design-Patterns sich nicht in Bibliotheken gießen lassen (zumindest nicht in Code-Bibliotheken, viele UML-Tools können einem Standard-Patterns generieren).

[DocJunioR]

Stud84 schrieb:

Ach, die Klasse Comamnd ist also deine große Leistung?

Also als Leistung hab ich's nicht gerade definiert. Immerhin sind das nur nen paar Zeilen, die man innerhalb einer halben Stunde runterbeten kann. Aber genau das will ich ja nicht immer wieder

Ich will aber nicht zwangsweise char* für die Datenspeicherung benutzen müssen und ich will auch nicht, dass irgendwas ausgegeben wird.

Du großer Meister wirst ja wohl casten können? Die Ausgabe ist auch nur ein Beispiel. Abgeleitete klassen werden diese Methoden einfach überschreiben und vergessen.

Was du also anbieten könntest, ist ein lediglich ein abstraktes Interface und genau deswegen werd ich mir auch eine zusätzliche Bibliothek dazulinken. Womit wir wieder darauf zurückkommen, dass alles, was du anbieten kannst, ein Stack ist.

Endlich mal ein sachlich artikuliertes Argument.. Ich lass gern mit mir reden.

Wenn man sich übrigens die 2000 anderen Postings von mir anschaut, merkt man vielleicht, dass ich gelegentlich einfach nur Gedanken aufschreibe um die Meinung anderer zu hören.

Trotzdem find ich, dass das Forum wieder freundlicher werden könnte..

[Stud84]

DocJunioR schrieb:

Du großer Meister wirst ja wohl casten können?

Warum sollte ich das überhaupt wollen? Warum sollte ich z.B: eine Zahl oder gar ein komplexeres Objekt als String abspeichern wollen? Natürlich muss ich das auch nicht, ich könnte es ja trotzdem in einem neuen eigenen Attribut dafür sichern, aber dann schlepp ich irgendwelche Altlasen mit mir her. Es ist einfach nicht generell, dass ich die Daten als char* speichern will, und demzufolge hat so ein Attribut auch nichts in einer generellen Klasse verloren.

DocJunioR schrieb:

Die Ausgabe ist auch nur ein Beispiel. Abgeleitete klassen werden diese Methoden einfach überschreiben und vergessen.

Es beginnt aber schon alleine damit zu behaupten, dass das Standartverhalten eines Commands die Ausgabe auf der Konsole ist, was einfach nicht stimmt. Noch dazu, wird man durch diese Standardimplementierung nichtmal dazu gezwungen diese Methode zu überschreiben, was dazu führen kann, dass man darauf vergisst.

Solltest du wirklich "Logging"-Funktionalität für deine Commands einbauen wollen, dann doch lieber so:

class LoggingCommand : public Command {
    private:
        Command& command;

    public:
        LoggingCommand(Command& command)
         : command(command) {
            // ...
        }

        void doCommand() {
            command.doCommand();
            cout << "Command done." << endl;
        }

        void undoCommand() {
            command.undoCommand();
            cout << "Command undone." << endl;
        }
}

[Jester]

Das ist übrigens ein Beispiel für einen Dekorierer, ebenfalls ein Muster, das sich nicht allgemein implementieren läßt.