Klassen Methoden

[Chewie]

Zitat von sakura:

Im Zweifel kann man ja die Klassenfelder innerhalb des Implementation-Teil als Variablen deklarieren

Das ist eigentlich als Work-around gar nicht so übel. Wenn man in der Klasse Felder deklariert, die auf die globalen Variablen zeigen, hat man fast Klassenfelder. Aber nur fast: In der Klassenmethode muss noch direkt auf die globalen Variablen zugegriffen werden:

Delphi-Quellcode:

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  ClassField1: Integer = 0;
  ClassField2: Boolean = false;

type
  TMyObjectWithClassFields = class(TObject)
  private
    FMyClassField1: PInteger;
    FMyClassField2: ^Boolean;
  public
    constructor Create;
    class procedure IncClassFields;
    procedure ShowValues;
  end;

var
  Form1: TForm1;
  myObject: TMyObjectWithClassFields;

implementation

{$R *.DFM}

{ TMyObjectWithClassFields }

constructor TMyObjectWithClassFields.Create;
begin
  FMyClassField1 := @ClassField1;
  FMyClassField2 := @ClassField2;
end;

class procedure TMyObjectWithClassFields.IncClassFields;
begin
  Inc(ClassField1);
  ClassField2 := not ClassField2;
end;

procedure TMyObjectWithClassFields.ShowValues;
var
  boolString: String;
begin
  if FMyClassField2^ then
    boolString := 'true'
  else
    boolString := 'false';
  ShowMessage('MyClassField1: ' + InttoStr(FMyClassField1^) + #13#10 +
              'MyClassField2: ' + boolString);
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  myObject := TMyObjectWithClassFields.Create;
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  myObject.Free;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  myObject.IncClassFields;
  myObject.ShowValues;
end;

end.

[negaH]

Hi

Die hier gegebene Erklärungen und Antworten sind meiner Meinung nach nicht ganz richtig.

1.) Klassemethoden arbeiten auf Klassen, statt wie bei Object methoden auf Instancen einer Klasse. Somit wird ihre Aufgabe klar unterschieden. Während Object Methoden auf lokale, Object-individuelle Daten zugreifen und diese dementsprechen OOP mäßig verwalten, verwalten Klassen Methoden die Eigenschaften ALLER Objecte mit gleichem Klassentyp im globalen Sinne.
2.) Sie sind NICHT überholt, ohne Klassenmethoden würde die RTTI, die TypInfos zu Objecten, somit die Grundlage zur OOP fehlen
3.) Borland hat hier mit dem Verzicht von Klassen Variablen Konsequenz gezeigt, und sch klar zu N.Wirth's Ideen bekannt. Ganz im Gegensatz zu C usw. Denn wenn eine Klasse eine fixierte und konzeptionelle Definition der OOP ist dann darf sie auch keine zur Laufzeit variablen Elemente enthalten. Im Falle des Beispieles mit der Anzahl der produzierten Autos wäre es OOP richtiger, dazu ein neues Object zu definieren das die Fabrik also solches beschreibt. Dieses verwaltet dann den Produktionszähler. Nun wird auch im OOP Sinne sichtbar warum man dies so machen sollte. Auf Klassenebene kann es nur EINE TFabrik geben, auf Object-Instance Ebene aber ganz viele solcher TFarbik'en.
Somit sind Klassen und Klassen Methoden die Demarkationslinie zwischen der Laufzeit und der Designzeit in der OOP. Ohne Klassenmethoden würden also alle Features der IDE, der Designzeit und der partiellen Nutzbarkeit der Typinfos zur Laufzeit (zb. Typsicherheit), in der OOP garnicht möglich sein. Damit stellen Klassenmethoden ein OOP-Interface zur Laufzeit eines Programmes dar, das es dem Programmierer ermöglicht auf die zur Designzeit gemachten konzeptionellen Vorgaben zuzugreifen.
4.) statische Klassen-Konstanten sind nichts anderes als Klassen-Methoden mit Rückgabewerten, zB. .ClassName ist eine solche statische Klassen-Konstante. D.h. per OOP Definition kann ganz leicht über Klassen-Methoden eine Klassenkonstante definiert werden. Deren Rückgabewert untescheidet sich dann von Klassentyp zu Klassentyp, deren Scope ist aber meistens für alle Klassen gleich. D.h. .ClassName ist zb. eine virtuelle Klassen Methode, die in jeder Klasse als gemeinsamme Schnittstelle uniform vorhanden ist. Deren Rückgabewert ist aber eindeutig zum jeweiligen Klassentyp. Somit stellen Klassen-Konstanten keine Verletzung des OOP Konzeptes dar, und Klassen-Methoden sind das korrekte und notwendige OOP Mittel.
5.) variable Klassen-Variablen kann man so umsetzen:

Delphi-Quellcode:

type
  TMyClass = class
  private
    class function GetCounter: Integer;
    class procedure SetCounter(Value: Integer);
  public
    property Counter: Integer read GetCounter write SetCounter;
  end;

implementation

var
  FCounter: Integer = 0;

class function TMyClass.GetCounter: Integer;
begin
  Result := FCounter;
end;

class procedure TMyClass.SetCounter(Value: Integer);
begin
  FCounter := Value;
end;

Betrachtet man die "Unit" selber als "Klasse", mit den Zugriffsbezeichnern "interface" und "implementation" so wäre die lokale Variable FCounter absolut im Sinne von guter OOP ! Nicht anders funktioniert auch .NET, es MUSS irgendwo IMMER lokale und globale Variablen in einer Anwendung geben. Sie sind also NICHT schlechter Programmierstil an sich.

Gruß Hagen

[negaH]

ps: es gibt in fakt nur EINE einzigste wirklich sinnvolle Anwendung für Klassen-Variablen die ich kenne. Nämlich die Verwaltung der aktuelle allozierten Object-Instance zu dem jeweiligen Klassentyp.

In C hat man Klassenvariablen eingeführt damit laufzeit-dynamische Klassen konstruiert werden können. D.h. man kann über Klasenvariablen zur Entwurfzeit bestimmen das man zur Laufzeit zb. die Klassenhierarchie ändern kann. Allerdings WIDER-spricht das dem strikten Konzept von N.Wirth, der davan ausgeht das ein OOP Konzept und deren Objecthierarchien eine zur Laufzeit fixierte Rahmenbedingung darstellen MUSS, eine Schnittselle eben für andere Programmierer. Denn, was soll dabei herauskommen, wenn man eine Schnittstelle definiert die jederzeit zur Laufzeit polymorph ansich ist. Dies widerspricht der OOP. In C++ werden in diesem Zusammenhang oft die Klassen-Templates benutzt, nun wir wissen ja was wir von Templates zu halten haben

Ok, im Falle von JAVA sind solche Konzepte schon wieder sinnvoller, wobei aber nicht unbedingt erstrebenswert. JAVA ist immer eine interpretierende Sprache, somit kann über Klassenvariablen strukturiert auf den Interpretations-Prozess des Interpreters zur Laufzeit Einfluß genommen werden.

Gruß Hagen

[Luckie]

Hm. Eventuell lasse ich das Kapitel erstmal raus, verstehe ich ja selber noch nicht so. Und man muss sich ja Optionen für ein Update offen alten.

[Bernd Ua]

da möchte doch auch nochmal meinen Senf beisteuern

ein netter Weg um Daten auf Klassenebene zu halten und auf Variablen auf Unitebene zu verzichten
sind typisierte Konstanten auf Ebene einer Klassenmethode. So implementiert ModelMaker zB den Singleton Pattern.

@luckie: Klassenmethode weglassen, wäre schade drum, dann hört dein OOP Tutorial da auf wo es interessant wird.
Klassenmethoden sind IMHO ein schönes Mittel für die Kapselung und natürlich für die RTTI.
Probier doch mal das aus auf einem Formular mit Button und Listbox aus:

Delphi-Quellcode:

// alle Vorfahren ausgaben
procedure TForm1.Button1Click(Sender: TObject);
var
  aClass : TClass;
begin
  aClass := Sender.ClassType;
  while Assigned(aClass) do
    begin
      Listbox1.Items.Add(aClass.Classname);
      aClass := aClass.ClassParent;
    end;
end;

Bernd

[Luckie]

Zitat von Bernd Ua:

@luckie: Klassenmethode weglassen, wäre schade drum, dann hört dein OOP Tutorial da auf wo es interessant wird.
Klassenmethoden sind IMHO ein schönes Mittel für die Kapselung und natürlich für die RTTI.
Probier doch mal das aus auf einem Formular mit Button und Listbox aus:

Delphi-Quellcode:

// alle Vorfahren ausgaben
procedure TForm1.Button1Click(Sender: TObject);
var
  aClass : TClass;
begin
  aClass := Sender.ClassType;
  while Assigned(aClass) do
    begin
      Listbox1.Items.Add(aClass.Classname);
      aClass := aClass.ClassParent;
    end;
end;

LOL. Das ist das Beispie aus der Delphi-Hilfe oder?

Ja, würde ich ja auch gerne mit reinnehmen, nur fehlt mir irgendwie noch immer das Grundlegende und das tiefere Verständnis über Klassenmethoden. Daran hängt es eben noch im Moment.

[edit]Mich würde es auch nicht stören, wenn jemand anders das Kapitel beisteuern würde.[/edit]

[Bernd Ua]

Zitat:

LOL. Das ist das Beispie aus der Delphi-Hilfe oder?

weiss nich - kann sein, glaube aber nicht. Ich nehms gerne in meinen Trainings
um die Unterschiede von Klassenmethoden und normalen Methdoen deutlich zu machen

Zitat:

Ja, würde ich ja auch gerne mit reinnehmen, nur fehlt mir irgendwie noch immer das Grundlegende und das tiefere Verständnis über Klassenmethoden.

Neben tollen Sachen, die man mit dem Typ TClass bzw eigenen Klassenreferenztypen machen kann
dienen Klassenmethoden vor allem zur Strukturierung und Kapselung.
( Kombiniert mit virtuellen Konstruktoren bildet der Klassenreferenztyp das Rückrat des
ganzen Streamimg Systems der Delphi-Formulare. )

Nimm beispielsweise einen Dateneingabedialog, den Du programmieren willst.
Wenn du prozedural rangehst, baust du dafür vielleicht (bzw hoffentlich)
in der Unit eine Funktion wie folgt :

Delphi-Quellcode:

type
  TForm2 = class(TForm)
    Button1: TButton;
  private
  public
  end;

var
  Form2: TForm2;

function GetData (out Data : TSomeData): Boolean;

implementation

{$R *.dfm}

function GetData (out Data : TSomeData): Boolean;
begin
  with TFrmData.Create(nil) do
    try
      Result := ShowModal=mrOk;
      if Result then
        Data := ...
    finally
       Free;
    end;
end;

Genausogut kannst Du aber sagen, was soll die sch.. Funktion, die macht doch ohne den Dialog keinen Sinn
und fasst die Funktion und die Klasse mittels Klassenmethdoe zu einer logischen Einheit zusammen :

Delphi-Quellcode:

type
  TForm2 = class(TForm)
    Button1: TButton;
  private
  public
    class function TForm2.GetData (out Data : TSomeData): Boolean;
  end;

implementation

{$R *.dfm}

class function TForm2.GetData (out Data : TSomeData): Boolean;
begin
  with TFrmData.Create(nil) do
    try
      Result := ShowModal=mrOk;
      if Result then
        Data := ...
    finally
       Free;
    end;
end;

Von aussen rufts Du die Klassenmethode dann wie folgt auf

if TForm2.GetData(...) then Hättest Du stattdessen GetDat zu einer normalen Methode degradiert,
müsstest Du den Dialog auch von aussen erzeugen - was weder gut gekapselt noch besonders elegant ist.

Die freistehende Funktion ginge natürlich auch, nur in "reinen" OOP-Sprachen gibt es sowas halt nicht.
( vieles was in Delphi als Funktionssammlung in Units zusammengefasst ist, findet sich in Java als
Klasse, die ausschliesslich Klassenmethoden enthält und nie instanziiert wird )

Bernd

[Luckie]

Diskutiert das ruhig noch etwas weiter. Ich lese fleißig mit, in der Hoffnung, dass es irgendwan nmal klick macht.

Danke aber schon mal allen für ihre hilfreichen Ausführungen.

[Bernd Ua]

Eigentlich war geplant, das es bei obigen Beispiel bei Dir klick macht