Warum und wann eine Klasse benutzen

[IMPEGA]

Die letzten beiden Antworten sind genau das was ich gesucht habe.
Ja @stahli genau so solltest du es verstehen.
Genau derart Antworten habe ich gesucht.
Ich benutze schon ziemlich lange eigene Klassen, habe mich aber nie wirklich damit beschäftigt.
Nun hat es angefangen mich ernsthafter zu interessieren, und siehe da, es tauchten Fragen auf.
Auch ein Dank an @Popov , sehr gut erklärt. Das sind Gründe genug um mehr über OOP zu lesen.
Es ist nämlich nicht so dass es ganz neu für mich ist, nun möchte ich es aber besser und sinnvoller machen.
Danke noch Mal.

[Popov]

Ja, manchmal muss erst der berühmte Groschen fallen. Ich hatte mal das Problem mit begin und end bei Pascal, da ich mit dem C64, bzw. TI-99/4A Basic angefangen habe und das Basic diesen "Unsinn" nicht brauchte. Ich konnte erst weiter machen, als ich verstanden habe, dass auch Basic ein begin und end hat, nur versteckt, bzw. indirekt (siehe next bei for). Im Grunde das Gleiche in grün. Manchmal muss einfach der Groschen fallen.

[Namenloser]

Ein weiterer, sehr toller Aspekt an OOP ist Polymorphie. Für mich ist das vielleicht sogar der entscheidende Punkt, da man ihn im Gegensatz zu Kapselung und Vererbung eigentlich nicht gescheit ohne Klassen simulieren kann (technisch möglich ist es natürlich, ist dann aber nicht mehr wirklich eleganter als Alternativen).

Delphi-Quellcode:

type
  TShape = class
  protected
    FLeft, FTop, FSize: integer;
  public
    procedure DrawTo(Canvas: TCanvas); virtual; abstract;
    property Left: integer read FLeft write FLeft;
    property Top: integer read FTop write FTop;
    property Size: integer read FSize write FSize;
  end;

  TCircle = class(TShape)
  public
    procedure DrawTo(Canvas: TCanvas); override;
  end;

  TSquare = class(TShape)
  public
    procedure DrawTo(Canvas: TCanvas); override;
  end;

implementation

procedure TCircle.DrawTo(Canvas: TCanvas);
begin
  Canvas.Ellipse(Left, Top, Left + Size, Top + Size);
end;

procedure TSquare.DrawTo(Canvas: TCanvas);
begin
  Canvas.Rectangle(Left, Top, Left + Size, Top + Size);
end;

Delphi-Quellcode:

type
  TMyForm = class(TForm)
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
    procedure FormPaint(Sender: TObject);
  private
    FShapes: array[0..4] of TShape;
  end;

implementation

procedure TMyForm.FormCreate(Sender: TObject);
begin
  // *Irgendwelche* Formen z.B. in einem Array/Liste speichern.
  // Konkreter Typ ist egal, solange sie nur von TShape erben.
  for i := low(Shapes) to high(Shapes) do
  begin
    if Odd(i) then
      Shapes[i] := TCircle.Create
    else
      Shapes[i] := TSquare.Create;

    Shapes[i].Size := i * 5;
    Shapes[i].Left := i * 20;
    Shapes[i].Top := 0;   
  end;
end;

procedure TMyForm.FormPaint(Sender: TObject);
begin
  // Wir können jetzt alle diese verschiedenen Objekte mit dem gleichen
  // Code verarbeiten, obwohl es sich um verschiedenartige Klassen 
  // handelt und jeweils spezialisierter Code ausgeführt wird 
  // -> man spart sich u.U. etliche Case-Strukturen, die den Code 
  // sonst unübersichtlich und fehleranfällig machen würden
  for i := low(Shapes) to high(Shapes) do
    Shapes[i].DrawTo(Canvas);
end;

procedure TMyForm.FormDestroy(Sender: TObject);
begin
  for i := low(Shapes) to high(Shapes) do
    Shapes[i].Free;
end;

Mit records geht das einfach nicht so schön... vor allem nicht, wenn man später das Programm leicht um weitere Spezialisierungen erweitern können will.

[DeddyH]

Die 3 großen Stichworte zur OOP lauten Kapselung, Vererbung und Polymorphie. Kurze vereinfachte Erläuterung zu den einzelnen Stichworten:
Kapselung:
Eine Klasse stellt die Konsistenz ihrer Daten selbständig sicher. Das erreicht sie dadurch, dass sie keinen direkten Zugriff auf diese gewährt, sondern lediglich über Schnittstellen in Form von Properties. Außerdem kann sie über Sichtbarkeitsebenen (private, protected, public) bestimmen, wer auf welche Daten und Methoden Zugriff haben soll.
Vererbung:
Wird eine Klasse von einer anderen abgeleitet, so erbt sie automatisch deren Properties und Methoden, ohne dass eine einzige zusätzliche Zeile Code nötig wäre. So lässt sich eine Klassenhierarchie aufbauen, in der die Funktionalität und/oder Spezialisierung von oben nach unten stetig zunimmt.
Polymorphie:
Vielgestaltigkeit, d.h. man kann z.B. einen Funktionsparameter vom Typ einer bestimmten Basisklasse deklarieren und sichergehen, dass auch davon abgeleitete Klassen dazu passen, ohne deren exakten Typ kennen zu müssen. Das klingt vielleicht etwas abstrakt, daher mal ein Beispiel:

Delphi-Quellcode:

type
  TTier = class
  public
    procedure GibLaut; virtual; abstract;
  end;

  THund = class(TTier)
  public
    procedure GibLaut; override;
  end;

  TKatze = class(TTier)
  public
    procedure GibLaut; override;
  end;

...

procedure THund.GibLaut;
begin
  ShowMessage('Wuff');
end;

procedure TKatze.GibLaut;
begin
  ShowMessage('Miau');
end;

procedure MachKrach(Tier: TTier);
begin
  Tier.GibLaut;
end;

In der Prozedur MachKrach ist ein Parameter vom Typ TTier deklariert. Es ist der Prozedur also vollkommen wurscht, ob es sich dabei nun um einen Hund oder eine Katze handelt, sie weiß aber, dass das Tier auf jeden Fall über eine Methode GibLaut verfügt, so dass sich diese über die TTier-Klasse aufrufen lässt.

Man kann natürlich auf den ganzen Schmu auch verzichten, macht es sich damit aber meist unnötig schwer. Das soll aber nicht heißen, dass OOP-Programmierung nun die Lösung aller Probleme wäre, man kann auch in OOP Mist schreiben, ebenso wie man auch prozedural gute Programme hinbekommen kann, der Aufwand ist aber (zumindest bei Neuentwicklungen) um Einiges größer.

P.S.: Zwischenzeitlich wurde zwar ein neuer Post geschrieben, trotzdem schicke ich das mal ab.

[p80286]

Zitat von DeddyH:

Vererbung:
Wird eine Klasse von einer anderen abgeleitet, so erbt sie automatisch deren Properties und Methoden, ohne dass eine einzige zusätzliche Zeile Code nötig wäre. So lässt sich eine Klassenhierarchie aufbauen, in der die Funktionalität und/oder Spezialisierung von oben nach unten stetig zunimmt.

Nichts für ungut, aber solche Erklärungen können einem den ganzen Spaß vertreiben.
Schön daß man so etwas machen kann, aber wofür ist es gut?
Was bringt es mir?
Wenn Olaf schreibt:

Zitat:

Im bisherigen Schema mußt du nun ALLE ROUTINEN, die sich mit Dateien befassen, ERNEUT schreiben. Also Routinen wie
- OpenMP3File
- ProcessMP3Header

Dann ist das wie ein Buhmann für kleine Kinder; ich kann mit Copy&Paste arbeiten, da schrecken die paar Zeilen Code nicht.

Wenn man mit Klassen arbeitet wird das dann noch etwas einfacher, da die "Code-Organisation" etwas übersichtlicher wird. Ebenso kann man innerhalb der Klasse arbeiten wie man will, da die Schnittstellen nach draußen definiert sind und ich keine Seiteneffekte beachten muß.

Schau ich mir VBA an, dann weiß ich wie OOP sich nicht präsentieren sollte, die gleiche Information in 5 verschiedenen Klassen und der Nutzer weiß nicht wofür es gut sein soll.

Gruß
K-H

[OlafSt]

Zitat von p80286:

Wenn Olaf schreibt:

Zitat:

Im bisherigen Schema mußt du nun ALLE ROUTINEN, die sich mit Dateien befassen, ERNEUT schreiben. Also Routinen wie
- OpenMP3File
- ProcessMP3Header

Dann ist das wie ein Buhmann für kleine Kinder; ich kann mit Copy&Paste arbeiten, da schrecken die paar Zeilen Code nicht.

Und genau das ist der Punkt, den ich versucht habe, hervorzuheben. Man kann mit Copy&Paste arbeiten. Und in solchen Kleinprogrammen funktioniert das sogar bis zu einem gewissen Grad.

Doch wenns dann größer und komplexer wird, dann geht die Nummer mit Copy&Paste schwer in die Hose. Merkt man dann allerspätestens beim Fehlersuchen. Darum auch mein abschließender Tip.

[DeddyH]

Wenn ich mit C&P arbeite, dann muss ich bei elementaren Änderungen darauf achten, dass ich auch wirklich alle betreffenden Stellen ändere. Das hat aber streng genommen noch nicht einmal direkt mit OOP zu tun.