Abstrakte Klasse

Hallo, ich bin irgendwie damit überfordert eine abstrakte Basisklasse zu schaffen, die keinerlei Funktionalität hat.

Im Grunde will ich so etwas wie
"Komponente"
haben. Eine Komponente muss nichts können, sondern einfach nur den Typ haben, nur wie schaffe ich es, dass keine leeren Komponenten erzeugt werden?
Der Weg, den ich kenne, ist es irgendeine Methode wie foo()=0; einzubauen. Aber meine Komponente hat keine Methoden.

Zum zweiten:
Eine Klasse soll aus solchen Komponenten bestehen, ich möchte aber, dass bestimmte Typen von Komponenten (sozusagen die Grundkomponenten) auf jeden Fall vorkommen, wie macht man das halbwegs elegant?

Und nochwas:
Jeder Komponententyp darf nur einmal vorkommen, um Probleme zu vermeiden.

Sorry für Doppelpost, aber einwas wäre da noch:
Gibt es eine Standard C++ Lösung um eine Klasse nicht erbbar zu machen?
Also es soll keine Klasse geschrieben werden können, die von dieser einen abgeleitet ist, ich glaube boost hatte so etwas, aber gibts etwas ohne boost?

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