Klassen? Warum?

[alzaimar]

Zitat von Qwert Zuiopü:

könnte man nicht genauso gut ohne klassen arbeiten?

'auch' : Ja.
'genauso gut' : Nein.

Heutzutage beauftragt man ein Logistikunternehmen, eine Produktionsstätte inklusive Knowledgetransfer, Zollformalitäten, Schulungen, Maschinen, Infrastruktur etc. nach Molwanien zu verlagern.

'Geht das nicht genausogut mit einem Fahrad inkl. Anhänger'?

'auch' : Ja.
'genauso gut' : Nein.

Edit: Komplexe Applikationen sind ohne OOP nicht mehr so einfach zu realisieren. Erst der Paradigmenwechsel zur objektorientierten Sichtweise ermöglicht es, größere Programme (etwas) fehlerfrei(er) und (ein wenig) robust(er) zu entwickeln. Es wird mit Sicherheit noch weitere Paradigmenwechsel nötig sein, um Anwendungen in status nascendi wirklich brauchbar und robust zu erzeugen.

Aber natürlich ist dein Dilemma offensichtlich: Letztendlich wird ja OOP in den guten alten Spaghetti-Code (=Assembler) übersetzt.

[Apollonius]

Die objektorientierte Programmierung führt u.A. zu besserer Wartbarkeit. In größeren Projekten sind sie daher sehr sinnvoll. Aber: Das Programmierparadigma muss dir dienlich sein, nicht umgekehrt. Ich halte nichts davon, Klassen um ihrer selbst willen zu verwenden.

[DeddyH]

Zitat von alzaimar:

Zitat von Qwert Zuiopü:

könnte man nicht genauso gut ohne klassen arbeiten?

'auch' : Ja.
'genauso gut' : Nein.

Heutzutage beauftragt man ein Logistikunternehmen, eine Produktionsstätte inklusive Knowledgetransfer, Zollformalitäten, Schulungen, Maschinen, Infrastruktur etc. nach Molwanien zu verlagern.

'Geht das nicht genausogut mit einem Fahrad inkl. Anhänger'?

'auch' : Ja.
'genauso gut' : Nein.

Schön ausgedrückt

[DeddyH]

Wobei ich Appolonius auch Recht geben muss, man muss ja nicht um jede Ausgabezeile gleich eine Klasse bauen: Hello World

[Qwert Zuiopü]

also legt man z.B. in einer klasse das bild eines männchen,seine x- und y- koordinaten fest, und sagt(schreibt) dann später in einer Prozedur:

Delphi-Quellcode:

if j=10 then
 begin
 maennchen.x:=maennchen.x+1;
 end;

[SirThornberry]

agenommen du baust einen Messanger. Für jeden Gesprächspartner hat mein ein eigenes Nachrichtenfenster. Es wäre jetzt unsinn 100 solche Fenster zu bauen um im schlimmsten Fall mit 100 Leuten zu texten. Einfacher ist es da eine Fensterklasse zu stellen und einfach 100 Instanzen zu erstellwen wenn sie benötigt werden (also 100 mal Create).
Mit Objectorientierter Programmierung sieht der Quelltext hübsch und niedlich aus.

Natürlich kann man das ganze auch ohne Objekteorientierter Programmierung machen (also ohne direkt Objecte zu nutzen) aber der entstehende Quelltext ist dann wohl letztendlich der gleiche der bei Objekten im verborgenen umgesetzt wird.

[Nikolas]

Eher nicht. Man schreibt eher eine Funktion die das übernimmt, also:

Delphi-Quellcode:

if j=10 then
begin
maennchen.move(1,0)
end;

Wie du die Position intern verarbeitest, sollte man nicht mehr sehen. Sowas nennt sich 'information hiding'. Du kannst es dir so vorstellen, dass jemand eine Klasse schreibt und jemand anders nicht den ganzen Code kennt, sondern nur die Funktionen mit Beschreibungen.
Wie die Position intern gespeichert wird (als int, string, whatever), kann demjenigen, der die Klasse benutzt egal sein.

[Christian Seehase]

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.

[mkinzler]

Zitat:

also legt man z.B. in einer klasse das bild eines männchen,seine x- und y- koordinaten fest, und sagt(schreibt) dann später in einer Prozedur:

Hierfür würde ja ein Record reichen. Die Vorteile von Klassen leigt aber woanders.

[Nikolas]

Eher nicht. Man schreibt eher eine Funktion die das übernimmt, also:

Delphi-Quellcode:

if j=10 then
begin
maennchen.move(1,0)
end;

Wie du die Position intern verarbeitest, sollte man nicht mehr sehen. Sowas nennt sich 'information hiding'. Du kannst es dir so vorstellen, dass jemand eine Klasse schreibt und jemand anders nicht den ganzen Code kennt, sondern nur die Funktionen mit Beschreibungen.
Wie die Position intern gespeichert wird (als int, string, whatever), kann demjenigen, der die Klasse benutzt egal sein.

Du hast grundsätzlich Vorteile:

a) Du kannst Code wiederbenutzen. Wie bei dem Messenger-Beispiel brauchst du nur einmal den Code schreiben und kannst ihn hundert Mal benutzen. Wenn du die Klasse in eine eigene Unit packst, kannst du die Klasse mit wenigen Zeilen in einem anderen Projekt nutzen, ohne den Code kopieren zu müssen.

b) Wenn du etwas am Code ändern willst, machst du das an einer Stelle und nicht an hundert. (Viel Spaß beim Suchen ). Wenn du einen Fehler machst, musst du ihn nur an einer Stelle korrigieren.

c) das eben erwähnte Information Hiding. Wenn die Klasse fertig ist, brauchst du nicht mehr so genau wissen, wie es intern funktioniert. Bestes Beispiel ist die GUI. Wohl niemand weiss so ganz genau, wie ein Button funktioniert, aber eine On-klick Methode kann jeder DAU schreiben.