Warum und wann eine Klasse benutzen

[IMPEGA]

Ich habe recht einfache doch zugleich schwere Frage.
Ich programmiere in Delphi schon eine Weile, immer ein bisschen dazu gelernt.
Nun, scheine ich an einen Punkt angelangt zu sein wo mich das Ganze etwas genauer interessiert.
Ich habe nie aus den Büchern gelernt, immer nur gelesen , probiert und mir die Sachen zu Recht gebastelt. Mit dem Verständnis kamen Fragen auf. (Leider habe ich sehr viele Grundbegriffe verschlafen, bzw. ignoriert)

Heutige Frage sind Klassen.
Wie man Sie erstellt weiß ich schon. Ich verstehe auch wie man damit umgehen kann/soll
Meine Frage ist.

Wann ist es sinnvoll die zu benutzen oder grob gesagt, wozu sollte ich Sie benutzen.
Ich schreibe keine große Projekte, bin nur ein Hobby-Programmierer.
Ich habe recht viel über Klassen schon gelesen, so eine Erklärung findet man aber schlecht.
Es wäre nett wenn mich ein Profi aufklären könnte.
Ich brauche nur den Sinn der dahinter steckt.

[Daniel]

Das ist ein reichlich großes Faß.
Es nennt sich "Objekt-Orientierte Programmierung" (OOP). Im Kern geht es darum, Grenzen zu ziehen. Zum Einen schon in der Struktur Deines Programmes, zum Anderen in einer klaren Aufgabenteilung und des Weiteren in einer klaren Aufteilung von Informationen - wer wo und wie auf etwas zugreifen darf oder eben nicht.

Hast Du Dir mal einen Artikel über OOP im Allgemeinen durchgelesen? Wenn nicht, solltest Du das jetzt tun - und sei es bei Wikipedia. Danach können wir über diverse Fragen sprechen. Aber das Grundwissen, das Für und Wider, solltest Du Dir selbst aneignen.

[stahli]

Vielleicht etwas Laien-näher (fällt mir leichter ):

Mit Records kannst Du Daten verwalten und per Programmcode auf diese zugreifen. Hast Du Personendaten mit Geburtsdatum und willst das Alter berechnen musst Du dafür irgendeine (externe) Funktion aufrufen.

Mit Klassen kannst Du Daten und dazugehörigen Code an einer Stelle definieren. Du kannst dann direkt Person.Alter verwenden oder Person.VerheiratenMit(AnderePerson) aufrufen.

Instanzen von Klassen sind Objekte. Die haben Daten und Fähigkeiten und können leicht weitergeben und verarbeitet werden.

Wenn man die gesamte Funktionalität einer Anwendung im Programmcode abbilden will und zur Datenverwaltung lediglich verschiendene Records hätte, wäre das unheimlich kompliziert.

In OOP haben die Objekte sozusagen ein Eigenleben, das man gleich benutzen kann.

So ist z.B. ein Button (auch ein Objekt) in der Lage, sich selbst zu zeichnen und auf einen Klick zu reagieren und ein Timer hat die Fähigkeit, innerhalb bestimmter Zeiten eine Ereignisbehandlung aufzurufen.

Stell Dir vor, Du müsstest bei jeder möglichen Mausaktion den Button gedrückt oder ungedrückt SELBST neu zeichnen oder willst in einer Anwendung ohne TTimer jede Sekunde die Formularfarbe ändern lassen. Das ginge zwar notdürftig, wäre aber EXTREM aufwendig.

Klassen lassen sich auch "vererben". Dadurch kann man von bestehenden Klassen andere Klassen ableiten, die über spezialisierte Eigenschaften verfügen.

[Darlo]

Als ich mit die selbe Frage gestellt habe (kommt wohl irgendwann bei jedem ) habe ich folgende Vorteile gesehen:

Wichtig: Das Thema Klassen und OOP ist mit den Vorteilen die ich hier nenne bei weitem nicht behandelt, soll Dir nur
einen Anhaltspunkt geben:

- Wiederverwendbarkeit von Code
- Bei Wiederverwendung brauchen Änderungen nur einmal gemacht werden
- Abgrenzung und Trennung von Logik und Oberfläche
- Zwingt zum saubereren Programmieren
- Zugriff und Veränderbarkeit von "Werten" können besser geregelt werden
- Ermöglicht eine bessere Strukturierung und Wartbarkeit des Programms

[BUG]

Wie Daniel schon sagte: OOP ist das Stichwort, wenn du Klassen verstehen willst.

Dahinter steckt (im Großen und Ganzen) weniger eine bestimmte Methode als eine bestimmte Sichtweise auf Programme, ein Programmierparadigma.
Man programmiert nicht nur in Objekt-orientiert, sondern man denkt Objekt-orientiert.

Ein Vorteil für Einsteiger in OOP ist, dass es sich relativ gut eignet um reale Gegenstände zu beschreiben.
Das ist allerdings nur der Anfang; reale Gegenstände reichen nicht aus, auch Konzepte und Verfahren können in Klassen gegossen werden.
Um OOP zu verinnerlichen, solltest du Gedankengänge anderer Programmierer nachvollziehst. Anfangs in Tutorials zu Klassen, dann in Bücher zu OOP* und später Pattern.
Es kann (fast) nie schaden, Code anderer Programmierer zu lesen und sich an Diskussionen zu Lösung von Entwurfs-Problemen in Foren zu beteiligen.

* Adhoc fällt mir da keines ein; vielleicht hat da jemand ein wirklich gutes im Schrank stehen.

[TiGü]

Zitat von BUG:

* Adhoc fällt mir da keines ein; vielleicht hat da jemand ein wirklich gutes im Schrank stehen.

Buch:
http://openbook.galileocomputing.de/oop/

Kurzer Artikel:
http://www.galileocomputing.de/artikel/gp/artikelID-215

[sx2008]

Zitat von BUG:

dann in Bücher zu OOP* und später Pattern.
* Adhoc fällt mir da keines ein; vielleicht hat da jemand ein wirklich gutes im Schrank stehen.

http://openbook.galileocomputing.de/oop/
Das Buch ist Top und es steht sogar im "Neuland" Internet

[IMPEGA]

Keine Ahnung ob ich meine Frage falsch formuliert habe, oder nicht Jeder es auf mein Art interpretiert hat.

Am besten kann ich mit dem Tip von Darlo umgehen.
Ein Dank eigentlich an Alle beteiligten, TiGü aber besonders, das wäre im Zusammenhang mit anderen Antworten die beste Lösung.

Nun, etwas klarer. Ich weiß was KLassen sind, ich weiß auch was OOP bedeutet.
Die Frage war , was es bringen soll. Nun, Vererbung ist gut und schön, bei kleinen Projekten aber unbedeutend.
Grob gesagt zu jetzigem Zeitpunkt würde ich behaupten. Warum sollte ich mich um den Speicher kümmern, Werte vererben wenn es auch ohne geht.
Natürlich ist mir klar dass es falsch ist. Die Frage war bezogen auf WARUM. Was bringt es in einem "Hallo World" Tool, den Wert einer Box in eine Klasse zu verlagern, verarbeiten und zurück zu geben?
Das ist zwar ein dämliche Beispiel, sollte nur wirklich als Beispiel dienen. Ab wann ist es eben sinnvoll Klassen zu benutzen.
Früher habe ich etwas mehr oder weniger VB.NET programmiert. Da habe ich fast Alles in die Klasse gelegt.
Allerdings nicht weil ich gewusst habe wann es Sinn ergibt, sondern weil es mir immer wieder gesagt wurde, also habe ich es auch getan.
Gelernt wie Klassen funktionieren, wozu die gut sind und Sie genutzt.
Ich programmiere nur Hobbymessing, meine Projekte sind auch meist klein. Trotzdem möchte ich versuchen es richtig zu machen. Viel mehr geht es eigentlich um mein Verständnis für die Sache.

Leider habe ich in den ganzen Antworten nicht die meine Antwort gefunden. Ich schaue mir die Bücher an, mal schauen was dabei raus kommt.
Dank geht an Alle beteiligten.

[stahli]

Du meinst also etwas wie: "Warum Datenverwaltung in Klassen?"

Das muss nicht unbedingt sein. Es kann Vorteile bringen, um den Quelltext übersichtlich zu strukturieren.
Man kann eben die Daten gut kapseln und über Objektzuweisungen flexibel damit arbeiten.
Die Objekte "leben" so lange bis sie wieder zerstört werden. Man kann auf sie mehrfach zugreifen oder sie z.B. in Listen leicht verschieben.

Records sind zwar ähnlich, aber i.d.R. etwas umständlicher im Handling.

Wenn Du in einem kleinen Projekt nur 20 Variablen brauchst, dann kannst Du sie natürlich ohne Weiteres auch einfach in einer Unit definieren.
Wenn das Projekt größer wird und z.B. unterschiedliche Formen der Datenspeicherung ermöglichen soll, ist man mit einer Klasse übersichtlicher dabei.

(Habe ich Dich jetzt besser verstanden?)

[Popov]

Zitat von IMPEGA:

Ich brauche nur den Sinn der dahinter steckt.

Ja, es gibt einen gute Sinn dahinter.

Ich hab irgendwann einen Artikel gelesen in dem über die Frage philosophiert wurde ob Klassen uns das Leben leichter machen, alternativ ob das Arbeiten dadurch schneller wird. An den genauen Wortlaut kann ich mich jetzt nicht mehr erinnern, aber aber die Antwort war in etwa: mit Klassen zu arbeiten sparrt keine Zeit im Vergleich zu der klassischen Prozeduren/Unit-Sammlungen. Ob das stimmt muss jeder für sich beantworten, es war aber die Antwort des Artikels. Deswegen würde ich die Frage nicht in die Richtung stellen. Ich persönlich bin eher der Unit-Prozedur-Sammlungen Typ, denn eine Klasse macht immer mehr Arbeit (meine Meinung) und es muss nicht immer eine Klasse sein.

Trotzdem, eine Klasse ist eine feine Sache, denn sie bietet Möglichkeiten.

Im Grunde ist eine Klasse zum Teil auch nichts anderes als eine Prozedur-Sammlung. Die wären dann eher die Methoden. Also Prozeduren und Funktionen einer Klasse. Dann hat die Klasse aber auch Eigenschaften. Ich beschreibe das gerne als intelligente Variablen, denn wenn ich einer normalen Variable "Zitrone", die nur grün oder gelb sein kann, die Farbe blau zuweise, juckt es sich nicht. In einer Klasse kann man den Zuweisungsprozess über eine Prozedur leiten. Das geht automatisch, so dass der Programmierer sich gar nicht drum kümmern muss. Diese Arbeit hat sich der Programmierer der Klasse gemacht. Der eigentliche Programmierer muss sich nicht mehr drum kümmern. Das kann man zwar auch mit einer normalen Variable und Prozedur oder Funktion auch machen, aber dann stellt sich die Frage: warum in dem Fall nicht gleich eine Klasse schreiben? Sie ist ja dazu gemacht solche Aufgaben zu übernehmen.

Delphi-Quellcode:

type
  TZitrone = class
  private
    FZitronenfarbe: String;
    procedure ZFarbe(a: String);
  public
    constructor Create;
    property Zitronenfarbe: string read FZitronenfarbe write ZFarbe;
  end;

constructor TZitrone.Create;
begin
  FZitronenfarbe := 'gelb';
end;

procedure TZitrone.ZFarbe(a: String);
begin
  if (LowerCase(a) = 'grün') or (LowerCase(a) = 'gelb') then
    FZitronenfarbe := a
  else
    FZitronenfarbe := 'gelb';
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  Zitrone: TZitrone;
begin
  Zitrone := TZitrone.Create;
  Zitrone.Zitronenfarbe := 'blau';
  ShowMessage(Zitrone.Zitronenfarbe);
  Zitrone.Free;
end;

Das kleine Beispiel verdeutlicht vielleicht was ich meine. In der Prozedur Button1Click gebe ich als Zitronenfarbe blau an. Zitronenfarbe scheint eine Variable zu sein, ist aber eine Eigenschaft. Betrachtet man property Zitronenfarbe (unter Type) wird der Schreibzugriff auf die Eigenschaft an die Prozedur ZFarbe umgeleitet. Diese Prüft den Wert und übernimmt die Speicherung in FZitronenfarbe. Wird gelesen, wird direkt aus der Variable gelesen.

Bei der Gelegenheit wird bei Create der Zitrone die Farbe gelb zugewiesen. Muss man also auch nicht mehr selbst machen. All das kann man zwar auch selbst mit Prozeduren und Funktionen machen, den Job übernimmt aber die Klasse für einen. Aufgaben werden sozusagen im Hintergrund erledigt. Die Entwicklung ist vielleicht mit mehr Aufwand verbunden, aber später holt man das wieder raus. Bei Prozeduren-Lösung müsste man sich selbst um alles kümmern.

Das ist natürlich nur eine der Vorteile von Klassen. Eine weitere wäre zum Beispiel die Vererbung. Man kann eine bestehende Klasse nehmen und sie mit paar Klicks erweitern.

Delphi-Quellcode:

type
  TBitmap64 = class(TBitmap)
  private
  public
    constructor Create;
  end;

constructor TBitmap64.Create;
begin
  inherited;
  Self.Width := 64;
  Self.Height := 64;
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  Bmp64: TBitmap64;
begin
  Bmp64 := TBitmap64.Create;
  Canvas.Draw(0, 0, Bmp64);
  Bmp64.Free;
end;

Wenn ich zum Beispiel ständig eine Bitmap mit den Massen 64 x 64 Pixel brauche und mich das ständige Wertezuweisen stört, könnte ich mir meine eigene Bitmap Klasse schreiben die bereits die richtige Abmessungen besitzt. Vererbung bietet noch mehr Möglichkeiten, aber das wäre etwas simples als Beispiel.

Wie schon oben erwähnt, man kann auch ohne eigene Klassen programmieren, aber gelegentlich lohnt es sich Klassen zu schreiben.