www.mikrocontroller.net

Forum: PC-Programmierung Mehrfachvererbung


Autor: Frank der gott (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mehrfachvererbungfür was wbrauchn man das

Autor: John Small (linux_80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das haben sich die Java Erfinder auch gefragt
;-)

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wenn dein Object z.b. 2 verschieden Interface untestützt

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tiny 80 schrieb:
> Das haben sich die Java Erfinder auch gefragt
> ;-)

Daß sie es weggelassen haben, lag wohl weniger am mangelnden Sinn
als an dem Aufwand, das umzusetzen.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit Mehrfachvererbung eine Entwicklung durchgemacht

* am Anfang wusste ich nicht wozu
* dann ein paar mal probiert und Gefallen daran gefunden
* dann in Probleme gelaufen
* Mehrfachvererbung verdammt und nicht mehr benutzt
* Auf den Interface-Trichter gekommen
* Gemerkt, dass Mehrfachvererbung mit Interfaces keine Probleme macht
* Dabei geblieben. Regel: Mehrfachvererbung nur mit Interfaces

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Angenommen, du hast eine Klasse Fahrzeug (Leergewicht, Gesamtmasse,
Art des Fahrwerks, ...), davon ist ein Pkw abgeleitet (zusätzlich
Sitzplätze) und ein LKW (Zuladung etc.).

Weiterhin gibt es eine Klasse Hebemaschine (Tragkraft etc), davon
abgeleitet Portalkran, Auslegerkran, etc..

Jetzt willst du einen Autokran machen.
Aber wovon ableiten? Es ist eigentlich ein LKW mit etwas dazu,
aber auch eine Hebemaschine.
Leitest du den Autokran vom LKW ab, fehlen die Sachen aus der
Klasse Hebemaschine und müssten parallel implementiert werden.
In Situationen, wo eine Hebemaschine genutzt werden kann, kann
man den Autokran dann nicht verwenden.
Leitest du ihn dagegen von der Hebemaschine ab, müssten die
LKW-Sachen neu programmiert werden und das Resultat kann nicht
als Fahrzeug verwendet werden.

Also leitet man ihn einfach von LKW und von Hebemaschine ab
und wird damit glücklich. Damit ist ein Autokran sowohl
ein LKW (und damit ein Fahrzeug) als auch eine Hebemaschine.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank der gott (Gast) wrote:

> Mehrfachvererbungfür was wbrauchn man das

braucht man nicht, siehe

"Erläuterung des Begriffs Mehrfachvererbung"

"Mehrfachvererbung ist in der Welt der objektorientierten Programmierung 
die Vererbung von mehreren Klassen gleichzeitig."

"C++: möglich
Java: nicht möglich
VB6: nicht möglich
VB.NET: nicht möglich
C#: nicht möglich"

.NET kommt auch ohne aus, also wozu der Aufwand?!

(jetzt gibt es bestimmt Mecker von den eingefleischten C++'ern :-))

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Natürlich kann man ohne auskommen.
Aber man kommt auch ohne OO aus, ohne ordentliches Bier
und ohne Sex.
Aber will man das?
Mehrfachvererbung vermisst man dann nicht, wenn man sie gar
nicht kennt.

Interfaces (Java) sind ein müder Abklatsch, weil ihre
Implementierung nicht vererbt wird und in jeder weiteren Ableitung
neu gestrickt werden muss - nicht ganz im OO-Sinne und nur tragbar,
wenn im Einzelfall nicht viel dahinter steckt.
Man braucht Mehrfachvererbung sicher nicht oft, aber manchmal
ist es ohne nur ein Gemurkse. Wer also nur C# und VB programmiert,
braucht es dementsprechend nicht :-)

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... also wozu der Aufwand?!
Es ist doch auffällig, dass Sprachen, die Wert auf einen 
funktionierenden Garbage Collector legen, keine Mehrfachvererbung 
kennen.
In C++ sollte es Aufgabe des Entwicklers sein, den Speicher zu pflegen.
In JAVA soll der Entwickler sich nicht um solche 'Details' kümmern. Ich 
kenne auch keine etablierte Interpretersprache die das Konzept der 
Mehrfachvererbung kennt.

Klaus hat ja schon ein sinnvolles Beispiel für Mehrfachvererbung 
genannt. Ich denke, Mehrfachvererbung wird schlicht und einfach dann 
nicht implementiert, wenn man einen narrensicheren Garbage Collector für 
alle Situationen braucht.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils schrieb:
>> ... also wozu der Aufwand?!
> Es ist doch auffällig, dass Sprachen, die Wert auf einen
> funktionierenden Garbage Collector legen, keine Mehrfachvererbung
> kennen.
> In C++ sollte es Aufgabe des Entwicklers sein, den Speicher zu pflegen.
> In JAVA soll der Entwickler sich nicht um solche 'Details' kümmern. Ich
> kenne auch keine etablierte Interpretersprache die das Konzept der
> Mehrfachvererbung kennt.
>
> Klaus hat ja schon ein sinnvolles Beispiel für Mehrfachvererbung
> genannt. Ich denke, Mehrfachvererbung wird schlicht und einfach dann
> nicht implementiert, wenn man einen narrensicheren Garbage Collector für
> alle Situationen braucht.

Den Zusammenhang kann ich nicht sehen.
Ein Garbage Collector kümmert sich um Objekte. Ob dieses Objekt jetzt 
über mehrere Vererbungspfade verfügt, ist ja fürs Objekt Jacke wie Hose. 
Objekt ist Objekt.

Aber mit Mehrfachvererbung kann man sich bitterböse ins Schwierigkeiten 
bringen, wenn die Vererbungspfade zum Vater hin wieder zusammenlaufen 
(sog. Diamond Shape Inheritance)

          A
        /   \
       /     \
     B         C
       \     /
        \   /
          D

Oder um bei Klausens Beispiel zu bleiben.

Ein LKW ist ein Kraftfahrzeug, aber auch eine Hebebühne könnte ein 
Kraftfahrzeug sein. Ist dann ein Autokran ein doppeltes Kraftfahrzeug?
(Stichwort: virtuelle Vererbung)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Zusammenhang mit GC sehe ich auch nicht so recht, außer
darin, daß sowohl Mehrfachvererbung als auch eigene Verantwortung
für Speicherorganisation scharfe, aber auch gefährliche Werkzeuge
sind.
Viele Sprachen versuchen, ihre Anwender von Fehlern fern zu halten,
C++ ermöglicht alles, was vielleicht mal nötig ist, und zwar
so effizient wie möglich.

Man kann C++ natürlich zu Recht vorwerfen, daß vieles darin
gefährlich ist. Aber so ist das halt mit scharfem Werkzeug;
wer nicht mit Behindertenmessern arbeiten will, muß selber
zusehen, daß er sich nicht selbst die Augen öffnet.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Den Zusammenhang mit GC sehe ich auch nicht so recht, außer
> darin, daß sowohl Mehrfachvererbung

Wenn ich mich recht erinnere, gibt es bei Mehrfachvererbung auch 
Probleme mit dem Slicing, wenn man nicht aufpasst.

> C++ ermöglicht alles, was vielleicht mal nötig ist, und zwar
> so effizient wie möglich.

Und das ist das, was ich an C++ so mag. Ich behalte in den für mich 
wichtigen Bereichen die volle Kontrolle. Und wenn beim Pofiling raus 
kommt, dass eine Klasse überdurchschnittlich oft durch new und delete 
durch muss und das dann noch signifikant zur Laufzeit beiträgt, dann 
statte ich die Klasse mit einer Poolallokierung aus und drücke so die 
Laufzeit (normalerweise) wieder in ein erträgliches Mass. Auch 
Speicherfragmentierung kann man so ziemlich wirkungsvoll begegnen.

Das alles sind für mich Gründe, warum ich das Speichermanagement so 
ungern in die Hand eines GC lege. Mit ein bischen Disziplin ist es dann 
auch gar nicht so schwer Klassen zu schreiben, die eine Resource 
dynamisch verwalten oder Reference Couting betreiben (ich weiß: bei 
Multithreading gibt das Probleme). In C++ kann ich mir mein Werkzeug 
aussuchen.

>
> Man kann C++ natürlich zu Recht vorwerfen, daß vieles darin
> gefährlich ist. Aber so ist das halt mit scharfem Werkzeug;
> wer nicht mit Behindertenmessern arbeiten will, muß selber
> zusehen, daß er sich nicht selbst die Augen öffnet.

Ein wahres Wort!

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Den Zusammenhang kann ich nicht sehen.
> Ein Garbage Collector kümmert sich um Objekte. Ob dieses Objekt jetzt
> über mehrere Vererbungspfade verfügt, ist ja fürs Objekt Jacke wie Hose.
> Objekt ist Objekt.

Wenn eine Sprache nur über eine Einfach-Vererbung verfügt, ist das 
Kriterium für das automatische Entfernung eines Objekts sehr simpel:
So lange noch ein Verweis auf das Objekt existiert, darf das Objekt 
nicht gelöscht werden. Existiert kein Verweis mehr, kann das Objekt 
entfernt werden. Manche Interpretersprachen zählen dazu einfach die 
Anzahl der Verweise. Einige dieser Sprachen kennen konsequenterweise 
auch keinen Destruktor.

Bei Vererbungspfaden können beliebig komplizierte Objektbäume entstehen. 
Ich denke, es ist schwierig (vielleicht sogar allgemein nicht lösbar) 
Kriterien für das automatische Löschen von Objekten zu finden. Daher 
meine Vermutung:
Interpretersprachen und Sprachen, die Bytecode erzeugen (in dem Sinne, 
dass ein Bytecode interpretiert wird) machen es sich hier einfach und 
verzichten schlicht auf die Mehrfachvererbung.

Korrigiert mich bitte, wenn ich falsch liege.

Autor: java_fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man kann auch bei Java eine eigene Speicherverwaltung verwenden.

Man holt sich den Speicher von der eigenen Speicherverwaltung im 
Konstruktor und gibt in der finilize Methode wieder frei.

Man kann bei Java auch einen "Destruktor" für bestimmte Klassen bauen. 
(einer klasse finilize methode vererben als public).

Man muss diesen "Destruktor" bei Bedarf aufrufen.

Reference Counting ist somit auch einfach und sinnvoll möglich. Man muss 
nur die Objekte von Hand entsorgen, sonst gammeln sie evtl   lange vor 
sich hin bis der GC sie "abholt".

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>... Man muss nur die Objekte von Hand entsorgen...
Darauf wollte ich hinaus: Es gibt Sprachen, die ihr Paradigma auf den 
Schwerpunkt des automatischen Entsorgen von Objekten legen. Soweit ich 
JAVA kenne, wird dies auch hier bevorzugt.

Bei den interpretierbaren 'Server-Sprachen' ist das die Präferenz, 
ebenso bei den genannten VisualBasic-Dialekten.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ist der Garbage Collector sowas wie die Bad Bank für die 
Finanzindustrie?

:-)

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also ist der Garbage Collector sowas wie die Bad Bank für die
> Finanzindustrie?
... und alle warten auf den großen Crash?
So gesehen muss Madoffs für Mehrfachvererbung in den Knast wandern.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Nils:

> Wenn eine Sprache nur über eine Einfach-Vererbung verfügt, ist das
> Kriterium für das automatische Entfernung eines Objekts sehr
> simpel:
> So lange noch ein Verweis auf das Objekt existiert, darf das Objekt
> nicht gelöscht werden.

Das ändert sich bei Mehrfachvererbung doch nicht.

@Karl heinz:

> Auch Speicherfragmentierung kann man so ziemlich wirkungsvoll
> begegnen.

Gerade das ist ein Punkt, wo ein Garbage Collector einen Vorteil haben 
kann. Da er alle Zeiger auf ein Objekt kennt bzw. ermitteln kann, ist es 
ihm möglich, Objekte während ihrer Lebenszeit im Speicher zu verschieben 
und damit den Speicher zu defragmentieren. Setzt natürlich voraus, daß 
der GC das auch macht.

@java_fan:

>Man kann bei Java auch einen "Destruktor" für bestimmte Klassen
> bauen.
> Man muss diesen "Destruktor" bei Bedarf aufrufen.

Da sehe ich den größten Nachteil von GC-Sprachen. Das gilt ja nicht nur 
für Speicher, sondern generell für alle Ressourcen. In C++ kann ich eine 
Ressource schön in einer Klasse kapseln. Wenn ich z.B. ein File-Objekt 
zerstöre, wird die Datei automatisch vom Destruktor geschlossen. Bei 
Java nicht so. Da muß ich das immer explizit machen. Deshalb gibt es bei 
Java für's exception handling auch ein "finally" und bei C++ nicht. C++ 
braucht sowas gar nicht, weil es Destruktoren gibt, die automatisch 
aufgerufen werden.
Man erkauft sich mit Java also ein automatisches Speichermangement, 
indem man sich dazu zwingen läßt, immer sämtliche anderen Ressourcen 
manuell zu verwalten.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast schrieb:
> Also ist der Garbage Collector sowas wie die Bad Bank für die
> Finanzindustrie?
>
> :-)

:o)

Autor: (gast) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Python unterstützt Mehrfachvererbung, wird interpretiert und hat einen 
GC.

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lisp (sowohl interpretierter code als auch compilierter) hat auch 
mehrfachvererbung, nur heißts da anders, weil das standard wurde als es 
das schöne wort noch nicht gab.

das war 1980 mit dem dialekt "Flavors" :-)

Autor: r auscher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein weiteres Problem bei Mehrfachvererbung ist die Möglichkeit, dass 
zwei   Elternklassen die gleichen Eigenschaften haben können.

Z.B. bei C++ wird dann nur die Eigenschaft aus einer Klasse verwendet.

Ein Amphipienfahrzeug (Auto und Schiff) kann wie ein Auto auf der Straße 
fahren und wie ein Schiff auf dem Wasser.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In C++ kann man das mit einem zusätzlichen virtual an der richtigen
Stelle steuern, wie man es haben will.

Wird eine Eigenschaft von beiden Seiten geerbt und man greift
ohne weitere Benamsung darauf zu, bekommt man einen Compilerfehler.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils schrieb:
>> ... also wozu der Aufwand?!
> Es ist doch auffällig, dass Sprachen, die Wert auf einen
> funktionierenden Garbage Collector legen, keine Mehrfachvererbung
> kennen.
> In C++ sollte es Aufgabe des Entwicklers sein, den Speicher zu pflegen.
> In JAVA soll der Entwickler sich nicht um solche 'Details' kümmern. Ich
> kenne auch keine etablierte Interpretersprache die das Konzept der
> Mehrfachvererbung kennt.

Eine der ersten Sprachen die auf das .NET-Framework portiert wurden, war 
Eiffel. BTW auch eine der ganz wenigen Sprachen, die im Gegensatz zu 
C++, Mehrfachvererbung richtig implementieren. 1)
OCaml kennt auch Mehrfachvererbung (zum normalen System gehören sowohl 
Interpreter, als auch Bytecode-Interpreter und nativer Compiler).
Wenn man möchte, kann man auch das was Python macht, als 
Mehrfachvererbung durchgehen lassen.
Alle genannten Sprachen haben Garbage Collection.

1) einige Details der Implementation gibt's hier 
http://msdn.microsoft.com/en-us/library/ms973898.aspx

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe schon ein paar größere Projekte mit Java umgesezt.
Und eigentlich bin ich immer mit interface+abstrakten Klassen gut dabei 
ausgekommen.
An den Stellen wo ich mir gedacht habe: Jezt wäre Mehrfachvererbung 
nützlich hat sich nach einigem Nachdenken doch herausgestellt das es 
doch anders (u.U. sogar besser) ging.

Klaus Wachtler schrieb:
> Jetzt willst du einen Autokran machen.
...
> Aber wovon ableiten? Es ist eigentlich ein LKW mit etwas dazu,
Eben es ist eigentlich ein LKW mit etwas dazu... und keine Ortsfeste 
Hebemaschine.
> aber auch eine Hebemaschine.
> Leitest du den Autokran vom LKW ab, fehlen die Sachen aus der
> Klasse Hebemaschine und müssten parallel implementiert werden.
Warum also nicht einen LKW der als zusätzliche Eigenschaft 
(Membervariable) eine Hebemaschine hat? (die Auf der Ladefläche montiert 
ist ;) )
> In Situationen, wo eine Hebemaschine genutzt werden kann, kann
dann einfach über einen Getter die Hebemaschine(neigenschaften) genuzt 
werden.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. schrieb:
> ...
> Warum also nicht einen LKW der als zusätzliche Eigenschaft
> (Membervariable) eine Hebemaschine hat? (die Auf der Ladefläche montiert
> ist ;) )
>> In Situationen, wo eine Hebemaschine genutzt werden kann, kann
> dann einfach über einen Getter die Hebemaschine(neigenschaften) genuzt
> werden.

Weil man diesxes Gebilde dann nicht z.B. in eine
std::list<Hebemaschine> einfügen kann.
Es hat nach deinem Vorschlag zwar eine Hebemaschine, ist aber keine
und darf damit halt nicht dort verwendet werden, wo man eine braucht.

Den Containern in Java ist der Typ erstmal schnurz und macht ggf. erst
zur Laufzeit Probleme, in C++ dagegen hat der Compiler den Daumen auf
dem Datentyp (ob das gut ist oder nicht, darüber kann man lange 
streiten).

(das "ortsfest" hast du dir nur im Nachhinein ausgedacht, um eine
strengere Unterteilung zu erzwingen - so streng hierarchisch ist
die Welt aber nicht immer).

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seit Java 1.5 gibt es auch die Möglichkeit getypte Listen zu erstellen.
Die Frage ist halt warum man in die Liste den ganzen "LKW/HEBEMASCHINE" 
Combo reinstopfen will, man kann aus Objekten der Liste eh nur auf 
Eigenschaften von 'Hebemaschine' zugreifen. Also kann man im Zweifel 
auch nur die Referenz der LKW Hebemaschine da reinstecken.

> das "ortsfest" hast du dir nur im Nachhinein ausgedacht, um eine
> strengere Unterteilung zu erzwingen
Ja das stimmt, ich wollte damit nur ausdrücken das für mich in diesem 
Falle die Beiden Dinge sich in einer Grundlegenden Eigenschaft 
unterscheiden, sonst könnten sie ja auch beide von einem gemeinsammen 
Objekt abstammen.

>ob das gut ist oder nicht, darüber kann man lange
>streiten
Streiten wollte ich mich sowieso nicht, was Typprüfung angeht bin ich 
ganz klar der Verfechter von soviel Typprüfung zur Compilezeit wie 
möglich :)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja, dann willkommen bei C++!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:

> (das "ortsfest" hast du dir nur im Nachhinein ausgedacht, um eine
> strengere Unterteilung zu erzwingen - so streng hierarchisch ist
> die Welt aber nicht immer).

Ja, leider :-)

Auf der anderen Seite sind wir Gott sei Dank in der Situation, dass 
unsere Programme immer nur einen begrenzten Ausschnitt aus der realen 
Welt modellieren müssen, und man die Hierarchie dann oft genug noch 
sinnvoll hinbiegen kann.

Wenn ich in die Versuchung komme Mehrfachvererbung zu machen (abgesehen 
von Interfaces), dann werte ich das als Indiz, nochmal über meine 
Klassenhierarchie nachzudenken und ob sie alle Aspekte, die ich 
modellieren möchte auch hinreichend berücksichtigt. Bisher hat sich dann 
immer noch eine Alternative aufgetan.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, man kommt notfalls immer ohne aus.
Ebenso wie man notfalls überhaupt ohne Vererbung auskommt natürlich.

Wenn du jetzt in einem Interface aber nennenswert Code hast und
in mehreren getrennten Basisklassen nutzen  willst, dann spart
die Vererbung halt Arbeit wie jede Vererbung.
Ich sehe keinen Grund, wieso man von einer zweiten
Basisklasse/alias Interface nicht ebenso erben kann wie
von der ersten.

Das Beispiel mit dem LKW und dem Kram ist ja noch recht schlicht,
um den Mechanismus überhaupt zu erklären und damit auch leicht
angreifbar.

Tatsächlich kann es auch Fälle geben, wo die verschiedenen 
Klassen/Interfaces eines Objekts völlig verschiedene Aspekte
berühren.

Ein Beispiel ist die Serialisierbarkeit von Java.
In einer Basisklasse stecken vielleicht die eigentlichen
funktionalen Daten (Fahrzeug etc.), ein ganz anderes Thema
deckt die Serialisierbarkeit ab.
Wieder ein anderes Thema könnte von einem anderen Interface
abgedeckt werden (z.B. Informationen zum Debuggen/Profiling,
Testen,  Protokollieren).
Dadurch kann ein Objekt  je nach Blickwinkel ein Fahrzeug sein,
ein serialisierbares Objekt oder was ganz anderes; dabei
ist beim Betrachten als serialisierbares Objekt das Fahrzeug
unerheblich und kollidiert nicht.

OK, man kann sich drum rum mogeln - aber mit Mehrfachvererbung
geht es sehr elegant, ohne eben nicht.

Bei einem Interface ala Java kann ich mit dem Interface gar
nichts übernehmen, bei Mehrfachvererbung kann halt die
ganze Grundfunktionalität für alle (Fahrzeug ebenso wie
Hebemaschine im Beispiel und alle anderen Klassen) schon
vorgekaut werden.
Will man das nicht, lässt man die Klasse halt leer und ist
beim reinen Interface.
Insofern ist Mehrfachvererbung einfach ein Interface
mit mehr (optionalen) Möglichkeiten, die man nutzen kann.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:

> Wenn du jetzt in einem Interface aber nennenswert Code hast und
> in mehreren getrennten Basisklassen nutzen  willst, dann spart
> die Vererbung halt Arbeit wie jede Vererbung.

Ooops. Hab ich das noch nicht gesagt:
Ich hab prinzipiell kein Problem mit Code in den Interfaces. Meine 
Problemkinder bei der Mehrfachvererbung waren dann zugange, wenn die 
Klassen Datenmember enthielten. Um die mach ich mittlerweile einen 
Bogen, wie der Teufel ums Weihwasser.

> Ich sehe keinen Grund, wieso man von einer zweiten
> Basisklasse/alias Interface nicht ebenso erben kann wie
> von der ersten.


Ich versuch mal ein Beispiel zu konstruieren, bei dem man in Probleme 
läuft. Ich hoffe ich kriegs noch hin :-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Mühe musst du dir nicht machen, schade um die Zeit!
Ich glaube dir sehr wohl, daß man in Probleme kommen kann.
Aber das kannst du auch mit Zeigern, Feldern, Funktionen,
Referenzen und Frauen.

Trotzdem sind sie halt manchmal nützlich.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus Wachtler schrieb:
> Frauen.
>
> Trotzdem sind sie halt manchmal nützlich.

Ich hoffe, Deine Freundin/Frau liest hier nicht mit. ;-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
war doch ein Lob?

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Man kann mit Frauen in Probleme kommen, aber manchmal sind sie ganz 
nützlich?"

Zeig mir bitte die Frau, die auf ein solches Kompliment hin mit Dir 
ausgeht :-)

Autor: D. I. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark Brandis schrieb:
> "Man kann mit Frauen in Probleme kommen, aber manchmal sind sie ganz
> nützlich?"
>
> Zeig mir bitte die Frau, die auf ein solches Kompliment hin mit Dir
> ausgeht :-)

Alles eine Frage der Konditionierung

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf Magnus schrieb:
>>Man kann bei Java auch einen "Destruktor" für bestimmte Klassen
>> bauen.
>> Man muss diesen "Destruktor" bei Bedarf aufrufen.
>
> Da sehe ich den größten Nachteil von GC-Sprachen. Das gilt ja nicht nur
> für Speicher, sondern generell für alle Ressourcen. In C++ kann ich eine
> Ressource schön in einer Klasse kapseln. Wenn ich z.B. ein File-Objekt
> zerstöre, wird die Datei automatisch vom Destruktor geschlossen. Bei
> Java nicht so. Da muß ich das immer explizit machen.

Naja, anders ausgedrückt: in C++ musst du jedes Objekt explizit 
freigeben, mit GC nur IO-Handles.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na jedes nicht, nur die händisch allokierten.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Naja, anders ausgedrückt: in C++ musst du jedes Objekt explizit
> freigeben, mit GC nur IO-Handles.

Nein. Nur dynamisch erzeugte Objekte müssen explizit freigegeben werden, 
wobei man das auch mit Smartpointern und anderen Techniken weitgehend 
automatisieren kann. Und bei Java sind es nicht nur Dateien, um die man 
sich explizit kümmern muß, sondern generell alle Ressourcen, die kein 
Speicher sind, egal ob jetzt Window-Handles, Datenbank-Verbindungen oder 
was auch immer. In C++ muß ich mich nur um "Objekte" kümmern, unabhängig 
davon, was da drin steckt. Wenn ich ein Objekt zerstöre, werden alle 
Ressourcen freigegeben, die zum Objekt gehören. Das passt für mich 
besser in die Idee objektorientierter Programmierung und vor allem auch 
Kapselung rein, als wenn ich Speicher und andere Ressourcen immer 
getrennt betrachten muß, weil zwar der Speicher irgendwann mal 
automatisch freigegeben wird, aber andere Ressourcen, die eigentlich ein 
für mich unwichtiges Implementierungsdetail sein sollten, leider für 
immer offen bleiben.

Zu Exceptions und automatischer Freigabe mal ein kleines triviales 
Beispiel:

void lesen(const std::string& filename)
{
    std::ifstream file(filename.c_str());
    parse_header(file);
    parse_content(file);
}

In C++ wird das file-Objekt am Ende automatisch zerstört, und dabei wird 
auch automatisch die Datei geschlossen. Ich muß nichts weiter tun. Und 
das gilt auch dann, wenn eine der Funktionen eine Exception wirft. In 
Java müßte ich das Dateihandle dagegen explizit schließen, und ich muß 
auch noch explizit dafür sorgen, daß das auch beim Auftreten einer 
Exception passiert.

Autor: Ingo Elsen (ogni42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In java kann man jeder Klasse eine finalize() Methode mitgeben. Die 
entspricht einem Destruktur dahin gehend, dass sie beim Löschen des 
Objektes aufgerufen wird. Aber: Das macht der GC und der alleine 
entscheidet, wann das passiert - was theoretisch niemals sein kann.

In modernen Systmen mit vieeeel Speicher und nach wie vor nur 64k 
TCP-Ports sind dann schnell mal die Ports zu Ende obwohl der GC noch 
nicht einmal gelaufen ist.

Ergo: Als Destruktor-Ersatz ist finalize nicht zu gebrauchen. Java hat 
nichts wirklich entsprechendes.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unterm Strich muss ich als Entwickler einer grossen Applikation meine 
Resourcen im Griff haben. Da kommt es nicht mehr darauf an, ob meine 
Objekte nun auch dazu zaehlen, oder nicht. Wer Resourcen verliert, hat 
seine Applikation falsch strukturiert. Und das ist oft ein viel 
groeberer Fehler als nur die verlorene Resource. Insofern betrachte ich 
Speicherlecks sogar als willkommenen Indikator fuer logische Fehler und 
tracke sie dementsprechend regelmaessig und gruendlich. Meine 
Applikationen muessen 100% sauber runterfahren koennen, auch aus vollem 
Lauf. Wenn das geht, ist die Wahrscheinlichkeit hoch, dass ich alles im 
Griff habe. Leider sind viele Entwickler heute der Meinung, dass fuer 
das Beenden einer Applikation ein exit()-Aufruf reicht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.