Bücher, Bücher, Bücher - aber welche?

Blue-Tiger

Brutus schrieb:

Naja, im sog. Gang of Four Book ist schon meist C++ Code als Beispiel enthalten, aber es ist eher theoretischer Natur, zumal sich die Implementationsbeispiele abwechseln, entweder mal in C++ oder halt in Smalltalk (oder beides)
Dennoch ist es, wie Jester schon sagte, sehr gut. Man sollte halt überlegen, welche Edition man nimmt, englisch oder deutsch.. (Ich sag nur Objektgranularität ;))

On a sidenote: ich denke "Head first Design Patterns" ist ein wesentlich besseres Einsteigerbuch ueber Entwurfsmuster. Didakisch super und sehr unterhaltsam zum lesen. Gibts jetzt sogar auf Deutsch. Ich wuerd dir absolut dazu raten. "Effektive C++" von S. Meyers ist logisch auch eine top Empfehlung.

Entwurfsmuster von Kopf bis Fuß | ISBN: 3897214210

Danke, die Lady sieht auch gut aus , aber zu spät.
Habs schon am Montag abend gekauft, und die ersten Abschnitte sind echt schonmal gut. Was das Deutsch betrifft, naja, is ok. An Exemplar statt Instanz muss man sich gewöhnen.
"Effective C++" steht nun auf der Liste für nächsten Monat, mir fehlt grad das Geld.

Offtopic: Ich hab was ganz strubes geträumt. War bei einer Frau zu Hause, die hatte ein ganzez Regal voll Programmierbücher, da hab ich etwas drin rumgestöbert. Neben C++ und Java fand ich eins über Smalltalk. Ich hab dann irgendeinen tollen Spruch gebracht, im Sinn von, "Naja, dann können wir ja nachher etwas Smalltalk machen" oder so ähnlich. Es war so doof, dass ich aufgewacht bin und lachen musste
Oh mann ich hasse solche Träume, danach bin ich immer so verwirrt..

Gregor

Brutus schrieb:

Naja, im sog. Gang of Four Book ist schon meist C++ Code als Beispiel enthalten, aber es ist eher theoretischer Natur, zumal sich die Implementationsbeispiele abwechseln, entweder mal in C++ oder halt in Smalltalk (oder beides)

Ich bin mir nicht so sicher, ob das Buch aus C++-Sicht so gut ist. Vor einiger Zeit habe ich hier mal mitgekriegt, dass sich das Verständnis der Objektorientierung bei vielen C++lern in diesem Forum "erweitert" hat. Offensichtlich liegt dem heutigen C++-Stil ein anderes OOP-Verständnis zu Grunde, als zum Beispiel der Java-Programmierung oder der C#-Programmierung oder auch der älteren C++-Programmierung.

Dieses Buch, das objektrientierte Entwurfsmuster darstellt, basiert eher auf dem Java-C#-AltC++-Verständnis der Objektorientierung. Wenn Du Dir da heute noch für Deinen Umgang mit C++ dieses Buch kaufst, dann solltest Du damit rechnen, dass Du aus C++-Sicht vielleicht veraltete Muster lernst, zu denen es inzwischen in der C++-Welt überlegene Alternativen gibt.

Aber ich bin da kein Experte. Vielleicht sollte da mal so'n C++-Guru etwas zu sagen.

Shade Of Mine

Design Pattern passen in C++ genau wie in Java - nur die implementierung ist halt verschieden (zB kann man Strategy in C++ sehr schoen ueber Templates loesen. Man verliert dabei zwar das dynamische austauschen der Strategy zur Runtime, aber das ist meistens ja egal. Oder abstract factory - auch super ueber statische Polymorphie loesbar. - das nur so als Beispiel. Die DPs selber bleiben dabei ja erhalten, sie sind nur anders implementiert - oder (kleiner seitenhieb) wie class adapater ueberhaupt implementierbar :p)

Heads First Design Pattern ist fuer den Einstieg in DP einfach nur genial. Habe es letztens selber gelesen und muss sagen, liest sich besser als ein Roman.

Die Standard C++ Buecher sind:

Effective C++
More Effective C++
Effecive STL
Exception C++
More Exceptional C++
Exceptional C++ Style

Die kann man alle lesen und lernt was dabei.

Gregor

Shade Of Mine schrieb:

Design Pattern passen in C++ genau wie in Java - nur die implementierung ist halt verschieden (zB kann man Strategy in C++ sehr schoen ueber Templates loesen. Man verliert dabei zwar das dynamische austauschen der Strategy zur Runtime, aber das ist meistens ja egal. Oder abstract factory - auch super ueber statische Polymorphie loesbar. - das nur so als Beispiel. Die DPs selber bleiben dabei ja erhalten, sie sind nur anders implementiert - oder (kleiner seitenhieb) wie class adapater ueberhaupt implementierbar :p)

ok. Ich habe es natürlich immer noch nicht verstanden. Kannst Du mir folgende Fragen beantworten?

Im GoF-Buch werden oft C++ Beispielcodes für Designpatterns gebracht: Stimmen die von Dir vorgeschlagenen Implementierungen mit diesen überein?
Im GoF-Buch sind allerlei UML-Diagramme abgebildet: Stimmen die von Dir vorgeschlagenen Implementierungen mit diesen überein?

Jester schrieb:

Zumindest effektiv C++ programmieren von Scott Meyers sollte jeder C++-Programmierer gelesen haben.

Gehts da darum wie man schnell mit C++ zum ergebnis kommt oder wie man schnellen c++ code schreibt?

Shade Of Mine

Gregor schrieb:

Im GoF-Buch werden oft C++ Beispielcodes für Designpatterns gebracht: Stimmen die von Dir vorgeschlagenen Implementierungen mit diesen überein?

Im GoF-Buch sind allerlei UML-Diagramme abgebildet: Stimmen die von Dir vorgeschlagenen Implementierungen mit diesen überein?

sie sind eine moegliche implementierung.

Beispiel
abstract factory

GoF schreibt:

class MazeFactory {
    public:
        MazeFactory();

        virtual Maze* MakeMaze() const
            { return new Maze; }
        virtual Wall* MakeWall() const
            { return new Wall; }
        virtual Room* MakeRoom(int n) const
            { return new Room(n); }
        virtual Door* MakeDoor(Room* r1, Room* r2) const
            { return new Door(r1, r2); }
    };

das ist natuerlich vollkommen in ordnung.

jetzt kommt aber das interessante:

Maze* MazeGame::CreateMaze (MazeFactory& factory) {
        Maze* aMaze = factory.MakeMaze();
        Room* r1 = factory.MakeRoom(1);
        Room* r2 = factory.MakeRoom(2);
        Door* aDoor = factory.MakeDoor(r1, r2);

        aMaze->AddRoom(r1);
        aMaze->AddRoom(r2);

        r1->SetSide(North, factory.MakeWall());
        r1->SetSide(East, aDoor);
        r1->SetSide(South, factory.MakeWall());
        r1->SetSide(West, factory.MakeWall());

        r2->SetSide(North, factory.MakeWall());
        r2->SetSide(East, factory.MakeWall());
        r2->SetSide(South, factory.MakeWall());
        r2->SetSide(West, aDoor);

        return aMaze;
    }

das kann ich aber auch so schreiben:

template<class Factory>
    Maze* MazeGame::CreateMaze (Factory& factory) {
        Maze* aMaze = factory.MakeMaze();
        Room* r1 = factory.MakeRoom(1);
        Room* r2 = factory.MakeRoom(2);
        Door* aDoor = factory.MakeDoor(r1, r2);

        aMaze->AddRoom(r1);
        aMaze->AddRoom(r2);

        r1->SetSide(North, factory.MakeWall());
        r1->SetSide(East, aDoor);
        r1->SetSide(South, factory.MakeWall());
        r1->SetSide(West, factory.MakeWall());

        r2->SetSide(North, factory.MakeWall());
        r2->SetSide(East, factory.MakeWall());
        r2->SetSide(South, factory.MakeWall());
        r2->SetSide(West, aDoor);

        return aMaze;
    }

und schon haette ich die virtuellen aufrufe in der factory eleminiert.
das UML diagramm wuerde dann fast komplett gleich bleiben. nur dass wir statt
ConcreteFactory erbt von AbstractFactory ein "ConcreteFactory complies to the interface of AbstractFactory" oder eine aehnliche formulierung haetten. Oder vl etwas OOPiger "ConcreteFactory implements the Concept of AbstractFactory".

Jedenfalls hat man dann trotzdem nen strich mit nem pfeil im UML diagramm :p

etwas interessanter wird es vielleicht bei Strategy:

class Composition {
    public:
        Composition(Compositor*);
        void Repair();
    private:
        Compositor* _compositor;
        Component* _components;    // the list of components
        int _componentCount;       // the number of components
        int _lineWidth;            // the Composition's line width
        int* _lineBreaks;          // the position of linebreaks
                                   // in components
        int _lineCount;            // the number of lines
    };

man beachte dass in dem GoF beispiel der Compositor nicht zur runtime gewechselt werden kann. manche leute behaupten Strategy verlangt dass man zur runtime wechseln kann - ich denke es ist eher ein feature wenn es moeglich ist, aber nicht zwangslaeufig noetig. denn meistens will ich eh nicht wechseln...

template<class Compositor>
    class Composition {
    public:
        Composition();
        void Repair();
    private:
        Compositor _compositor;
        Component* _components;    // the list of components
        int _componentCount;       // the number of components
        int _lineWidth;            // the Composition's line width
        int* _lineBreaks;          // the position of linebreaks
                                   // in components
        int _lineCount;            // the number of lines
    };

und wieder haben wir die Vererbung von AbstractStrategy zu ConcreteStrategy aufgeloest und durch statische Polymorphie ersetzt. Mit allen ihren Vorteilen und allen ihren Nachteilen.

diese 2 varianten der implementierung sind nicht besser oder schlechter als die GoF variante - einfach nur anders und uU genau das was man in einer Situation haben will (oder eben auch nicht).

Die implementierung variiert bei den DPs sowieso sehr oft. In der freien Wildbahn sieht man da ja ne Menge... Man sollte dabei aber nie das wesentliche aus den Augen verlieren:

ein DP ist ein Ansatz fuer eine Loesung zu einem gaengigen Problem.

Es ist keine fertige Loesung und auch kein non plus ultra heilmittel. Sondern nur ein Ansatz den man verfolgen kann wenn man dieses oder jenes Problem hat...

Shade Of Mine

dfvvdfuzb schrieb:

Jester schrieb:

Zumindest effektiv C++ programmieren von Scott Meyers sollte jeder C++-Programmierer gelesen haben.

Gehts da darum wie man schnell mit C++ zum ergebnis kommt oder wie man schnellen c++ code schreibt?

es geht dabei darum wie man guten Code schreibt.

Es sind quasi eine Handvoll richtlinien an die man sich halten soll. Wenn man das macht, wird man vielen fehlern vorbeugen koennen. Und es wird auch immer gut erklaert _warum_ man es so machen soll und nicht anders...

NCC-1701 schrieb:

An Exemplar statt Instanz muss man sich gewöhnen.

Autsch. das ist ja fast so gut wie "vektor" anstelle von "array" in der deutschen Übersetzung vom K&R

Blue-Tiger

TactX schrieb:

NCC-1701 schrieb:

An Exemplar statt Instanz muss man sich gewöhnen.

Autsch. das ist ja fast so gut wie "vektor" anstelle von "array" in der deutschen Übersetzung vom K&R

das kommt in "Entwurfsmuster" auch vor