Nachdem ich mich so allmählich durch das Buch "Modern C++ Design, Generic Programming and Design Patterns Applied" von Andrei Alexandrescu welze, überlege ich ständig, wo ich am sinnvollsten Templates im Quellcode nutzen kann.

Jüngster Einsatz ist bei einer Klasse, die Daten aus einer Datei liest. Ich möchte es deshalb abstrahieren, weil das später evtl. in anderen Formaten/Backends (Datenbank zum Bleistift) möglich sein soll.

Daher folgendes Design:

template <class Loader> 
class ItemsetLoader : public Loader { 
    public: 
        static bool LoadFromFile( const std::string& filename, model::Itemset& itemset ); 
}; 

template <class Loader> 
bool ItemsetLoader<Loader>::LoadFromFile( const std::string& filename, model::Itemset& itemset ) { 
    return Loader::LoadFromFileImpl( filename, itemset ); 
} 

// Ein Beispiel-Loader für YAML: 
class YAMLItemsetLoader { 
    protected: 
        static bool LoadFromFileImpl( const std::string& filename, model::Itemset& itemset ); 
};

"itemset" ist hier schlichtweg das Objekt, welches die Daten empfangen soll. Ist ein solches Design sinnvoll? Ich persönlich finde es recht sexy, wollte aber sicherheitshalber mal rumfragen.

Man könnte natürlich auch einfach getrennte Klassen bauen, wie z.B. YAMLLoader, DBLoader, XYZLoader etc., die einfach alle LoadFromFile() implementiert haben. Aber ich finde die Idee gut, dass es ein gemeinsames Interface gibt.

In dem Beispiel macht es eigentlich nicht so viel aus, wenn das mit Klassen lösen würdest. Aber das schöne an diesem Ansatz ist, ist, dass du jetzt noch etwas anderes dazu tun kannst und keine extra Klasse definieren brauchst. z.B:

template <class Loader, class Deleter>
class ItemsetLoader : public Loader {
    public:
        static bool LoadFromFile( const std::string& filename, model::Itemset& itemset );
    static void DeleteFile ( const std::string& filename){...}
};

class NormalLoader
{...};

class FancyLoader
{...};

class NormalDeleter
{...};

class FancyDeleter
{...};

Da kannst du jetzt varieren, wie du willst. Stell dir vor du müsstest jede Möglichkeit der Normal und Fancy Klasse ausprogrammieren. Und im Normal Fall gibt es ja mehr, als 4 Möglichkeiten. Das ausrechnen spare ich mir hier mal.

Diese Technik wird im übrigen in der Standardbibliothek recht oft benutzt.

Also finde ich das durchaus eine gute Überlegung. Vor allem kann man dem User die Freiheit überlassen gewisse Sachen selbst zu steuern, wenn der Bedarf da ist. Wenn nicht gibt es ja noch die Default Template Parameter.

Man könnte natürlich auch einfach getrennte Klassen bauen, wie z.B. YAMLLoader, DBLoader, XYZLoader etc., die einfach alle LoadFromFile() implementiert haben. Aber ich finde die Idee gut, dass es ein gemeinsames Interface gibt.

Nein, bei deinem Beispiel ist da nichts gemeinsam. Es ist höchstens ein marignaler Unterschied, wenn du anstatt YAMLLoader ein ItemsetLoader<YAMLItemsetLoader> schreibst. Dadurch hast du noch nichts gewonnen. Den Typen musst du immer noch mitschleppen. Das was dein Ansatz so wie er jetzt ist macht, ist nichts weiter, als eine weitere Ebene an Komplexität hinzuzufügen.

Policy based design ist nur Sinnvoll, wenn die Klasse die einzelnen Policies sinnvoll miteinander kombiniert. Das heißt, die äußere Klasse organisiert, und die Policies führen die konkreten Aktionen aus. Wenn es aber nichts zu organisieren gibt, ist der ganze Designansatz irgendwie...komisch.

Ich denke, an der Stelle sollte man sich immer schön an occam's razor halten: Wenn es zwei Wege gibt etwas zu machen, dann nimm den einfacheren.

Anders wäre es wohl, wenn es einen Loader gibt, der Policy-Klassen wie YAML, TXT etc. als Datenquelle nutzt, richtig? Soweit möchte ich natürlich nicht gehen, aber rein von der Theorie sollte das so passen.

Ich danke Dir für den Anstoß.

Dennoch auch von Dir interessante Anregungen, Danke.