Sinn, Nutzen und Einsatzmöglichkeit von abstrakten Klassen

[MaBuSE]

Zitat:

Zitat von Luckie

Zitat:

Zitat von p80286

Ich denke man könnte die abstrakte Klasse als Prototypen bezeichnen.

Ich galube, das ist eine gute Zusammenfassung.

Du kannst eine abstrakte Funtkion aber auch als "forward"-Definition ansehen.

Du hast eine Klasse TKörper, in dieser Klasse kannst Du das Gewicht berechnen in dem Du das Volumen mit dem spezifischem Gewicht des Körpers multipizierst. (Vorausgesetzt alle Körper bestehen nur aus einem Material). Der Körper weiß aber nicht wie sein Volumen berechnet wird. Ein TWürfel und eine TKugel unterscheiden sich in der Volumenberechnung.

Ich hoffe es wird Dir in folgendem Beispiel klar.

Ein anderes gutes Beispiel findest du auf Deiner Festplatte im Delphi Demos Ordner (ThreadDemo).

[edit]
Nachtrag:
Beim Kompilieren gibt es "nur" eine Warnung wenn Du abstrakte Methoden nicht implementierst.
Du kannst eine TKoerper erzeugen aber wenn Du berechneGewicht aufrufst, bekommst du beim berechneVolumen Aufruf eine EAbstractError-Exception.
[/edit]

Beispiel:

Delphi-Quellcode:

unit Unit2;

interface

type
  TKoerper = class
  private
    FspezifischesGewicht: Integer;
  public
    function berechneVolumen: Integer; virtual; abstract;
    function berechneGewicht: Integer;
    property spezifischesGewicht: Integer read FspezifischesGewicht write FspezifischesGewicht;
  end;

  TWuerfel = class(TKoerper)
  private
    FLaenge: Integer;
  public
    property Laenge: Integer read FLaenge write FLaenge;
    function berechneVolumen: Integer; override;
  end;

implementation

{ TKoerper }

function TKoerper.berechneGewicht: Integer;
begin
  Result := berechneVolumen * FspezifischesGewicht;
end;


{ TWuerfel }

function TWuerfel.berechneVolumen: Integer;
begin
  Result := FLaenge * FLaenge * FLaenge;
end;

end.

[Jelly]

Zitat:

Zitat von MaBuSE

Nachtrag:
Beim Kompilieren gibt es "nur" eine Warnung wenn Du abstrakte Methoden nicht implementierst.
Du kannst eine TKoerper erzeugen aber wenn Du berechneGewicht aufrufst, bekommst du beim berechneVolumen Aufruf eine EAbstractError-Exception.

Und in .NET geht das sogar soweit dass sich das Projekt gar nicht erst kompilieren lässt (also keine Warning sondern ein Error). Das geht sogar soweit, dass sobald eine abstrakte Methode in deiner Klasse definiert ist, du gezwungen wirst die gesamte Klasse als abstract du deklarieren. Und das führt dazu, dass noch nicht mal eine Instanz der Klasse direkt erstellt werden kann.

Nachtrag2: :zwinker:
Abstrakte Methoden machen auch dann Sinn, wenn in der Basisklasse noch überhaupt nicht bekannt ist, wie die Methode implementiert werden soll. Um das Beispiel von Mabuse nochmals aufzugreifen, kann man in der abstrakten Klasse zwar erahnen, was das BerechneVolumen einer TKörper Klasse machen soll, aber weil die Geometrie in diesem Stadium noch nicht bekannt ist, kann hier nichts vorgegeben werden. Allerdings das Gewicht des Körpers ist wieder über die generelle Formel Volumen*Volumenmasse definiert, und zwar für alle Körper. Die Methode BerechneGewicht kann also direkt in der Basisklasse komplett implementiert werden. Das konkrete Volumen wird dann aus einer Methode der abgeleiteten Klasse genommen.

Du kannst dir natürlich auch vorstellen, dass in der BerechneVolumen eventuell einige generelle Aktionen getroffen werden müssen. In dem Fall deklarierst du wie gehabt die Methode als virtual und in der abgeleiteten Klasse als override.

[mkinzler]

Es ist aber eher eine Besonderheit von Delphi, dass man abstrakte Klassen überhaupt instantiieren kann.

[Luckie]

So, in meinem Skript hab eich jetzt folgendes stehen:

Zitat:

\subsection{Warum abstrakte Klassen?}
Abstrakte Klassen stellen einen Prototypen\index{Prototyp} oder eine Basiklasse\index{Basisklasse} dar, worauf die abgeleiteten Klassen dann aufbauen. Durch abstrakte Methoden\index{Methode!abstrakt} wird den abgeleiteten Klassen mitgeteilt, welche Methoden sie noch selber implementieren muss. Abstrakte Methoden sind dann sinnvoll, wenn abgeleitete Klassen identische Eigenschaften haben, die sich aber unterschiedlich verhalten. So haben geometrische Figuren die gemeinsame Eigenschaft \emph{Fläche}. Die Berechnung der Fläche hängt jedoch von der geometrischen Figur ab. In der Basisklasse wird die Methode zur Berechnung der Fläche als abstrakt deklariert, da sie nicht sinnvoll implementiert werden kann, da sich die Fläche der unterschiedlichen geometrischen Körper auch unterschiedlich errechnet.

Abstrakte Klassen kann man nicht instanzieren in Java, da sie Methoden besitzen, die nicht implementiert sind und somit ohne Funktion. Solch eine Klasse mit leeren Metrhoden zu instanzieren, wäre nicht sinnvoll. Ist eine Methode der Klasse abstrakt gekennzeichnet, so muss die ganze Klasse als abstrakt gekennzeichnet werden.

[MaBuSE]

Zitat:

Zitat von Luckie

So, in meinem Skript hab eich jetzt folgendes stehen:

Zitat:

\subsection{Warum abstrakte Klassen?}
Abstrakte Klassen stellen einen Prototypen\index{Prototyp} oder eine Basiklasse\index{Basisklasse} dar, worauf die abgeleiteten Klassen dann aufbauen. Durch abstrakte Methoden\index{Methode!abstrakt} wird den abgeleiteten Klassen mitgeteilt, welche Methoden sie noch selber implementieren muss. Abstrakte Methoden sind dann sinnvoll, wenn abgeleitete Klassen identische Eigenschaften haben, die sich aber unterschiedlich verhalten. So haben geometrische Figuren die gemeinsame Eigenschaft \emph{Fläche}. Die Berechnung der Fläche hängt jedoch von der geometrischen Figur ab. In der Basisklasse wird die Methode zur Berechnung der Fläche als abstrakt deklariert, da sie nicht sinnvoll implementiert werden kann, da sich die Fläche der unterschiedlichen geometrischen Körper auch unterschiedlich errechnet.

Ich würde noch erwähnen, das in der Basisklasse auch auf die abstrakten Funktionen zugegriffen werden kann, um Funktionalität in die Basisklasse zu packen, die für alle abgeleiteten Klassen identisch ist, aber Funktionen aufruft, in denen sich die abgeleiteten Klassen unterscheiden.

[Angel4585]

Also abstrakte Klassen kenne ich mehr aus Java und nicht aus Delphi

Wenn ich zB. eine Klasse "Spielfigur" habe hat diese eine Methode "walk".
Die Spielfiguren selbst sind jetzt jedoch keine "Spielfigur"en sondern zB "Pferd","Hund" etc
Die akstrakte Klasse dient im Gegensatz zum Interface jetzt dazu das die davon ageleitete Klasse bereits eine funktionierende Methode hat. Beim interface muss ich die erst bei jeder abgeleiteten Klasse selbst schreiben.

Abstrakt macht man das ganze damit man diese Klassen nicht direkt erzeugen kann, sondern erst ableiten muss.

[Luckie]

Zitat:

Zitat von Angel4585

Also abstrakte Klassen kenne ich mehr aus Java und nicht aus Delphi

TStrings ist eine abstrakte Klasse auf der alle Stringlisten basieren.

[Apollonius]

Streng genommen nein, denn TStrings hat zwar abstrakte Methoden, ist aber nicht selbst als abstrakt deklariert. Das geht auch erst in späteren Delphi-Versionen.

[Jelly]

Zitat:

Zitat von Angel4585

Die akstrakte Klasse dient im Gegensatz zum Interface jetzt dazu das die davon ageleitete Klasse bereits eine funktionierende Methode hat. Beim interface muss ich die erst bei jeder abgeleiteten Klasse selbst schreiben.

Das ist bei abstrakten Klassen auch nicht anders. Wenn die Basisklasse bereits eine funktionierende Methode besitzt, dann ist diese ja nicht mehr abstrakt, sondern virtuell und kann in der abgeleiteten Klasse überschrieben werden.

Interfaces haben noch teils ganz anderen Nutzen, denn man kann Instanzen von Klassen, die ein Interface implementieren, direkt über das Interface ansprechen. Wenn das Objetk zum Beispiel von einem Remoting Server kommt, dann braucht der Client noch nicht einmal zu wissen, um welche Klasse es sich handelt. Die Definition des interface reicht ihm völlig aus... Bei abstrakten Klassen ist sowas nicht zu bewerkstelligen... Aber Thema ist ja abstrakte Klassen und nicht Interfaces.

[Angel4585]

Ja aber es war ja nicht die Frage nach dem Sinn der Interfaces, sondern der abstrakten Klassen.

Luckie: Ich weis das es abstrakte Klassen in Delphi gibt, es ist nur nicht so offensichtlich wenn man nicht so oft damit arbeitet. Bei Java hab ich das öfters gemacht,deswegen war es mir dort geläufiger.