Abstrakte Klassen in C++?

[MoonGuy]

Nunja, seit langem auch mal wieder da.
Dank des äußerst guten Tutorials hier, hatte ich eigentlich noch keinen nachlese Bedarf und wirklich Zeit für Posts hier im Forum hatte ich auch nicht, da war zuviel mit Hobby, Arbeit, Schule.
Aber ich habe so eine Frage aus reiner Neugier(muss ja in der Schule sowieso mit Java arbeiten...):
Also, ich habe in der Schule gelernt, dass Java abstrakte Klassen besitzt. Den Namen hatte ich vorher nie so gehört, aber der Inhalt des Unterrichts klang stark nach Interfaces. In C++ sind Interfaces ja Klassen, die virtuelle Methoden haben. Das bedeutet, die Klasse ist i.d.R. nur zum Vererben gedacht. Allerdings hätte ich gerne eine Klasse, welche nur zum Vererben gedacht ist, aber einige Methoden sind nicht virtuell, denn sie arbeiten ausschließlich mit protected Attributen, was sich ja in den Unterklassen nicht ändert. Kann ich irgendwie das instanziieren der Klasse verhindern und nur das Vererben ermöglichen, oder muss ich einfach andere Programmierer durch Kommentare darauf hinweisen bzw. ihnen mitteilen, dass es total sinnlos wäre, folgende Klasse zu instanziieren? Oder muss ich den new Operator überladen und so dem Bösen ein Ende bereiten?

[Panke]

Den Namen hatte ich vorher nie so gehört, aber der Inhalt des Unterrichts klang stark nach Interfaces

Abstrakte Klassen und Interfaces sind in Java etwas stark unterschiedliches. Zum Beispiel kann eine Klasse nur von maximal einer abstrakten Klasse erben, aber beliebig viele Interfaces implementieren.

Nur abstrakte Klassen lassen in Java Standardimplementierungen von Methoden zu.

In C++ sind Interfaces ja Klassen, die virtuelle Methoden haben.

Nein. Zuerst gibt es kein Sprachmittel "Interface" in C++. Das was man benutzt, um das
gleiche wie Java-Interfaces zu modellieren, sind abstrakte Klassen ohne Datamember,
die (nur) aus (rein-)virtuellen Methoden bestehen. Eine Methode ist reinvirtuell, wenn
sie in abgeleiteten Klassen implementiert werden _muss_. Syntax: "=0".

Allerdings hätte ich gerne eine Klasse, welche nur zum Vererben gedacht ist, aber einige Methoden sind nicht virtuell, denn sie arbeiten ausschließlich mit protected Attributen, was sich ja in den Unterklassen nicht ändert.

Also sollen die Methoden in Java-Sprech final sein? Warum? Und warum sind die
Attribute protected? Irgendwie klingt das nach schlechter Kapselung, so ganz ohne
Kontext.

Kann ich irgendwie das instanziieren der Klasse verhindern und nur das Vererben ermöglichen, oder muss ich einfach andere Programmierer durch Kommentare darauf hinweisen bzw. ihnen mitteilen, dass es total sinnlos wäre, folgende Klasse zu instanziieren?

Mache eine Methode rein-virtuell und man muss erben und diese implementieren.
Der Operator-New zu implementieren, ist hier der völlig falsche Ansatz.

[MoonGuy]

Du hast mich völlig falsch verstanden. Ich bezog mich gar nicht auf Java-speech, in keinster Weise. Ich meine das eher so:

Code: Alles auswählen

public class BaseClass {
procted:
    int iAttribut; // ein Attribut was von der Superklasse(z.b. von vMethode) als auch von Unterklassen verwendet wird
public:
    void vMethode(){} // arbeitet mit iAttribut und ist für alle Unterklassen gleich, also brauch nicht überschrieben werden
};

Die BaseClass soll nun nicht instanziiert werden, da man sie als solches, einzeln nicht braucht, aber es gibt mehrere Unterklassen, welche die BaseClass in sich erben.

[Bebu]

Das dürfte kein Problem sein, denn wenn ich nicht ganz auf dem Holzweg bin, dann lassen sich Klassen nicht instanzieren, wenn sie auch nur eine einzige pure-virtual Funktion enthalten. Solche Klassen können nur vererben, aber nicht selber genutzt werden, sonst wird der Kompiler meckern.

[Panke]

Die BaseClass soll nun nicht instanziiert werden, da man sie als solches, einzeln nicht braucht, aber es gibt mehrere Unterklassen, welche die BaseClass in sich erben.

Sollte noch offen sein, wie das funktioniert, es geht so:

Mache eine Methode rein-virtuell und man muss erben und diese implementieren.
Der Operator-New zu implementieren, ist hier der völlig falsche Ansatz.

Hinweis: Falls man keine Methode als Kandidaton findet, bietet sich der Destruktor an.

http://www.smart2help.com/e-books/ticpp ... Heading448

[Xin]

Nunja, seit langem auch mal wieder da.
Dank des äußerst guten Tutorials hier, hatte ich eigentlich noch keinen nachlese Bedarf und wirklich Zeit für Posts hier im Forum hatte ich auch nicht, da war zuviel mit Hobby, Arbeit, Schule.

Och, ich sehe an den Tutorials noch genug Verbesserungsbedarf. Habe vorgestern erst noch einen groben Schnitzer aus einem C-Text rausgeholt, der den Wiki-Text quasi unlesbar machte.

Aber ich habe so eine Frage aus reiner Neugier(muss ja in der Schule sowieso mit Java arbeiten...):
Also, ich habe in der Schule gelernt, dass Java abstrakte Klassen besitzt. Den Namen hatte ich vorher nie so gehört, aber der Inhalt des Unterrichts klang stark nach Interfaces. In C++ sind Interfaces ja Klassen, die virtuelle Methoden haben. Das bedeutet, die Klasse ist i.d.R. nur zum Vererben gedacht.

Interfaces sind gewissermaßen abstrakte Klassen, die ausschließlich abstrakte Methoden und keine Membervariablen haben.

Allerdings hätte ich gerne eine Klasse, welche nur zum Vererben gedacht ist, aber einige Methoden sind nicht virtuell, denn sie arbeiten ausschließlich mit protected Attributen, was sich ja in den Unterklassen nicht ändert. Kann ich irgendwie das instanziieren der Klasse verhindern und nur das Vererben ermöglichen, oder muss ich einfach andere Programmierer durch Kommentare darauf hinweisen bzw. ihnen mitteilen, dass es total sinnlos wäre, folgende Klasse zu instanziieren? Oder muss ich den new Operator überladen und so dem Bösen ein Ende bereiten?

Du kannst sie nicht instanziieren. Du kannst nur Ableitungen einer abstrakten Klasse instanziieren, die alle abstrakten (in C++ spricht man hier von "pure virtual") Methoden implementiert hat.

Du kannst aber einen Referenz auf eine abstrakte Klasse auf eine Implementation zeigen lassen. Wie die Implementierung dann aussieht, weißt du nicht. So kann Tier abstrakte Methoden besitzen, die in Hund und Katze unterschiedlich implementiert sind. Eine Tierreferenz kann damit aber auf einen Hund oder eine Katze zeigen. Das ist eben objekt-orientierte Programmierung.

http://www.proggen.org/doku.php?id=cpp:oop:interface

Hinweis: Falls man keine Methode als Kandidaton findet, bietet sich der Destruktor an.

Wenn eine Klasse (Edit: statt Klasse stand da Funktion) virtuelle Funktionen enthält, sollte der Destruktur grundsätzlich ebenfalls virtuell angelegt sein, selbst dann, wenn erst Ableitungen virtuelle Funktionen enthalten werden.

[Panke]

Wenn eine Funktion virtuelle Funktionen enthält, sollte der Destruktur grundsätzlich ebenfalls virtuell angelegt sein, selbst dann, wenn erst Ableitungen virtuelle Funktionen enthalten werden.

Guter und wichtiger Hinweis. Ich meinte den Fall, dass eine Klasse abstrakt sein soll, man aber nicht weiß, welche Methode man rein virtuell machen soll.

[MoonGuy]

Achso, also reicht eine virtuelle Methode aus, um die Klasse abstrakt zu gestalten.
Zu den Tutorials: Ja, ich finde auch ab und an noch Stelen, wo ich mir mehr Tiefgang wünsche, aber ich bezog mich auf früher, als ich hier noch aktiver war und da hatte ich die Tutorials hier und Quellen aus Schule und diversen englischsprachigen Portalen vereint, um mir Wissen anzueignen.
Zum Destruktor, wird dieser denn überhaupt mitvererbt? Also, der Konstruktor wird nicht mitvererbt, soweit ich weiß, in Java kann man diesen aber über super ansteuern in der Art von this. C++ bietet das soweit ich weiß nicht. Aber wie sieht das dann mit dem Destruktor aus?

So kann Tier abstrakte Methoden besitzen, die in Hund und Katze unterschiedlich implementiert sind. Eine Tierreferenz kann damit aber auf einen Hund oder eine Katze zeigen. Das ist eben objekt-orientierte Programmierung.

Grundpfeiler des Polymorphismus?

[Xin]

Achso, also reicht eine virtuelle Methode aus, um die Klasse abstrakt zu gestalten.

Nein. Eine virtuelle Tabelle ist ein Array mit Funktionspointern. Ein Objekt schaut also in der Tabelle nach, welche Funktion gerufen werden soll, wenn Du eine virtuelle Funktion rufst.

Die Funktion ist abstrakt (oder in C++ pure virtual), wenn in der Tabelle noch kein Funktionszeiger existiert. Der Name der Funktion existiert als Interface, so dass der Compiler weiß, dass jede "class Tier" eine Methode "gibLaut()" hat, die sind aber nur in "class Hund" und "class Katze" implementiert. Darum kannst Du auch kein Tier mit new erstellen, weil der Compiler nicht weiß, was er tun soll, wenn Du "gibLaut()" rufst.
Du kannst aber eine Referenz auf ein Tier auf einen Hund oder eine Katze zeigen lassen. Hunde und Katzen haben eine vollständig gefüllte VTable, ruft man die Tier-Referenz dann mit gibLaut(), so wird aus der VTable des Hundes oder der Katze die Funktion aufgerufen, die für das Objekt den angemessene Laut ("Wau", "Miau") ausgibt.

Zu den Tutorials: Ja, ich finde auch ab und an noch Stelen, wo ich mir mehr Tiefgang wünsche, aber ich bezog mich auf früher, als ich hier noch aktiver war und da hatte ich die Tutorials hier und Quellen aus Schule und diversen englischsprachigen Portalen vereint, um mir Wissen anzueignen.

Wenn Dir in den proggen.org-Tutorials der Tiefgang fehlt, dann gib das bitte als Feedback zurück. Stell also Fragen, die Dir das Tutorial nicht beantwortet hat, oder gib Antworten ins Forum, die Du im Tutorial vermisst.
Alternativ kannst Du auch gleich die fehlenden Informationen mit dem Autor absprechen und selbst eintragen.

Zum Destruktor, wird dieser denn überhaupt mitvererbt? Also, der Konstruktor wird nicht mitvererbt, soweit ich weiß, in Java kann man diesen aber über super ansteuern in der Art von this. C++ bietet das soweit ich weiß nicht. Aber wie sieht das dann mit dem Destruktor aus?

Es wird immer erst der Destruktor der abgeleiteten Klasse gerufen, dann der Destruktor der Basisklasse.

Nehmen wir wieder Tier und Katze.

Code: Alles auswählen

Tier * tier = new Katze();

Wenn Du nun "delete tier" aufrufst, wird der Destruktor "Tier::~Tier()" gerufen, aber eben nicht "Katze::~Katze()". Wenn der Destruktor von Tier aber virtuel ist, dann trägt die Klasse "Katze()" als Destruktor eben "~Katze()" in die VTable ein und der Aufruf "delete tier" ruft wie zuvor den Destruktor, muss diesen aber über die VTable nachschlagen. In der VTable steht "~Katze()", entsprechend wird erst ~Katze() gerufen und ~Katze ruft am Ende des Katzen-Destruktors den Tier-Destruktor auf.

So kann Tier abstrakte Methoden besitzen, die in Hund und Katze unterschiedlich implementiert sind. Eine Tierreferenz kann damit aber auf einen Hund oder eine Katze zeigen. Das ist eben objekt-orientierte Programmierung.

Grundpfeiler des Polymorphismus?

Ja, Nein, Vielleicht.

Polymorphismus ist ein recht polymorpher Begriff in der Informatik, darum taucht er in meinem Tutorium auch nicht auf, weil er keine konkrete Aussage trifft.
Wenn Du eine ambivalente Frage stellst, fällt eine boolische Antwort schwer. ^^