Einführung in Design Patterns



  • Aha...

    Nun ja, warum soll ich da Smart Pointer reinbringen? Das verwirrt viele Leute eher, da eher wenige Leute mit SmartPointer arbeiten, und ich mich auch nicht zu sehr auf C++ fokussieren wollte.

    Und wenn man mit Polymorphie arbeitet, dann muss das Zeugs nun mal dynamisch allokiert werden



  • nep schrieb:

    Aha...

    Nun ja, warum soll ich da Smart Pointer reinbringen? Das verwirrt viele Leute eher, da eher wenige Leute mit SmartPointer arbeiten, und ich mich auch nicht zu sehr auf C++ fokussieren wollte.

    Und wenn man mit Polymorphie arbeitet, dann muss das Zeugs nun mal dynamisch allokiert werden

    Smart-Pointer wären IMHO besser, ja. Dieses schreckliche übermäßige Verwenden von rohen Pointern, obwohls in C++ nicht nötig ist, sorgt in meiner Erfahrung für enorm viele Fehler.

    Zum Thema "nicht auf C++ fokussieren"... wenn du C++ nicht nutzen willst, nimm ne andere Sprache, aber bitte kein verkrüppeltes C++.



  • ich bin auch gegen smart pointer aus ähnlichem grund wie nep
    einfach weil die meißten c++ mit rohen pointern gelernt haben und
    die beispiele mit rohen pointern verständlich und durchsichtig sind

    dass smart pointer in realer umgebung sinnvoller sind ist richtig aber
    ein ganz anderes thema



  • Sovok schrieb:

    ich bin auch gegen smart pointer aus ähnlichem grund wie nep
    einfach weil die meißten c++ mit rohen pointern gelernt haben und
    die beispiele mit rohen pointern verständlich und durchsichtig sind

    dass smart pointer in realer umgebung sinnvoller sind ist richtig aber
    ein ganz anderes thema

    Tut mir leid aber das ist großer Mist.
    Zum einen würde es sicher ausreichen kurz zu erläutern, was ein smart pointer ist.
    Beu Tutorials ist es wichtig immer den richtigen und sichersten weg zu wählen, damit andere davon lernen können. Warum also nicht smart pointer benutzen. An der Verständnis kann es sicherlich nicht liegen, denn:
    Foo *bar = new Foo();
    bar->blub()
    oder
    auto_ptr<Foo>bar(new Foo());
    bar->blub();
    ist alles andere als ein riesiger schwer zu verstehende Unterschied.
    Das einzige was nötig wäre, ist dem Leser kurz zu vermitteln was so ein Zeiger Container macht. Also bei zerstörung des containers automatisch den Inhalt freigeben und somit Speicherlecks zu verhindern und ansonsten die Nutzung des Objektes wie immer von statten geht.
    Das ist ebenso verständlich wie mit rohen pointern plus zusätzlicher Sicherheit. Solche Grundlegenden Dinge sollten auch in so einem Tut genutzt und wenn nötig kurz erklärt werden.

    Wenn etwas beibringen, dann auch richtig.

    Schöne Grüße



  • also erstmal Danke für diesen Artikel! Habe dadurch endlich nach 2 Tagen eine funktionierende Observer Subject Struktur hinbekommen. Es gibt noch einen kleinen Fehler

    class ConcrecteSubject : public Subject

    da hast du ein c zu viel. Ansonst Danke für diesen Artikel ich teste jetzt mal das Strategie Pattern!

    // ConcreteSubject.h //
    #include <string>
    #include "Subject.h"
    
    using namespace std;
    
    class ConcrecteSubject : public Subject
    {
    
    private:
        string data;
    
    public:
        void setData(string _data) { data = _data; }
        string getData() { return data; }
        ConcreteSubject() : Subject() {}
    };
    

    Gruß bEKAR



  • Super Artikel, genau danach habe ich gesucht und auf anhieb gefunden 😉 👍



  • Super Artikel, danke auch von meiner Seite! 👍



  • Sehr guter Artikel, dickes Dankeschön auch von mir 👍

    Lg freeG



  • Vielen Dank für den Artikel!
    Im Adapter-Pattern habe ich zwei Fehler entdeckt resp. in der Erzeugung der Objekte über den Iterator:
    1. begin() und end() sind doch Funktionen also sollte man die Klammern nicht vergessen
    2. sollte man den Iter inkrementieren und nicht die Liste

    Deine Version:
    //alle gemoetrischen Figuren anzeigen
    list<Shape*>::iterator iter = shapes.begin();
    for ( ; iter != shapes.end; shapes++ )
    (*iter)->display();

    Verbesserte Version:
    //alle gemoetrischen Figuren anzeigen
    list<Shape*>::iterator iter = shapes.begin();
    for ( ; iter != shapes.end(); iter++ )
    (*iter)->display();

    Habe mir nur den Adapter angeschaut möglicherweise gibts im Artikel weitere Fehler



  • Guter Artikel, steckt viel Arbeit drin.

    Eine Seite die ich nicht mehr missen möchte ist diese:
    https://dotnetcodr.com/architecture-and-patterns/


Anmelden zum Antworten