OOP: Vererbung von Konstruktoren

[Nonsense]

Hi,

mal eine kleine Frage zu Konstruktoren.
Ich habe eine Basisklasse:

Delphi-Quellcode:

  TBase = class(TObject)
  private
    FX    : Integer;
    FY    : Integer;
    constructor Create(X, Y: Integer);
  public
    property X: Integer read FX;
    property Y: Integer read FY;
  end;

(Der Konstruktor ist private, da die Klasse nur für Ableitungen ist und keine Instanz gebildet werden soll.)

Meine Frage ist jetzt:
Wenn ich weitere Klassen von TBase ableiten will, wie muss ich deren Konstruktoren gestalten?

Delphi-Quellcode:

  TSecond = class(TBase)
  private
  public
    constructor Create(X, Y: Integer);
  end;

  constructor TSecond.Create(X, Y: Integer);
  begin
    inherited Create(X, Y: Integer):
  end;

Oder wie muss ich mir das vorstellen? Wenn ich keinen eigenen Konstruktor definiere, wird dann der von TBase genommen?

Ihr könnt mir sicher helfen (davon bin ich überzeugt...) :zwinker:

Danke im Voraus.

[Luckie]

Ja du solltest ihn auf alle Fälle aufrufen. Und auch in TBase solltest du inherited aufrufen, damit der Konstruktor von TObject aufgerufen wird.

[Nonsense]

Zitat:

Zitat von Luckie

Ja du solltest ihn auf alle Fälle aufrufen.

D.h. es gibt primär keine "bessere" Lösung, als meine aufgezeigte?

Zitat:

Und auch in TBase solltest du inherited aufrufen, damit der Konstruktor von TObject aufgerufen wird.

Ist ja logisch, hab ich jetzt nur wegrationalisiert (was für ein hässliches Wort).

Hier stand absoluter Blödsinn. Ich sollte schlafen gehen.

[Luckie]

Wie so besser? Das ist nun mal so. da gibt es kein besser oder schlechter. Wenn ich mit dem Auto fahren will, dann müssen sich die Räder auch drehen.

[Nonsense]

Zitat:

Zitat von Luckie

Wie so besser? Das ist nun mal so. da gibt es kein besser oder schlechter. Wenn ich mit dem Auto fahren will, dann müssen sich die Räder auch drehen.

Was für ein Vergleich. Aber Du hast schon recht, meine Formulierung war nur etwas unglücklich.

Edit: Danke. Frage beantwortet. :thumb:

[Robert_G]

Sollte der Constructor in TBase nicht protected sein?
Private Felder/Methoden sind doch für abgeleitete Klassen nicht sichtbar. IMHO würde das inherited deshalb nicht den Constructor aus TBase sondern von TObject nehmen.
Ich bin mir da aber nicht so sicher. (arbeite nur sporadisch mit Delphi)

[Nonsense]

Zitat:

Zitat von Robert_G

Sollte der Constructor in TBase nicht protected sein?
Private Felder/Methoden sind doch für abgeleitete Klassen nicht sichtbar. IMHO würde das inherited deshalb nicht den Constructor aus TBase sondern von TObject nehmen.
Ich bin mir da aber nicht so sicher. (arbeite nur sporadisch mit Delphi)

Hui, da muss ich mal kurz nachlesen.
Edit: Ja, Du hast recht. Danke.

[Robert_G]

Du kannst aber mit protected ins nächste offene Messer laufen...
Die (etwas schlampige) Implementierung von protected in Delphi ähnelt ein wenig dem internal aus c#.
Alle protected Felder/Methoden sind für alle Klassen innerhalb der Unit sichtbar!

[Nonsense]

Zitat:

Zitat von Robert_G

Du kannst aber mit protected ins nächste offene Messer laufen...
Die (etwas schlampige) Implementierung von protected in Delphi ähnelt ein wenig dem internal aus c#.
Alle protected Felder/Methoden sind für alle Klassen innerhalb der Unit sichtbar!

Da fällt mir doch glatt noch eine Frage ein:
Warum kann ich die Privaten Felder einer Klasse (z.B. FBitmap: TBitmap) bei der Code-Vervollständigung sehen obwohl es entsprechende property-Elemente gibt?

D.h. wenn ich auf MeineKlasse.Bitmap zugreifen will, zeigt er mir auch FBitmap an, obwohl als private deklariert.

[Luckie]

Befindest du dich in der gleichen Unit? Innerhalb der gleichen Unit sind auch private Felder einer Klasse für andere sichtbar.

[Nonsense]

Zitat:

Zitat von Luckie

Befindest du dich in der gleichen Unit? Innerhalb der gleichen Unit sind auch private Felder einer Klasse für andere sichtbar.

Hat das einen tieferen Sinn? Irgendwie etwas verwirrend, weil ich keinen Sinn erkennen kann.

[Hansa]

Mittlerweile sind die Constructors nicht mehr so wichtig. Habe soeben im eigenen Source mal gesucht. Die tauchen nur bei meinen eigenen Komponenten auf. Ist auch kein Wunder, denn das Create ist fast dasselbe.

ich modifiziere mal Dein Beispiel:

Delphi-Quellcode:

TSecond = class(TBase) 
  private 
    x,y : integer;
  public 
    constructor Create; 
  end; 

Constructor TBase.Create;
begin
  x := 1;
  y := 1;
  z := 999;
end;

constructor TSecond.Create; 
begin 
  inherited;   // x und y erben die Werte von Vorfahrklasse, die durch inherited
               // aufgerufen wird, sind also jetzt jeweils 1 z ist jetzt 999
// x und y sollen 1 bleiben, z aber 1000 :
  z := 1000;   // Entresult : x, y = 1, z = 1000 !!!!
end;

Soll nun der Wert von x und y mit 2 anfangen und z soll unberührt bleiben, so muß bereits in TBase.Create x und y auf 2 gesetzt werden. 8) So ungefähr läuft das. :zwinker:

[Robert_G]

Zitat:

Zitat von Nonsense

Zitat:

Zitat von Luckie

Befindest du dich in der gleichen Unit? Innerhalb der gleichen Unit sind auch private Felder einer Klasse für andere sichtbar.

Hat das einen tieferen Sinn? Irgendwie etwas verwirrend, weil ich keinen Sinn erkennen kann.

Ich denke mal der "Sinn" dahinter ist, dass IMHO ca. 50% der Delphi-"Programmierer" keinerlei Ahnung von OOP haben. Wenn sie dann doch etwas OOP programmieren wollen, wollen sie's wohl so simpel wie möglich -> so müssen sie sich keine Gedanken über die Sichtbarkeit innerhalb einer Unit machen.
Du kennst doch die typischen Fragen in der DP: "Gibt's 'ne Komponente hierfür?", "Gibt's 'ne Komponente dafür?", ... :roll:
Da Delphi darauf abzielt VB'ler zu bekehren ist diese Implementierung gar nicht so unverständlich. ;) VB ist halt alles andere als OOP. :P

Nachtrag:
@Hansa, das ist jetzt nicht dein Ernst, oder?

[Luckie]

Zitat:

Zitat von Robert_G

Ich denke mal der "Sinn" dahinter ist, dass IMHO ca. 50% der Delphi-"Programmierer" keinerlei Ahnung von OOP haben. [..]

Das halte ich aber für sehr unwahrscheinlich.

[Nonsense]

Zitat:

Zitat von Luckie

Das halte ich aber für sehr unwahrscheinlich.

+++
Ich denke, im Kopf eines Borland-Entwicklers geht etwas anderes vor.

[Hansa]

@RG: was soll mein ernst sein ? Die OOP-Grundlagen zu erläutern ? :shock:

Zitat:

Zitat von Luckie

Zitat:

Zitat von Robert_G

Ich denke mal der "Sinn" dahinter ist, dass IMHO ca. 50% der Delphi-"Programmierer" keinerlei Ahnung von OOP haben. [..]

Das halte ich aber für sehr unwahrscheinlich.

Die Schätzung ist realistisch. Hier im Forum gehe ich sogar eher von 80-90% aus. 8) :mrgreen:

[Nonsense]

Zitat:

Zitat von Hansa

Die Schätzung ist realistisch. Hier im Forum gehe ich sogar eher von 80-90% aus. 8) :mrgreen:

Aber was bringt es mir, dass es angezeigt wird? Darauf zugreifen kann ich doch eh nicht.

[Robert_G]

Zitat:

Zitat von Nonsense

Aber was bringt es mir, dass es angezeigt wird? Darauf zugreifen kann ich doch eh nicht.

Das ist ja der Witz: Es geht trotzdem.

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}

type
  Base = class(TObject)
  private
    fX :Integer;
    fY :Integer;
    constructor Create(X, Y :Integer);
  public
    property X :Integer read fX;
    property Y :Integer read fY;
  end;

  Descendant = class(Base)
  private
    fZ :Integer;
  public
    property Z :Integer read fZ;
    constructor Create(X, Y, Z :Integer);
  end;

{ TBase }

constructor Base.Create(X, Y :Integer);
begin
  inherited Create();
  fX := X;
  fY := Y;
end;

{ TSecond }

constructor Descendant.Create(X, Y, Z :Integer);
begin
  inherited Create(X, Y);
  fZ := Z;
  // hier hätte er meckern sollen
  inc(fX);
end;

var
  x                           :string;
begin
  with Descendant.Create(1, 2, 3) do
  try
    Writeln(X, ', ', Y, ', ', Z);
  finally
    Free();
  end;
  Writeln('Zum Beenden bitte den Any-Key suchen... :P');
  Read(x);
end.

Code:

2, 2, 3
Zum Beenden bitte den Any-Key suchen... :P

Zitat:

Zitat von Hansa

Die Schätzung ist realistisch. Hier im Forum gehe ich sogar eher von 80-90% aus. 8) :mrgreen:

Das glaube ich nicht. :shock:

[Hansa]

Zitat:

Zitat von Robert_G

constructor Descendant.Create(X, Y, Z :Integer);
begin
inherited Create(X, Y);
fZ := Z;
// hier hätte er meckern sollen
inc(fX);
end;

Warum soll wer da meckern ? :shock: Die in der Basisklasse eingeführten X und Y werden doch nur um Z erweitert. Durch das inherited sind X und Y klar. Im abgeleiteten Create kommt dann eben noch Z dazu. 8) Oder willst du behaupten, das wäre Hexerei ? :mrgreen:

[Nonsense]

Zitat:

Zitat von Hansa

Warum soll wer da meckern ?

Full Ack. Warum sollte er meckern? :coder2:

[woki]

Zitat:

Zitat von Robert_G

Du kannst aber mit protected ins nächste offene Messer laufen...
Die (etwas schlampige) Implementierung von protected in Delphi ähnelt ein wenig dem internal aus c#.
Alle protected Felder/Methoden sind für alle Klassen innerhalb der Unit sichtbar!

Das ist keine schlampige Implementierung sondern Absicht, und zwar als Ersatz für das Friend-Klassen Konzept in C++.

[Muetze1]

Beschimpfungen (per ICQ zu diesem Beitrag, bisher noch nicht hier im Forum) brauch ich nicht - dann lass ich es lieber bleiben hier mich zu äussern.

[jbg]

Zitat:

Zitat von Muetze1

Im Normalfall sollten die Contructoren auch als Virtual gekennzeichnet werden, damit ein überschreiben möglich wird.

Bist du dir da ganz sicher? Ich hoffe du weißt für was virtuelle Konstruktoren gut sind.

[Hansa]

Zitat:

Zitat von Muetze1

PS: Die angesprochene Warnung kommt bei euch nicht, da ihr bisher immer wieder neue Constructoren gebildet habt anstatt den vorhandenen der Vorklasse zu verändern...

Jetzt aber mal langsam. Willst du wirklich behaupten, bei neu eingeführten private Feldern einer Klasse dürfe man nicht den vorhandenen Constructor erweitern ? :shock: Sondern man solle den der Vorklasse verändern ? :gruebel: Dann müßte ich total umlernen und hätte bisher alles falsch gemacht. Seltsamerweise funktioniert bei mir alles und Warnungen habe ich in dem Zusammenhang auch keine. Und ich verwende fast nur OOP in nicht gerade kleinen Programmen. Sollte immer der Constructor der "Vorklasse" geändert werden müssen, egal ob man ihn jetzt Constructor nennt, oder eher ein Create meint, so müßte ich in einer Hierarchie von 20 Klassen aber ganz schön viel unnötigen Balast mitschleppen.

Und was Komponenten angeht so suche ich die nur selten. Lieber baue ich mir die selber. Da steckt auch viel OOP drin.

[woki]

Zitat:

Zitat von Robert_G

Zitat:

Zitat von Nonsense

Zitat:

Zitat von Luckie

Befindest du dich in der gleichen Unit? Innerhalb der gleichen Unit sind auch private Felder einer Klasse für andere sichtbar.

Hat das einen tieferen Sinn? Irgendwie etwas verwirrend, weil ich keinen Sinn erkennen kann.

Ich denke mal der "Sinn" dahinter ist, dass IMHO ca. 50% der Delphi-"Programmierer" keinerlei Ahnung von OOP haben. Wenn sie dann doch etwas OOP programmieren wollen, wollen sie's wohl so simpel wie möglich -> so müssen sie sich keine Gedanken über die Sichtbarkeit innerhalb einer Unit machen.
Du kennst doch die typischen Fragen in der DP: "Gibt's 'ne Komponente hierfür?", "Gibt's 'ne Komponente dafür?", ... :roll:
Da Delphi darauf abzielt VB'ler zu bekehren ist diese Implementierung gar nicht so unverständlich. ;) VB ist halt alles andere als OOP. :P

Nachtrag:
@Hansa, das ist jetzt nicht dein Ernst, oder?

@Nonsense: Das Verahlten der IDE macht Sinn, auch wenn Du es im Moment nicht verstehst. Ich kann jetzt hier kein Tutorial über den Sinn des Konzeptes von Friendklassen machen, aber es ist ein akzeptiertes Konzept in der OOP, ich persönlich habe noch nie gehört das jemand gesagt hat, das war ein Fehler. Ich denke,am sichersten kommst du zu mehr Informationen und Verständnis dafür, wenn du nach Friend - Klassen suchst, bei dem Delphi - Ersatzkonzept dafür würde mir jetzt kein Stichwort einfallen.

@Robert_G:
Wenn man auf ein Konzept stößt, das einem das Gefühl vermittelt, man habe OOP besser verstanden als Anders H., dann sollte man vieleicht in sich gehen, und darüber nachdenken,ob man sich nicht gründlich auf dem Holzweg befindet. Delphi - Language (Objekt-Pascal) basiert auf einem sehr gut durchstrukturierten und sauber umgesetzten OOP - Konzept. Und es ist kein Kompromiß für OOP-Unfähige Entwickler. Man kann in Delphi zwar genau wie in C++(Builder), Java, oder C# zwar auch eine Menge erreichen, indem man Obejktbasiert statt Objektorientiert entwickelt, das läßt aber keine Rückschlüsse auf die Qualität des Grundkonzeptes zu. Und das ist in Delphi nach wie vor sehr gut. Im Gegenteil, die Möglichkeit, Komponenten durch verschiedene Techniken an einen bestimmten Zweck anzupassen statt immer sofort neue Klassen ableiten zu müssen ist gerade eine Stärke des Konzeptes.
Es ist auch ein horrender Blödsinn, zu behaupten es gäbe hier irgendwelche Kompromisse, um VB-Entwicklern zu gefallen.

Die Frage, gibt es eine Komponente hierfür oder dafür, zeigt lediglich daß jemand das Grundkonzept moderner Softwareentwickung verstanden hat (wenn vielleicht auch unbewußt), mit dem diese versucht, erwachsen zu werden. und versucht die Quote gescheiterter Projekte unter die 80% Marke zu drücken. Der goldene Grundsatz lautet, 'Never make it, if you can buy it'. Was glaubst du. was jeder Projektleiter oder Budgetverantwortliche der seinen Job versteht, einem Anwendungsentwickler erzählt, der eine Komponente, die er in einer halben Stunde downloaden und einsetzen kann, mit einem Aufwand von einer oder mehreren Mannwochen selbst entwickelt.

Grüße
Woki

[Robert_G]

Uff :shock: , das klang doch schlimmer als es tatsächlich gemeint war.
Mein rüder Tonfall kam wohl gestern durch eine Diskussion mit einem VB'Ler, der mir vorwerfen wollte: Ich arbeite ineffizient, weil ich eine WebControl-Abgeleitung gebastelt habe anstatt mein WebForm mit Repeatern zuzumüllen. (Es kostete mich fast unmenschliche Selbstbeherrschung, ihn deshalb nicht auszulachen.)

@Topic
Nachdem ich von 2 erfahrenen Delphianern hören musste, dass das Sinn macht muss ich mich natürlich geschlagen geben. Da war ich wohl gehörig auf dem Holzweg. :oops:
Ein hübsche Implementierung ist es trotzdem nicht. Ein extra Access modifier á la internal wäre da ... "netter".

p.s.:
@Muetze, ärgere dich nicht über Hansa -> das bringt nix ;)
Und zu deinem Einwand: Der Code hatte tatsächlich nicht viel mit OOP zu tun. Es ging mir eigentlich nur um das da:

Delphi-Quellcode:

// hier hätte er meckern sollen 
inc(fX);

p.p.s.: Ich glaube trotzdem, dass Delphi versucht VB'lern zu "gefallen". :mrgreen:

[woki]

Zitat:

Zitat von Robert_G

p.p.s.: Ich glaube trotzdem, dass Delphi versucht VB'lern zu "gefallen". :mrgreen:

Aber indem man ihnen etwas bietet, was die Vorteile von VB (in der Epoche "Ante Dot NET") aufweist, ohne Ihnen diegleichen Kompromisse aufzuzwingen. Und es wendet (wandte) sich genauso an C++- Anwendungs-Enwickler, deren Projekte in Schönheit sterben, weil die zehnmal höheren Projektkosten (Schätzung eines Freundes von mir, der von Haus aus C++-Entwickler ist und seine erfolgreiche Bildverarbeitungsfirma in seiner Nische an die Weltspitze geführt hat) nicht bezahlbar sind.

Grüße
Woki

[LarsMiddendorf]

Zitat:

Ein extra Access modifier á la internal wäre da ... "netter".

Ab Delphi 8 gibt es dafür dann strict private und strict protected. Das entspricht dann dem private und protected aus C++/C#, wobei das normale private ja faktisch zumindest auf unit Ebene wie das internal ausgewertet wird.