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