class helper

[Helmi]

Zitat von stahli:

Allister Christie hatte mal ein nettes Video dazu veröffentlicht: http://www.codegearguru.com/video/029/ClassHelpers.html

Das Video ist echt gut...

[romankassebaum]

Hallo,

um noch einmal auf meine erste Antwort zurückzukommen: Es wird eine Variable pro Instanz benötigt. Klassenvariablen können das nicht leisten. Also muss man sich etwas anderes überlegen.
Ich persönlich würde wahrscheinlich mit einem Feld arbeiten. Da Klassenhelper das nicht können, würde ich ableiten oder mir das Feld in dem Formular merken. Das kommt auf den konkreten Fall an.

--
Roman Kassebaum

[Helmi]

Zitat von romankassebaum:

...
um noch einmal auf meine erste Antwort zurückzukommen: Es wird eine Variable pro Instanz benötigt. Klassenvariablen können das nicht leisten. Also muss man sich etwas anderes überlegen.
Ich persönlich würde wahrscheinlich mit einem Feld arbeiten. Da Klassenhelper das nicht können, würde ich ableiten oder mir das Feld in dem Formular merken. Das kommt auf den konkreten Fall an.
...

Ja da hast du recht - Klassenvariablen sind fehl am Platz (hab grad rausgefunden, dass man da ganz schön perverse Sachen machen kann)
Ich nutz jetzt DeddyH´s Cracker-Klasse.

[Sir Rufo]

Ein class helper oder eine CrackerKlasse haben beide allerdings Nachteile: Die Wirkung ist nicht mehr gesteuert sondern gilt für alle betroffenen Klassen (in diesem Bereich).

Nehmen wir mal als Beispiel, dass du in einer TListBox eine Datei anzeigen möchtest und eben den Dateinamen dir merken möchtest, dann würde ich folgenden Ansatz bevorzugen:

Delphi-Quellcode:

unit TextFilePresenter;

interface

uses
  StdCtrls;

type
  TTextFilePresenter = class
  private
    FFileName : string;
    procedure SetFileName(const Value : string);
  protected
    procedure Present; virtual; abstract;
  public
    property FileName : string read FFileName write SetFileName;
  end;

  TTextFilePresenterListBox = class( TTextFilePresenter )
  private
    FListBox : TListBox;
    procedure SetListBox( const Value : TListBox );
  protected
    procedure Present; override;
  public
    property ListBox : TListBox read FListBox write SetListBox;
  end;

implementation

uses
  SysUtils;

procedure TTextFilePresenter.SetFileName( const Value : string );
begin
  FFileName := Value;
  Present;
end;

procedure TTextFilePresenterListBox.Present;
begin
  if Assigned( FListBox ) then
    if FileExists( FileName ) then
      FListBox.Items.LoadFromFile( FileName )
    else
      FListBox.Clear;
end;

procedure TTextFilePresenterListBox.SetListBox( const Value : TListBox );
begin
  FListBox := Value;
  Present;
end;

end.

Nun kann man sehr genau steuern, welche ListBox man damit ansprechen möchte.
Egal in welchem Formular und ohne Nebenwirkungen.

[JamesTKirk]

Zitat von stahli:

Die Funktion GetResult kann aber nur auf öffentliche Eigenschaften der Klasse zugreifen.

Das ist nicht ganz korrekt. Class helper können auf published , public , protected und strict protected Member der erweiterten Klasse zugreifen. Hatte ich nicht erwartet, kam aber raus, als ich Tests zur Implementierung der class helper in Free Pascal schrieb...

Dass class helper jedoch auch class var unterstützen war mir entfallen

Gruß,
Sven

[Mschmidt]

noch ein Nachtrag; class var geht, weil es keine Instanz-Variable ist. Es wäre genau so, als wenn du eine globale Variable deklarierst.
Class Var ist sogar verfügbar, wenn es keine Instanz gibt. Lediglich der Zugriff erfolgt via <Classname>.Variable statt nur Variable.
cheers Ms.

[stahli]

Zitat von Helmi:

Zitat von DeddyH:

In dem Fall muss man sich mit einer Cracker-Klasse behelfen, da geht das dann wieder.

Daran hab ich auch schon gedacht! - Dann ergibt sich für mich nicht wirklich der sinn von class helper
aber das ist eine andere Diskussion...

Mit einem Helper bleibt die Objekt-Klasse unangetastet.

Mit einer CrackerKlasse muss man das Objekt ggf. casten je nachdem von welcher Klasse das Objekt instanziiert wurde und wie es weiter verarbeitet werden soll. Streng genommen sind es nicht mehr die gleichen Klassen (auch wenn deren Namen noch gleich sind).

[Mschmidt]

Obwohl es vielleicht eher akademischer Natur ist, gefallen mir die Ansaetze hier eher nicht. Wozu gibt es die Vererbung?
Also

TmyListbox = class(tlistbox)
// erweiterungen einbauen

Ggf. Als neue Komponente installieren und verwenden.
Cheers mschmidt

[Sir Rufo]

Zitat von Mschmidt:

Obwohl es vielleicht eher akademischer Natur ist, gefallen mir die Ansaetze hier eher nicht. Wozu gibt es die Vererbung?
Also

TmyListbox = class(tlistbox)
// erweiterungen einbauen

Ggf. Als neue Komponente installieren und verwenden.
Cheers mschmidt

Das ist in diesem Zusammenhang eher kontraproduktiv.
Meine "Presenter" oder "Adapter" Klasse kann leicht auch auf andere visuelle Komponenten/Frameworks angepasst werden und über eine Factory kann ich diese verbinden. Dadurch kann ich der Factory z.B. ein TMemo, TListBox oder TComboBox (VCL sowie FMX) übergeben und bekomme eine Instanz vom Typ der Basisklasse zurück.

Bei dieser Instanz ändere ich die Eigenschaft FileName und fertig ist.

Mit deinem Ansatz müsste ich immer die konkrete Ableitung der Komponente ansprechen (ja, auch möglich per RTTI, aber schick ist das nicht).

[Mschmidt]

Es wird doch akademisch , ok. In diesem Falle gebe ich dir recht. Jedoch faellt doch das argument, wenn man mehrere funktionalitaeten erweitern moechte. Mehrfachvererbung geht bei D nicht. Imho fange ich dann an, viele adapter zu bauen. Meine persoenliche Meinung ist, strikte Kapselung, sprich; nur die Klasse (visuell oder nicht) selbst kennt seine Funktionalitaeten, fremde Zugriffe erfolgen auf Properties/fkt/proc. Die implementation ist verborgen und physisch auf eine unit beschraenkt. Wird eine neue Funktionalitaet benoetigt, wird die klasse erweitert oder eine neue abgeleitet, nichts anderes. Leider ja, das ist ein
Hoher Aufwand, der sich aber in der Wartung bezahlt macht.
Cheers Mschmidt