Abstrakte Klasse

theta

Aber meine Komponente hat keine Methoden.

Und wie, was und wann tut denn eine solche Komponente irgendwas?

Falls es Dir nur darum geht, eine abstrakte Klasse ohne Methoden zu machen:
Mach einfach den Destruktor rein virtuell und implementiere ihn trotzdem.

Einfach den Destruktor pure virtual machen.

krümelkacker

shisha schrieb:

Eine Komponente muss nichts können, sondern einfach nur den Typ haben

Design-Kritik: Es klingt so, als wolltest Du eine dynamic_cast-Orgie starten. Igitt!

@Krümelkacker:
welche Alternativen habe ich denn zur dynamic_cast-Orgie?

Also was ich haben möchte ist so etwas wie

Toolkit
{
 Grundkomponente A
 Grundkomponente B
 Grundkomponente C
 Andere Komponenten
}

Wobei es bei andere Komponenten jede Menge Möglichkeiten geben kann. Und nur weil ich eine Komponente mehr haben möcht, will ich nicht vom Toolkit erben müssen inder Art:

erweitertes Toolkit: Toolkit
{
 Zusätzliche Komponente D
}

Gibts da irgendwas eleganteres?

dot

Ich versteh nicht, wofür brauchst du Komponenten wenn die Komponenten dann nichts können, das klingt irgendwie sinnlos

Komponente soll der Oberbegriff sein, die einzelnen Implementierungen können dann natürlich etwas.

Toolkit
{
Komponenten
}

Komponente
{
//einfach damit das Toolkit sie annehmen kann
}

KomponentenTypA
{
  tuWas()  -> müssen alle von Typ A haben
}

KomponentenTypAImplementierung
{
//zusätzlich
  meine Variablen
  tuWasAnderes()
}

RHBaum

erweitertes Toolkit: Toolkit
{
 Zusätzliche Komponente D
}

Das riecht sowieso schon nach Design-Fehler

Vererbung niemals, um sich TippArbeit zu sparen.
"Ist implementiert mit" ist eine Composition, kein Inheritance !

class erweitertes_Toolkit
{
    Zusätzliche_Komponente D;
    Toolkit                Base;
};

Ist eh sauberer im Design ...

Es sei denn, Toolkit und erweitertes_Toolkit sollen gleichbehandelt werden, also Codeanteile machen keinen unterschied zwischen den Beiden.
Dann ist vererbung natuerlich angebracht und auch notwendig!
Dann haben wir aber auch eine "Ist ein" Beziehung !

Ciao ...

dot

Wie wärs mit:

class ComponentA;
class ComponentB;
...

class Toolkit
{
public:
  virtual ComponentA* GetComponentA() = 0;
  virtual ComponentB* GetComponentB() = 0;
  ...
};

Artchi

Bei uns im Java-Projekt gibt es auch solche leeren Interfaces. Dann wird einfach abgefragt, ob das Objekt eine Instanz vom Interface-Typ ist, und es wird dann darauf entsprechend reagiert. Ziemlich Un-OO.

Ich denke mal, in C++ wird so was eher über Type Traits gelöst?

krümelkacker

Artchi schrieb:

Bei uns im Java-Projekt gibt es auch solche leeren Interfaces. Dann wird einfach abgefragt, ob das Objekt eine Instanz vom Interface-Typ ist, und es wird dann darauf entsprechend reagiert. Ziemlich Un-OO.

Ich denke mal, in C++ wird so was eher über Type Traits gelöst?

Wenn der dynamische Typ zur Compile-Zeit nicht bekannt ist, helfen Type Traits nicht weiter. Type Traits sind auch eher dazu da, Eigenschaften von bereits bekannten Typen zu erfragen.

Thingy t = ....;
if (t instanceof SuchAndSuch) {
  SuchAndSuch s = (SuchAndSuch) t;
  s.transmogrify();
  ....
}

-->

Thingy* t = ....; // Thingy is a polymorphic class type
if (auto s = dynamic_cast<SuchAndSuch*>(t)) {
  s->transmogrify();
}

K*cke sieht das aber in beiden Fällen aus, ob Java, ob C++.

314159265358979

Warum eigentlich auto und nicht auto* schreiben? Für mich wirkt die Zeile mit auto* viel logischer