Habe eine Klasse "Controller", die einen "upperConnector", einen "lowerConnector" sowie ein dazwischenliegendes "Protocol" verwaltet.
"upperConnector" und "lowerConnector" sind vom Typ "FileConnector" und können konkret als "COM_Connector" oder "TCP_Connector" (beide von "FileConnector" abgeleitet) durch den "Controller" instanziiert werden. Welche Typen der "Controller" verwenden soll, bekommt er im Konstruktor per int-define mitgeteilt.

Nun benötigen sowohl TCP_Connector als auch COM_Connector jedoch noch parameter, welche ich durch eine leere Interface-Klasse "Params" realisiere. Von "Params" wird dann wiederum eine Klasse "TcpParams" und eine Klasse "ComParams" abgeleitet und dem "Controller"-Konstruktor ebenfalls übergeben. Hier mal der Konstruktorkopf :

Controller::Controller(int upperFileConnector, int lowerFileConnector, int Protocol, Params upperConnectorParams, Params lowerConnectorParams)

Nun müsste ich natürlich im Konstruktor-Block prüfen, ob upperConnectorParams vom Typ her ("Tcp- oder "ComParams") zu dem unter upperFileConnector vorgegebenen "FileConnector" passt.
mit typeid und dynamic_cast möchte ich nur ungern arbeiten.
Kennt ihr eine bessere Lösung oder gibt es gar ein Pattern für diesen Fall?

Meine restliche Architektur finde ich recht schön OO und möchte sie nicht durch so nen blöden Aufruf verhunzen.

(btw, wenn du die Param's by value übergibst, wirst du nicht viel Freude von den abgeleiteten Parameter-Klassen haben ;))

Ich würde andersherum angehen und die "int define"s nicht als eigenständigen Parameter, sondern als Teil der jeweiligen Param-Klasse übergeben - dann kann diese selber sicherstellen, daß die Angabe zu ihr "passt".

Meinst du sowas wie: "Params" bekommt eine Membervariable int "connectorTyp", in der ich den jeweiligen define stecke!? Sowas hab ich mir auch schon überlegt. dann würde also mein Konstruktor so aussehen:

Controller::Controller(int Protocol, Params upperConnectorParams, Params lowerConnectorParams)

(btw, wenn du die Param's by value übergibst, wirst du nicht viel Freude von den abgeleiteten Parameter-Klassen haben ;))

Das sehe ich wohl ein ;-))

Aber so richtig zufrieden bin ich immer noch nicht. evtl. sollte ich meinen Controller nochmal aufteilen: in den "funktionalen teil", der das Polling durch die Connectoren etc. macht und einen "konstruktionalen (!?) teil", der die Instanziierung, koppelung usw. erledigt!?

ich werd mal drüber schlafen. Dank Dir trotzdem CStoll
weitere Vorschläge sind herzlich willkommen!

ja, das war auch mein erster Ansatz. Hat auch gut funktioniert, wurde aber abgelehnt
Die Begründung war, dass der Controller ja schließlich auch kontrollieren solle und die beiden (bzw. drei, mit Protocol) Instanzen selbst erzeugen solle.

Ich denke ich werde den funktionalen teil des Controllers ("scheduling" + "eventhandling") in eine neue Klasse "Scheduler" stecken, welche die fertig instanziierten Connectoren übergeben bekommt und den Rest der Klasse Controller so implementieren, dass sie von der main() die geparsten argumente als defines sowie die Parameter bekommt und dementsprechend die Instanziierung vornimmt.

Werde diese "Controller"-Restklasse dann wohl auch in "AppLauncher" umbennenen müssen, denn ein Controller lieg ja dann eigentlich nicht mehr vor...

wie mache ich eigentlich eine leere (Interface) Klasse abstrakt in C++?

mir fällt da spontan nur private vitural methode ein:

#ifndef _PARAMS_H_
#define _PARAMS_H_

//empty Interface Class
class Params{
	private: 
		virtual void ichtunix() = 0;
};

#endif //_PARAMS_H_

Seh ich das richtig?

class empty_interface
{
public:
  virtual ~empty_interface() = 0;
};

//ist notwendig trotz der abstrakt Deklaration, weil der Basis-Dtor automatisch aufgerufen wird:
empty_interface::~empty_interface()
{}

ich will doch gerade verhindern, dass der Basis Dtor aufgerufen wird, da ja die Abgeleiteten Objekte i.d.R. mehr Speicher belegen und wieder freigeben müssen.
Leider findet sich zu diesem Thema weder hier
http://de.wikibooks.org/wiki/C%2B%2B-Programmierung:_Polymorphie#Virtuelle_Destruktoren
etwas, noch in meinem Nachschlagewerk ("C++ für Programmierer" RRZN Uni Hanover, 11. Auflage")

Kannst du das ein wenig näher erleutern? was passiert, wenn ich den Dtor nicht definiere? Ich bin bisher noch nie auf die Idee gekommen eine abstr. methode zu definieren (Ableitungen natürlich ausgenommen).

Du kannst (und willst) lediglich verhindern, daß Interface-Objekte angelegt werden können - und das sichert dir der Compiler zu, wenn du der Klasse eine (egal welche) abstrakte Methode gibst.

Du kannst (und willst) lediglich verhindern, daß Interface-Objekte angelegt werden können - und das sichert dir der Compiler zu, wenn du der Klasse eine (egal welche) abstrakte Methode gibst.

Das war mir soweit klar.

Der Destruktor wird auf jeden Fall aufgerufen - implizit durch den Dtor der jeweiligen abgeleiteten Klasse. Daran kannst du nichts ändern.

Das ist mir neu. Dachte, der basis-Dtor verhält sich so, wie der basis-Ctor. Der wird ja auch nicht implizit aufgerufen, wenn das abgeleitete Objekt instanziiert wird. Oder täusch ich mich da!?

Der Destruktor wird auf jeden Fall aufgerufen - implizit durch den Dtor der jeweiligen abgeleiteten Klasse. Daran kannst du nichts ändern.

Das ist mir neu. Dachte, der basis-Dtor verhält sich so, wie der basis-Ctor. Der wird ja auch nicht implizit aufgerufen, wenn das abgeleitete Objekt instanziiert wird. Oder täusch ich mich da!?

Doch, auch der Basis-Ctor wird automatisch aufgerufen - wenn du nichts anderes in der Initialisierungsliste angibst, der Default-Ctor (d.h. der ohne Parameter).

(und wenn es keinen Default-Ctor in der Basisklasse gibt, macht dich der Compiler drauf aufmerksam)