[Beantwortet] Vererbung OHNE Design

[Mokus]

Wunder schön Guten Morgen Community;

steh vor, für euch wahrscheinlich kleines, Problem.
Wollte / sollte ein kleines Programm schreiben, dass die Oberfläche verschiedener Flächen berechnet.
Da die Formel von Oberflächen von vier ecken immer gleich ist, wollt ich den Umfang per Hauptkklasse vererben.
Probelm; ich arbeite mit meheren Formular anwendungen. Die Oberfläche des Formulares wird nun auch vererbt.
GIbt es ne möglichkeit, dies zu umgehen ?

Delphi-Quellcode:

// hauptklasse; 

unit main;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants,
  System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
  TForm3 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    r_laenge: real;
    r_breite: real;
    function getUmfang(r_laenge: real; r_breite: real): real;
  end;

var
  Form3: TForm3;

implementation

{$R *.dfm}

uses quadrat;

procedure TForm3.Button1Click(Sender: TObject);
var
  qua: TForm4;

begin
  qua := TForm4.Create(self);
  qua.Show;
end;

function TForm3.getUmfang(r_laenge: real; r_breite: real): real;
begin
  result := (2 * r_laenge + 2 * r_breite);
end;

end.

Delphi-Quellcode:

//Zweite Klasse

unit quadrat;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants,
  System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, main, Vcl.StdCtrls;

type
  TForm4 = class(TForm3)
    Edit1: TEdit;
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form4: TForm4;

implementation

{$R *.dfm}

end.

Pic 1; oberfläche von der hauptklasse;
Pic2; oberfläche von der quadraten klassen;
Pic3; wie es in der exe aussieht ...

[DeddyH]

Die Berechnung hat ja mit dem Formular nichts, aber auch gar nichts zu tun, daher gehört das in eine eigene Klasse, am Besten in einer eigenen Unit. Diese kann man dann überall einbinden, wo man sie braucht.

[Mokus]

d.H.
extra für die Berechnung der Länge eine eigende Klasse erstellen, klar das würde das problem lösen.
aber nur mal so, gibt es ne möglichketi das Design nicht mit zu vererben ?

[DeddyH]

Wenn TForm4 von TForm3 abgeleitet wird, erbt es natürlich auch dessen Eigenschaften und Methoden. Aber man muss ja nicht von TForm3 ableiten.

[Mokus]

und die Oberfläche gilt als eigenschaft ;
alles klar, dann weiß ich bescheid

dank dir. =)

[himitsu]

Aber, auch wenn ich sowas nicht unbedingt empfehlen würde...

Wenn man das INHERITED aus der DFM der neuen Klasse entfernt und durch OBJECT, dann wird die DFM der Elternklasse nicht geladen/vererbt.


Wobei der "bessere" Weg wäre diese "Berechnung" auszulagern => neue Klasse oder in eine einfache Funktion.

PS: Im Constructor/OnCreate kann man auch {Button}.Free; bzw. {Button}.Hide; ({Button}.Visible := False; ) aufrufen, um den Button wieder loszuwerden.
Oder er ist im Vorfahren unsichtbar und im Constructor wird dann Visible auf True gesetzt.

[sx2008]

Zitat von himitsu:

PS: Im Constructor/OnCreate kann man auch {Button}.Free; bzw. {Button}.Hide; ({Button}.Visible := False; ) aufrufen, um den Button wieder loszuwerden.

Aua, da schüttelt es mich aber.
Formularvererbung ist eh etwas kritisch weil der Vererbungsbaum schon so tief ist *) und dann noch solche "Tricks"...

*) Lesestoff für Fortgeschrittene:
http://openlandscape.net/2010/05/11/...t-inheritance/

[himitsu]

Zitat von sx2008:

Aua, da schüttelt es mich aber.

Ist aber besser, als gleich die komplette Vererbung zu zerschießen.

[sx2008]

Man darf nicht Dinge vererben die dann in der abgeleiteten Klasse teilweise ausgehebelt werden!
Nehmen wir mal {Button}.Free - was passiert wohl wenn im übergeordneten Formular auf eben diesen Button zugegriffen wird?
Ok, dann eben nur {Button}.Hide bzw {Button}.Visible := False .
Aber auch hier - wenn im übergeordneten Formular das Property Visible verändert wird dann erscheint je nach äusseren Umständen ein Button wo er nicht hingehört.
Und nach Murphy tritt dieser Fall erst beim Endbenutzer auf und wird bei Tests nicht entdeckt.
Der Button könnte z.B. auch dynamisch über RTTI angesprochen werden ohne dass dies bei Anwendung dieses Tricks bekannt wäre.

Oder man stelle sich vor das Projekt von einem anderen Mitarbeiter übernommen.
Ich kann mir schon vorstellen welche Flüche er von sich gibt wenn er auf diesen unerwarteten Trick stösst.

[OlafSt]

Ich habe so einen Fall in einem Projekt mit gefühlt 40k Formularen. Sie alle stammen von einem Basisformular ab, das leer ist - bis auf zwei Buttons (OK und CLOSE). An sich nicht schlecht gedacht, aber im Nachhinein dann schlecht gemacht: In 99% der Formulare werden im OnCreate eben diese Buttons unsichtbar gemacht, weil sie nicht benötigt werden (oder der Programmierer, der offensichtlich wenig Ahnung von OOP hatte, wußte es nicht besser).

Der nächste Nachteil zeigte sich dann, als ein Spinoff von diesem Monster gemacht werden sollte und ich zwei Formulare übernehmen wollte... In letzter Konsequenz habe ich dann das Basisformular entfernt, das war weniger Arbeit als ~40% des Monsterprojektes wegen der im Laufe der Jahre entstandenen Abhängigkeiten mit übernehmen zu müssen.

Ich würde hier also definitiv die Vererbung neu gestalten und die Berechnungen in eine eigene Klasse samt eigener Unit verschieben.