Warum und wann eine Klasse benutzen

[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?)

[Perlsau]

Zitat von IMPEGA:

Was bringt es in einem "Hallo World" Tool, den Wert einer Box in eine Klasse zu verlagern, verarbeiten und zurück zu geben?

Nichts. Mit anderen Worten: Wenn du nur "Hallo World" Tools schreiben willst, brauchst du dich um Klassen nicht zu kümmern. Möchtest du allerdings eines schönen Tages eine etwas komplexere Anwendung, die gut erweiter- und wartbar sein soll, entwickeln, wäre es schon angebracht, entsprechende Klassen zu entwickeln. Ich benutze z.B. zur Verarbeiten der Daten aus einer Datenbank grundsätzlich eine Klasse in einer eigenen Unit. Damit schreibe ich meine Datenbankanwendungen weitaus schneller und übersichtlicher. Auch bei Grafik-Anwendungen empfiehlt es sich, eine Klasse zu entwickeln, die alle benötigten Methoden zur Verfügung stellt. Wenn ich z.B. eine komplexe Grafik-Ausgabe entwickle, der ich den jeweiligen Canvas als Parameter mitgebe, kann ich diese Methode ebenso für die Bildschirm- wie für die Druckerausgabe verwenden.

Ansonsten schließe ich mich der Ansicht Daniels an, wonach es auf diese doch eher allgemeine Frage keine konkretere Antwort geben kann als: Lese dich ein in OOP und Klassendesign.

[Medium]

Für mich liegt der merkbarste Effekt beim Verwenden von Klassen ganz naiv betrachtet darin, dass ich zusammengehörige Daten und Verhaltensweisen in einen gemeinsamen "Container" packen kann. Dies ist vor allem dann immer wieder schön, wenn ich mehrere Instanzen solcher Container brauche, die zwar alle gleich strukturiert sind und sich gleich verhalten, aber unterschiedliche Daten tragen müssen. Zudem kann ich gleich Verhaltensweisen in den Container integrieren, um die ich mich nachher nie wieder kümmern muss - ich muss mir nichtmals Sorgen darum machen, wie meine Datenstrukturen dazu auszusehen haben; die ist ja ebenfalls schon drin. (Im Gegensatz z.B. zu einer Prozedur, die dafür geschrieben ist X Werte aus Y Arrays zu verarbeiten. Hier müsste ich immer darauf achten, eben genau passende Arrays zu erstellen. Diese Art zu arbeiten wird mit zunehmender Parallelisierung lustigerweise aber schon wieder interessanter.)

Ich bin zwar mit QBASIC und TP5 aufgewachsen, habe mich aber schon so sehr an OOP gewöhnt, dass ich es mehr oder weniger als die "natürliche" Art zu programmieren empfinde. Den Eindruck fördert bei mir sicherlich auch, dass ich es leicht finde Echtwelt-Probleme in Form von Klassen und Objekten abzubilden. Ich finde, es ist einfach oft eine schon gute Terminologie für eine Fülle an Alltagsaufgaben und -Daten. Zumindest passt es oft für die Dinge, die ich zum Brötchenverdienen schreibe echt gut. Umfangreiche Hierarchien waren bislang bei mir aber nicht oft angesagt, oftmals nur um leicht underschiedliche Objekte in gemeinsamen Listen verarbeiten zu können. Entwickler von Komponenten-Suits sind da sicherlich weit mehr von betroffen.

Insgesamt empfinde ich den Wiederverwendungswert bei Klassen als für höher. Zumindest so lange es sich nicht nur um einzelne kleine Helferlein in Prozedurform handelt. Diese landen bei mir oftmals dann auch gesammelt lose in einer Unit. Entscheidend für die Geschäftslogik sind davon aber kaum welche, da geht es oft um nicht mehr als z.B. Strings in gewisser Weise zentral zu formatieren o.ä.


Lösbar sind bestimmt fast alle Probleme mit fast allen Programmier-Paradigmen, und je nach dem wie geübt der Programmierer darin ist auch ähnlich schnell und (für ihn) komfortabel. Ich finde es eigentlich immer nur wichtig, sich nicht auf einen Weg einzuschießen. Oft ist es nämlich die Aufweichung in andere Paradigmen, oder gar Mischung mehrerer, die einem die elegantesten Möglichkeiten eröffnen. So wie Delphi z.B. Prozedural und OOP in einer Sprache nahtlos vereint. Es ist sicherlich nicht verkehrt, sich alles mal intensiv zu beschauen, und nachher auch zu benutzen wo angebracht. Und letztlich kommt wie so oft auch eine große Protion persönlichen Geschmacks dazu. (Oder ersatzweise firmeninterne Standards )

[Sir Rufo]

Auch für eine "Hello World" Anwendung kann die Verwendung von Klassen hilfreich sein.
Genau dann, wenn das Ausgabeziel (MessageBox, Konsole, Drucker) dynamisch sein soll.

Delphi-Quellcode:

unit Outputter;

interface

type
  TOutputter = class
  protected
    procedure DoOutput( const AStr : string ); virtual; abstract;
  public
    procedure Output( const AStr : string ); overload;
    procedure Output( const AFormat : string; AArgs : array of const ); overload;
  end;

  TNullOutputter = class( TOutputter )
  protected
    procedure DoOutput( const AStr : string ); override;
  end;

  TConsoleOutputter = class( TOutputter )
  protected
    procedure DoOutput( const AStr : string ); override;
  end;

implementation

uses
  System.SysUtils, Winapi.Windows;

{ TOutputter }

procedure TOutputter.Output( const AStr : string );
begin
  DoOutput( AStr );
end;

procedure TOutputter.Output( const AFormat : string; AArgs : array of const );
begin
  Output( Format( AFormat, AArgs ) );
end;

{ TNullOutputter }

procedure TNullOutputter.DoOutput( const AStr : string );
begin
  // Nichts machen
end;

{ TConsoleOutputter }

procedure TConsoleOutputter.DoOutput( const AStr : string );
begin
  AllocConsole;
  try
    Writeln( AStr );
    Writeln;
    Write( 'Press any key to continue... ' );
    ReadLn;
  finally
    FreeConsole;
  end;
end;

end.

Delphi-Quellcode:

unit Outputter_VCL;

interface

uses
  Outputter;

type
  TMsgOutputter = class( TOutputter )
  protected
    procedure DoOutput( const AStr : string ); override;
  end;

  TPrintOutputter = class( TOutputter )
  protected
    procedure DoOutput( const AStr : string ); override;
  end;

implementation

uses
  Vcl.Dialogs, Vcl.Printers;

{ TMsgOutputter }

procedure TMsgOutputter.DoOutput( const AStr : string );
begin
  inherited;
  ShowMessage( AStr );
end;

{ TPrintOutputter }

procedure TPrintOutputter.DoOutput( const AStr : string );
begin
  inherited;
  Printer.BeginDoc;
  try
    Printer.Canvas.TextOut( 100, 100, AStr );
    Printer.EndDoc;
  except
    Printer.Abort;
  end;
end;

end.

Delphi-Quellcode:

unit Main_FormU;

interface

uses
  Outputter,

  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ExtCtrls;

type
  TMain_Form = class( TForm )
    Output_RadioGroup : TRadioGroup;
    Hello_Button : TButton;
    procedure Output_RadioGroupClick( Sender : TObject );
    procedure Hello_ButtonClick( Sender : TObject );
  private
    FOutput : TOutputter;
    procedure SetOutput( const Value : TOutputter );
  protected
    property Output : TOutputter read FOutput write SetOutput;
  public
    constructor Create( AOwner : TComponent ); override;
    destructor Destroy; override;

  end;

var
  Main_Form : TMain_Form;

implementation

{$R *.dfm}

uses
  Outputter_VCL;

{ TMain_Form }

constructor TMain_Form.Create( AOwner : TComponent );
begin
  inherited;
  Output := TNullOutputter.Create;
end;

destructor TMain_Form.Destroy;
begin
  Output := nil;
  inherited;
end;

procedure TMain_Form.Hello_ButtonClick( Sender : TObject );
begin
  // Ausgabe von "Hello World"
  Output.Output( 'Hello World' );
end;

procedure TMain_Form.Output_RadioGroupClick( Sender : TObject );
begin
  // Ausgabekanal festlegen
  case Output_RadioGroup.ItemIndex of
    0 :
      Output := TNullOutputter.Create;
    1 :
      Output := TMsgOutputter.Create;
    2 :
      Output := TConsoleOutputter.Create;
    3 :
      Output := TPrintOutputter.Create;
  end;
end;

procedure TMain_Form.SetOutput( const Value : TOutputter );
begin
  if Value = FOutput
  then
    Exit;

  FOutput.Free;
  FOutput := Value;
end;

end.

[IMPEGA]

Danke noch Mal an Alle. Vor Allem an die super Beispiele.
Ich lerne Autodidakt, damit kann ich am meisten was anfangen. Ich analysiere es so lange bis ich es verstanden habe. Meisten funktioniert es ganz gut. (leider nicht immer)

Ich bin gerade mit den Antworten etwas überlastet.
Muss das Ganze erst Mal analysieren.
Obwohl ich noch mit einigen Sache meine Schwierigkeiten habe, sehe ich langsam den Sinn dahinter.
Tatsache ist, ich habe mir nun stark vorgenommen das Buch über OOP durchzusehen.
Ich bin noch auf der Suche nach einem Buch der meiner Art zu lernen am weitesten entspricht, habe aber schon ein paar Ansätze, das hilft.
Bist dato habe ich mir immer ein passende Unit gebastelt, die ich natürlich wiederverwenden konnte.
Wenn man aber tiefer nachdenkt, bieten Klassen doch enorm mehr Möglichkeiten.
Das einzige was ich als ERSTES in die Birne rein kriegen muss.
Es sind Objekte. Den Umgang mit dem Speicher muss ich mir rein prägen.
Damit tue ich mir noch etwas schwer. (unbewusst nehme ich an).

[stahli]

Das kommt mir bekannt vor.
Ich habe damals (ich gleube bei Delphi 1) die Erklärung von OOP mehrfach gelesen und immer wieder gedacht: "Hää? Wie jetzt? Wieso? Hä? ... Ahhh! ... Nee? ... Ach so..." usw.

Benutze einfach Objekte und globale Daten und Prozeduren und dann wirst Du mit der Zeit erkennen, wann welche Form welche Vorteile bietet.

[Popov]

Zitat von IMPEGA:

Ich bin noch auf der Suche nach einem Buch der meiner Art zu lernen am weitesten entspricht, habe aber schon ein paar Ansätze, das hilft.

Das "Problem" mit Lehrbüchern ist, dass sie von Leuten geschrieben werden, die das Thema inzwischen beherrschen und vergessen haben welche Fragen sie damals selbst hatten. Die meisten schreiben dann aber eher ein Nachschlagewert als ein Lehrbuch.

Ich weiß nicht wie viel Bücher ich damals zum Thema OOP gelesen habe, aber an eines kann ich mich erinnern, so richtigen Bezug zu OOP brachte mir keiner bei. Als dann der Groschen gefallen war, stellte ich fest, dass alle Bücher sehr gut geschrieben waren. Das Problem war also weniger die Fachkompetenz der Autoren, als dass sie keine Lehrbücher schrieben konnten.

Vor Jahren wollte es mal besser machen und hab ein Lehr-Tut angefangen. Damals habe ich mir viel Gedanken darüber gemacht und da Ganze versucht für absolute Anfänger zu schreiben, also keine Fachbegriffe, jedes Fitzelchen wurde nicht nur beschrieben, sondern auch der Sinn dahinter erklärt. Und viele Beispiel. Logische Beispiele die man auch in der Praxis anwenden konnte. Nur leider habe ich nach etwa 50 Seiten irgendwie die Lust verloren, denn es ist noch lange nicht fertig. Aber ausführlich wäre es geworden

Was ich dir daraus aber als Tipp zurück geben kann ist, wie du evtl. an die Sache ran gehen kannst: lass dich nicht von Fachbegriffen abschrecken. Sie sind wichtig, verwirren am Anfang aber. Übung macht den Meister. Stürze dich auf Beispiele. Und logisch müssen sie sein. Diese Obst ist Eltern und Banane ist Kindklasse ist zwar logisch, aber praxisfern. Schreibe Klassen die dem entsprechen was du auch sonst programmierst. Wenn du Grafik programmierst, dann schreib Bitmap Klassen. Irgendwas, was du schon mal als Unit gemacht hast. Um es (frei) mit Worten von Monkeyboy Ballmer zu sagen: Bitmap Klassen, Bitmap Klassen, Bitmap Klassen. Am Anfang ableiten und erweitern (siehe Bitmap64 Beispiel), dann eine Bitmap um Funktionen und Eigenschaften erweitern die du schon immer dran vermisst hast, wie zum Beispiel Clear Funktion, oder Hintergrundfarbe setzen, Skalierung, usw. Einfach sinnvolle Erweiterungen. Denn wenn man an einem Problem arbeitet, dann sucht man auch Lösungen. Dann wälzt man auch Bücher nach Tipps in die Richtung. Wenn man stattdessen aber nur stupide Beispiele aus Büchern abtippt, erkennt man oft nicht den Sinn dahinter. Und zuletzt, nutze die vorhandenen Klassen von Delphi als Beispielpool. Einfach TStringList tippen, die Strg Taste drücken und mit der Maus drauf klicken. Und nun die Klasse studieren. Aus den vorhandenen Klassen kann man viel lernen. Die sind in der Regel gut und knapp geschrieben. Und wenn du etwas nicht verstehst, dann gezielt nach Erklärung suchen.