Moin Qwert,
ich möchte mal behaupten, dass Du wenige Delphi-Programme, ohne eine Klassen finden wirst.
Wenn es nicht gerade ein Konsolenprogramm ist, sondern mindestens ein Formular enthält, hast Du eine auf jeden Fall einmal ein Application-Objekt (eine Instanz der Klasse TApplication), und ein Formular-Objekt (eine Instanz der Klasse TForm, bzw., standardmässig, TForm1).
Die ursprüngliche Idee hinter der Objekt-Orientierten-Programmierung war es, dass die reale Welt sich eigentlich auch "nur" aus Objekten zusammensetzt.
Klassen stellen hierbei, sozusagen, den Bauplan für Objekte zur Verfügung.
Sie können Felder, Methoden, und Eigenschaften haben.
Felder sind, i.d.R., klasseninterne Variablen.
Methoden sind Prozeduren und Funktionen, mit denen die Daten verarbeitet werden können.
Eigenschaften dienen dazu Daten zwischen einem Objekt und anderen Programmteilen austauschen zu können.
Klassen können auch voneinander Erben (Klassen können voneinander abgeleitet werden).
Um mal das Eingangsbeispiel zu verwenden:
Wenn man ein neues Programm erstellt, wird hierfür, standardmässig, eine Klasse TForm1 generiert, die von TForm erbt.
Solange man nichts weiter hinzufügt, sind TForm1 und TForm identisch.
Wenn man jetzt einen Button auf das Formular legt, ist TForm1 eine eine Ableitung von TForm, die um ein Feld (Button1) ergänzt wurde.
Das war jetzt zwar erst einmal ziemlich kurz, aber ich hoffe es hat ein wenig Einblick gegeben.
Verwenden kann man Klassen dann in vielfältiger Weise.
In den meisten Programmen habe ich beispielsweise ein Klasse für die Einstellungen.
Damit kann ich die Funktionalität Einstellungen zu speichern und zu laden, so auslagern, dass es für das restliche Programm völlig uninteressant ist, wie das geschieht. Ob ich die Einstellungen in einer Datei lokal auf dem Rechner speichere, oder in der Registry spielt dann keine Rolle, und kann jederzeit geändert werden, ohne das der übrige Programmablauf davon beeinflusst wird.
Eine andere Möglichkeit ist es bestehende Klassen zu ergänzen, um sie den eigenen Bedürfnissen anzupassen.
Ein Beispiel hierfür:
TImage merkt sich niemals, woher jetzt die geladene Graphik stammt.
Also leite ich mir eine Klasse von TImage ab, in der ich mir den Pfad merke:
Delphi-Quellcode:
type
TMyImage = class(TImage)
private
FsFilePath : string;
public
// Eine neue Methode
procedure LoadFromFile(const AsFilepath : string);
// Eine neue Eigenschaft
property Filepath : string read FsFilePath;
end;
procedure TMyImage.LoadFromFile(const AsFilepath: string);
begin
// die in TImage enthaltene Eigenschaft Picture nutzen, um das Image zu laden
Picture.LoadFromFile(AsFilepath);
// und gleichzeitig den verwendeten Pfad speichern
FsFilePath := AsFilepath;
end;
Alle übrigen Eigenschaften und Methoden von TImage bleiben hierbei erhalten.
Man könnte das jetzt noch variieren:
Delphi-Quellcode:
type
TMyImage = class(TImage)
private
FsFilePath : string;
// Die, sogenannte, Setter-Methode für eine Eigenschaft
// (Getter-Methoden kann man auch verwenden, ist hier allerdings nicht
// unbedingt sinnvoll)
procedure SetFilePath(const Value: string);
public
property Filepath : string read FsFilePath write SetFilePath;
end;
procedure TMyImage.SetFilePath(const Value: string);
begin
Picture.LoadFromFile(Value);
FsFilePath := Value;
end;
Das Image wird einfach durch das Zuweisen eines Pfades geladen.