Warum und wann eine Klasse benutzen

[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.

[OlafSt]

Eigentlich ist die Antwort ganz simpel - und zugleich sehr kompliziert.

Ich benutze mal das Beispiel, mit dem ich meinem Kollegen, seines Zeichens krasser Anfänger, die Augen öffnen konnte. Sein "Fachgebiet" damals waren MP3-Player jeder Art.

Nun ist es nicht allzu schwer einen MP3-Player zu stricken. BASS.DLL rein und damit ist er schon fast fertig. Aber das ist langweilig, also verzichten wir auf die BASS.DLL und machen das alles selbst. Also schreiben wir ein paar Routinen, die DirectSound initialisieren, uns einen DirectSound-Kontext holen, Daten an DS senden und so weiter. Das sind alles Basics und wir haben dann u.a. folgende Routinen:

- InitDirectSound
- GetDSContext
- SendToDS
- CloseDSContext
- FinalizeDirectSound

Anschließend greifen wir uns das simple Format "WAV". Das hat einen Header und dann rohe Sounddaten. Also basteln wir weitere Routinen:

- OpenWAVFile
- ProcessWAVHeader
- ProcessChunkofWAVData
- CloseWAVFile

Wesentliche Daten werden in Records gespeichert und in globalen Variablen gehalten *hust* - typisch Anfänger halt.

However. Wenn das alles implementiert ist, klickt man auf "PLAY" und das zuvor selektierte WAV-File wird abgespielt. Bis hierhin haben wir den Umfang eines normalen Hobbycoder-Projektes erreicht. Und bis hierher machen Klassen auch kaum einen Sinn, das ganze geht auch mit dem Programmierparadigma "strukturiert" zu bauen.

Aber nun verlassen wir diese Ebene. Wir haben plötzlich die absonderliche Idee und möchten jetzt auch MP3-Files abspielen.

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

Selbst dann, wenn der Code völlig identisch zu dem der WAV-Files ist - natürlich könnte man sagen "okay, rufe ich einfach die WAV-Routinen auf". Kann man machen, aber dann hast du den berühmten Spaghetti-Code produziert und nach 6 Monaten fragst du dich "Hä, ich fummel hier mit MP3 herum, wieso ruf ich da nu WAV-Routinen auf ?!?". Macht man also nicht.

Auch brauchst du nun alle die schönen Records ein weiteres Mal. Und die globalen Variablen.

Nun hast du 2 Sätze an Routinen gebaut und mehrfach identischen Code mitsamt fast identischer Datenstrukturen produziert. Hier kommt nun OOP ins Spiel.

Man bastelt sich eine Klasse namens "WAVFile". Wir schreiben uns die Methoden
- OpenFile
- ProcessHeader
- ProcessData
- CloseFile

Da wir mit WAV anfangen, kann unser erster Entwurf, genauso wie oben am Anfang, nur mit WAV umgehen. Natürlich integrieren wir die Records in diese Klasse und - oha - globale Variablen sind eigentlich nicht mehr nötig.

Fügen wir nun MP3 hinzu, vererben wir kurzerhand (Hier fiel vor 25 Jahren bei meinem Bruder der Groschen ). Wir leiten eine Klasse MP3File von WAVFile ab. Da OpenFile und CloseFile identisch für WAV und MP3 sind, brauchen wir das gar nicht mehr programmieren - Zeit, Code und Fehlersuch-Ärger gespart. Wir implementieren nur noch ProcessHeader und ProcessData und PAFF - können wir MP3, nachdem wir ein paar Anpassungen an den internen Strukturen gemacht haben.

Und nun kommt OGG hinzu - nach altem Schema bastelst du nun wieder 4 Routinen und einen Satz Records, von denen wieder einiges identisch ist und du hast nun etliche Male denselben Code da stehen. In OOP leitest du wieder von WAVFile ab, schreibst nur neuen Code und hast Zeit, Code und Fehlersuch-Ärger gespart.

Tja, und dann... Dann möchtest du nicht nur DirectSound unterstützen, sondern auch das brandneue Soundsystem "OpenSound". Die gleiche Leier.

Ergo: In Kleinstprogrammen, wie sie Anfänger basteln und die kaum über den Umfang von 5000 Zeilen hinauskommen, wirkt OOP völlig sinnlos und produziert sogar scheinbar mehr Aufwand. Die Stärken der OOP kommen erst in größeren Projekten voll durch - und je größer und komplexer, desto effektiver ist OOP.

Mein Tip: Auch wenn es sinnlos oder aufwändig erscheint - programmiere immer objektorientiert. Hast du dich erstmal an den inzwischen prähistorisch anmutenden strukturierten Stil gewöhnt, wird es irgendwann schwer, wieder auf OOP umzuschwenken. Viele, viele, viele Hobbyprogrammierer bleiben genau das: Hobbyprogrammierer, die auch nach der 50. Version ihres MP3-Players noch einen neuen anfangen und doch immer wieder dieselben Features basteln und nur die Oberfläche ändert sich. Etliche von diesen hören auch wieder auf mit dem Programmieren.

Ein paar allerdings infizieren sich unheilbar mit dem Coder-Virus und womöglich bist du auch einer von diesen Irren Dann sind Programme im 50k-Bereich eher das übliche Tagewerk und dann haut OOP richtig rein.

[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.

[Meflin]

Wenn man Objektorientierung wirklich grundlegend verinnerlichen will (was sehr über "es gibt Klassen, Vererbung und Instanzen" hinausgeht), hat mir persönlich am meisten gebracht, mit einer tatsächlich objektorientierten Umgebung zu arbeiten. Und das war / ist Smalltalk. Dort ist einfach alles ein Objekt. Selbst Klassen und Methoden sind Objekte. True und False sind Objekte. Keywords gibt es keine. Genausowenig Operatoren (es gibt eben nur Nachrichten). Im Vergleich dazu kann man Delphi, Java und Co wirklich bestenfalls noch als klassenorientiert bezeichnen

Die Einstiegshürde war zwar durchaus nicht gerade flach, aber es hat sich für mich richtig ausgezahlt. Es schult eben einfach die Denkweise extrem, wenn das Paradigma so extrem umgesetzt ist. Und ich denke, dass ich heute auch mit Java und Co deutlich objektorientierteren Code schreibe, als ich das getan habe, bevor ich Smalltalk konnte.

[Perlsau]

Zitat von Meflin:

Wenn man Objektorientierung wirklich grundlegend verinnerlichen will (was sehr über "es gibt Klassen, Vererbung und Instanzen" hinausgeht), hat mir persönlich am meisten gebracht, mit einer tatsächlich objektorientierten Umgebung zu arbeiten. Und das war / ist Smalltalk. Dort ist einfach alles ein Objekt. Selbst Klassen und Methoden sind Objekte. True und False sind Objekte. Keywords gibt es keine. Genausowenig Operatoren (es gibt eben nur Nachrichten). Im Vergleich dazu kann man Delphi, Java und Co wirklich bestenfalls noch als klassenorientiert bezeichnen

Die Einstiegshürde war zwar durchaus nicht gerade flach, aber es hat sich für mich richtig ausgezahlt. Es schult eben einfach die Denkweise extrem, wenn das Paradigma so extrem umgesetzt ist. Und ich denke, dass ich heute auch mit Java und Co deutlich objektorientierteren Code schreibe, als ich das getan habe, bevor ich Smalltalk konnte.

Wenn man in Delphi-OOP einsteigen will, ist es auf jeden Fall hilfreich, sich in ein oder zwei der zahlreich verfügbaren Open-Source-Quellen einzuarbeiten. So hatte ich damals über die Verwendung der ein oder anderen Unit aus dem Netz sehr schnell begriffen, wie man damit arbeitet und wie sie aufgebaut sind. Ob der Rat an den OP, erst einmal Smalltalk zu erlernen, wirklich hilfreich ist, darf bezweifelt werden.

[Meflin]

Zitat von Perlsau:

Ob der Rat an den OP, erst einmal Smalltalk zu erlernen, wirklich hilfreich ist, darf bezweifelt werden.

Und das denkst du beurteilen zu können, weil...? Ich habe geschildert, was mir persönlich am meisten gebracht hat, um OOP zu "lernen". Was der Fragesteller mit diesem Erfahrungsbericht anfängt, sollten wir ihm doch selbst überlassen

[Perlsau]

Zitat von Meflin:

Zitat von Perlsau:

Ob der Rat an den OP, erst einmal Smalltalk zu erlernen, wirklich hilfreich ist, darf bezweifelt werden.

Und das denkst du beurteilen zu können, weil...? Ich habe geschildert, was mir persönlich am meisten gebracht hat, um OOP zu "lernen". Was der Fragesteller mit diesem Erfahrungsbericht anfängt, sollten wir ihm doch selbst überlassen

Durch meinen geäußerten Zweifel daran, daß das Erlernen von Smalltalk nützlich sei für einen Delphiprogrammierer, der in OOP einsteigen will, bleibt es dem Fragesteller auch weiterhin und entgegen deiner Andeutung selbst überlassen, was er damit anfängt. Dein "Erfahrungsbericht" war doch als Ratschlag gedacht, oder etwa nicht? Mag ja sein, daß du jetzt wunderbar in Java OOP entwickelst, aber es ging doch ursprünglich um die Frage, warum und wann in Delphi eine Klasse verwendet werden sollte, und nicht darum, zum Erlernen von OOP erst einmal Smalltalk zu erlernen. Und mal im Ernst: Welcher Delphi-Entwickler, der auch weiterhin mit Delphi programmieren möchte, würde nun erst einmal Smalltalk erlernen? Außer dir natürlich ...

Ich denke nicht, "das kann ich beurteilen", sondern ich beurteile es, weil ich es beurteilen kann. Übrigens: Wenn man in öffentlichen Fachforen mitreden will, sollte man auch ein wenig Gegenwind vertragen können und nicht gleich losheulen, sobald man kritische Stimmen vernimmt.

[JasonDX]

Zitat von Perlsau:

Und mal im Ernst: Welcher Delphi-Entwickler, der auch weiterhin mit Delphi programmieren möchte, würde nun erst einmal Smalltalk erlernen? Außer dir natürlich ...

Jeder, der seinen Horizont erweitern will und keine Angst vor einem Tellerrand hat. Konzepte erlernt und versteht man erst dann richtig, wenn man gezwungen ist, sie zu benutzen.
Die Empfehlung, kurzzeitig mal mit Smalltalk zu arbeiten kann ich nur bestärken. Auch wenn man die Sprache danach nie wieder berührt, man nimmt viel mit, das sich auf Delphi gut übertragen lässt - zum Beispiel, warum und wie man Klassen verwendet.