Polymorphie in Templates

dot

Skym0sh0 schrieb:

nein, aber geht sowas in c++?

Bei templates ist sowas nicht notwendig, das geht dort implizit. Ein template funktioniert automatisch für jeden Typ der die notwendigen Operationen unterstützt.

skNiNe

Die Klasse Document => Schnittstelle zum Zugriff auf eine Dokumentart, also bspw. eine Datei auf dem Filesystem.

Ich möchte nun alle geöffneten bzw. erstellten Documents in eine liste werfen, um bspw. prüfen zu können, ob ich das Document schon mal geladen hab bzw. schon geladen ist. Jedoch kann der Inhalt variieren, bspw. wchar_t oder char (diese Typen würde ich Document als Parameter übergeben).

Ist mal eine vereinfachte Form.

dot

class DocumentBase
{
public:
  virtual bool isOpen() = 0;
};

template <class CharType>
class Document : public DocumentBase
{
  ...
};

list<DocumentBase*> bla;

skNiNe

dot schrieb:

class DocumentBase
{
public:
  virtual bool isOpen() = 0;
};

template <class CharType>
class Document : public DocumentBase
{
  ...
};

list<DocumentBase*> bla;

Mh ne sowas mein ich nicht :(.

template<typename T>
class Document {
	T get();
};

Angenommen ich möchte jetzt rein zur Verwaltung alle Documents irgendwo weg speichern? Wie stellt man das am besten an? Natürlich wenn die Documents mit unterschiedlichen T's erstellt wurden.

dot

Das geht so nicht. Wenn du alle gemeinsam behandeln willst müssen sie eine gemeinsame Basis haben.

skNiNe

Mh aber selbst wenn ich jetzt folgendes habe:

struct DocumentBase {
	// irgendwas
};

template<typename T>
struct Document : DocumentBase {
	T value;

	Document(T _value) {
		value = _value;
	}
};

Das hier funktioniert:

int main(int argc, char **argv) {
	Document<int> di(1337);
	Document<char> dc('c');

	std::list<Document<int>*> bases;
	bases.push_back(&di);
	//bases.push_back(&dc);

	// Cast zwar überflüssig, aber funktioniert
	Document<int> *dic = dynamic_cast<Document<int>*>(bases.front());
	if (dic != 0) {
		cout << dic->value << endl;
	}

	return 0;
}

Aber da hier dann wieder nicht. Krieg ich selbst mit einem Cast die tatsächlichen Template-Instanzen raus?

int main(int argc, char **argv) {
	Document<int> di(1337);
	Document<char> dc('c');

	std::list<DocumentBase*> bases;
	bases.push_back(&di);
	bases.push_back(&dc);

	Document<int> *dic = dynamic_cast<Document<int>*>(bases.front());
	if (dic != 0) {
		cout << dic->value << endl;
	}

	return 0;
}

dot

Das sollte so schon funktionieren. Aber besonders schön ist das nicht. Warum genau musst du von der Liste wieder auf die verschiedenen Typen kommen!?

skNiNe

Ehrlichgesagt muss ich mein Konzept nochmal genau durchdenken ob das überhaupt nötig ist. Aber selbst wenn nicht, würde mich interessieren wie man sowas macht (falls sowas geht).

An dieser Stelle bedanke ich mich schon mal bei allen hier

dot

skNiNe schrieb:

Ehrlichgesagt muss ich mein Konzept nochmal genau durchdenken ob das überhaupt nötig ist.

Ja das dürfte ziemlich sicher dringend nötig sein.

skNiNe schrieb:

Aber selbst wenn nicht, würde mich interessieren wie man sowas macht (falls sowas geht).

Naja, prinzipiell "gehts" so wie du es gemacht hast: Indem man castet. Allerdings ist ein Downcast praktisch immer Symptom einens groben Designfehlers, daher sollten bei Code wie dem da oben sofort die Alarmglocken läuten...

skNiNe

Aber wie ist es bspw. beim Factory-Pattern? Hier kann ja im Endeffekt nur etwas abstraktes zurück kommen. Hier müsste man ja auch eine Unterscheidung treffen (dynamic_cast) was das nun ist und wie es weiter zu behandeln ist oder?

volkard

int main(int argc, char **argv) {
	Document<int> di(1337);
	Document<char> dc('c');

	std::list<DocumentBase*> bases;
	bases.push_back(&di);
	bases.push_back(&dc);

	DocumentBase *dic = bases.front();
	dic->printAt(cout);

	return 0;
}

Aber wie ist es bspw. beim Factory-Pattern? Hier kann ja im Endeffekt nur etwas abstraktes zurück kommen. Hier müsste man ja auch eine Unterscheidung treffen (dynamic_cast) was das nun ist und wie es weiter zu behandeln ist oder?

Wirklich?

dot

skNiNe schrieb:

Aber wie ist es bspw. beim Factory-Pattern? Hier kann ja im Endeffekt nur etwas abstraktes zurück kommen. Hier müsste man ja auch eine Unterscheidung treffen (dynamic_cast) was das nun ist und wie es weiter zu behandeln ist oder?

Es ist doch gerade der Sinn von Abstraktion dass man das nicht muss!? Du abstrahierst ja damit der restliche Code nurmehr mit dieser Abstraktion arbeiten muss ohne sich darum zu kümmern was genau es nun ist.

XSpille

skNiNe schrieb:

Aber selbst wenn nicht, würde mich interessieren wie man sowas macht (falls sowas geht).

Also generell kann man eine Wrapper-Klasse schreiben...
Hier nur mal etwas Beispiel-Code, ich weiß nicht, ob es einfacher geht...

Aber für den Zuweisungsoperator oder Copy-Konstruktor, braucht man wohl intern einen Zeiger auf eine Klasse mit virtuellen Funktionen

An der Komplexität siehst du, dass es wohl eher eine theoretische Möglichkeit einer Lösung ist.

#include <iostream>
#include <vector>

template<typename T>
class InternalVectorWrapper{
public:
	virtual ~InternalVectorWrapper(){}
	virtual InternalVectorWrapper<T>* copy() const = 0;
	virtual T& operator[](unsigned int i) = 0;
	virtual unsigned int size() = 0;
};

template<typename Type, typename TBase>
class SpecificVectorWrapper : public InternalVectorWrapper<TBase>{
public:
	SpecificVectorWrapper(std::vector<Type>& list) : list(list){
	}

	virtual InternalVectorWrapper<TBase>* copy() const {
		return new SpecificVectorWrapper<Type, TBase>(*this);
	}
	virtual TBase& operator[](unsigned int i){
		return list[i];
	};

	virtual unsigned int size(){
		return list.size();
	}

private:
	std::vector<Type>& list;
};

template<typename TBase>
class VectorWrapper{
public:
	template<typename T>
	VectorWrapper(std::vector<T>& t) : ptr(new SpecificVectorWrapper<T, TBase>(t)){}
	~VectorWrapper(){ delete ptr; }

	VectorWrapper(const VectorWrapper<TBase>& w){
		this->ptr = w.ptr->copy(); 
	}

	// Zuweisungsoperator implementieren...

	TBase& operator[](unsigned int i){
		return ptr->operator[](i);
	}

	unsigned int size(){
		return ptr->size();
	}

protected:
	InternalVectorWrapper<TBase>* ptr;
};

class Fruit{
public:
	virtual ~Fruit(){}
	virtual void print_name() = 0;
};

class Banana : public Fruit{
public:	
	virtual void print_name(){
		std::cout << "banana" << std::endl;
	}
};

class Apple : public Fruit{
public:	
	virtual void print_name(){
		std::cout << "apple" << std::endl;
	}
};

class FruitBasket{
public:
	virtual VectorWrapper<Fruit> get_list(); 
};

class BananaBasket{
public:
	BananaBasket(){
		basket.push_back(Banana());
		basket.push_back(Banana());
	}

	virtual VectorWrapper<Fruit> get_list(){
		return basket;
	}

private:
	std::vector<Banana> basket;
};

class AppleBasket{
public:
	AppleBasket(){
		basket.push_back(Apple());
		basket.push_back(Apple());
		basket.push_back(Apple());
	}

	virtual VectorWrapper<Fruit> get_list(){
		return basket;
	}

private:
	std::vector<Apple> basket;
};

void print(VectorWrapper<Fruit>& list){
	// Hier braucht man natürlich noch andere Funktionen in ListWrapper
	for(int i=0; i< list.size(); ++i){
		list[i].print_name();
	}
}

int main(){
	AppleBasket apples;
	BananaBasket bananas;
	VectorWrapper<Fruit> apple_list = apples.get_list();
	VectorWrapper<Fruit> banana_list = bananas.get_list();
	print(apple_list);
	print(banana_list);
}

apple
apple
apple
banana
banana

Gruß,
XSpille

skNiNe

Das weiss ich, aber es gibt trotzdem Fälle in denen man nicht drum herum kommt (soweit ich weiss).

Ein Fall der mir grad im Kopf rum schwirrt:
Man möchte einen Instant-Messenger entwickeln. Man bekommt über Sockets serialisierte Objekte gesendet, die kann man an Hand einer Factory wieder deserialisieren und whatever damit machen. Wenn man die abstrakte Message (bspw. Datei, Nachricht oder irgendwas) dann hat, muss trotzdem unterschieden werden an Hand des genauen Typs, wie diese weiterverarbeitet werden soll.

volkard

skNiNe schrieb:

Das weiss ich, aber es gibt trotzdem Fälle in denen man nicht drum herum kommt (soweit ich weiss).

Ein Fall der mir grad im Kopf rum schwirrt:
Man möchte einen Instant-Messenger entwickeln. Man bekommt über Sockets serialisierte Objekte gesendet, die kann man an Hand einer Factory wieder deserialisieren und whatever damit machen. Wenn man die abstrakte Message (bspw. Datei, Nachricht oder irgendwas) dann hat, muss trotzdem unterschieden werden an Hand des genauen Typs, wie diese weiterverarbeitet werden soll.

oder man ruft die virtuelle Methode verarbeite() auf.

skNiNe

Mh die Message soll tatsächlich selbst wissen wie sie verarbeitet wird? Ich finde es naheliegender wenn die Message nur ihre Daten beinhaltet und durch nen speziellen Handler verarbeitet wird (der evtl. auch die nötigen Referenzen auf andere Objekte hält die zur Verarbeitung nötig sind).

volkard

skNiNe schrieb:

Mh die Message soll tatsächlich selbst wissen wie sie verarbeitet wird? Ich finde es naheliegender wenn die Message nur ihre Daten beinhaltet und durch nen speziellen Handler verarbeitet wird (der evtl. auch die nötigen Referenzen auf andere Objekte hält die zur Verarbeitung nötig sind).

Mhmm, die Message kommt über eine Connection rein.

msg->process(&connection);

wäre schonmal generell möglich.
Und in process kann sich die Message bestimmt von der Connection auch den Nick oder die Sitzung holen, den Server oder wasauchimmer. Vielleicht.
Ich halte es für überlegenswert.

skNiNe

Also wch will meinen Gedankengang nicht als DEN besten darstellen. Aber ich kann mcih damit nicht anfreunden, wenn in einer Message (reines Datenobjekt) irgendwelche Funktionalität implementiert wird. Da würde mir der Bezug zur Realität fehlen (was ja mit im Fokus der OOP steht). Wenn ich Post bekomme, weiss der Brief auch nicht was er nun machen muss. Davon abgesehen finde ich das Konzept der selbstverwaltung der Messages unflexibel. Es müsste eine fette Schnittstelle existieren um die nötigen Referenzen auf die Messages zu setzen bzw. zu übergeben. Was ist wenn neue Messages dazu kommen und weitere bzw. andere Informationen zusätzlich brauchen? Schnittstellenänderungen und alles hin und her usw. ... Da finde ich es persönlich sauberer einmal in einer Factory per dynamic_cast den passenden Handler für die Message zu ermitteln und die Funktionalität von der Message sauber getrennt zu haben.

+ Höhere Erweiterbarkeit / Flexibilität
+ Sauberere Trennung

- Typüberprüfung zur Laufzeit

Da bin ich dann doch am überlegen was sinnvoller ist.

PS: Wie gesagt, ich will nicht meine Lösung als die beste darstellen, sondern einfach die richtigerere Lösung diskutieren.

volkard

Och, ich stellte mir vor, daß die Factory den Stream liest und Messages aus dem Bytestrom baut. Das sind sozusagen über's Netz geschickte Funktionsaufrufe.
Man kann auch erst nur Messages empfangen, reine Datenobjekte, und dann mit einer Factory daraus den benötigten Handler erzeugen.
Das ist jetzt für mich gar kein großer ideologischer Unterschied.
Ich weiß nicht, ob ich "Saubere Trennung" überhaupt haben will.

dot

Um was für Messages handelt es sich da, wie sind die aufgebaut und wie sollen sie verarbeitet werden?