Dies kann man, wenn nicht alles täuscht, auch als Komponente mache.
Klar, diese würde sich dann wohl "THaus" nennen.
Wobei hier schon wieder das Abstrakte für meine Geschmack vorhanden ist: Weil es ist für mich gefühlt kein wirkliches Element, sondern Zeichenbefehle. Aber ok.
Die OOP bzw. das Programmieren ist nun mal sehr Abstrakt. ein Haus kann mehr als nur aus Zeichnen bestehen...
Wenn man später bei den Häusern was ändern will (Farbe, Größe, Position), dann scheint mir dies im Falle von Komponenten (und über den Namen der Hauskomponente (Mein, Deins, Unser)) komfortabler anzusprechen zu sein, als über direkte Zeichnungen oder Funktionen.
Nehmen wir an, du möchtest ein Gehäuse bauen... Ich nutzte dazu OpenScad... Dieses Gehäuse ist Parameterisiert. Größe kann ich leicht anpassen, Dicke vom verwendenen "Holz" und soweiter.
Hier gibt es "module"... ob die mit Klassen Vergleichbar sind, weiß ich nicht, aber nehmen wir es mal an:
Es kann also eine Klasse TCube geben, für ein Würfel. in diesen Würfel schneiden wir weitere "Flächen" rein, z.b. für ein LCD, für Buttons... Das kann man prima alles mit Klassen beschreiben...
Für meine Arduino Umgebung habe ich es ganz ähnlich gemacht...
Wir reden hier von selbsterstelltem. Je mehr man selber erstellt, desto mehr muss man sich dann doch wieder mit dem Kern von Lazaraus beschäftigen.
Die Frage ist, wie Tief wir dabei gehen. Ich bleibe sehr weit Oben in der Regel. So tief muss man auch nicht immer gehen.
Schau dir Komponenten wie TSynedit an. TSynEdit macht soweit ich weiß, alles selbst... TMemo z.b. nutzt das, was es auf dem System gibt. Das kann ein Eingabe Komponente von Windows sein, oder von Linux z.b. GTK2, oder jetzt GKT3 oder QT... Spielt keine Rolle...
Es sind zwei unterschiedliche Konzepte... Aber der Benutzer selbst der Programmierer der diese Klassen verwendet bekommt von diesen "unterschieden" NICHTS mit....
nsbesondere dann, wenn es mit der Komponente nicht so recht auf Anhieb klappt. Nicht selten ging es schneller, es direkt zu machen, als erst lange eine Komponente zu schreiben.
Hier muss du zwei dinge beachten.
1. Zum testen brauchst du nicht immer gleich eine Komponente zu schreiben.
Eine Komponente/Klasse ist gut geeignet um Code sehr schnell und einfach wieder zu verwenden.
Oft weiß man ja nicht mal wirklich, was man da an Schaden aufreißt. Wie zum Beispiel der ledige Mist mit der Speicherverwaltung, was leider keiner genau erklären kann und auch nie erklären können wird.
Was ist daran mist an der Speicherverwaltung? Die ist im Prinzip ganz einfach.
Wie schon geschrieben, alles was du manuell erzeugst musst du auch wieder Freigeben, alles was die LCL für dich erzeugt, gibt die LCL auch wieder frei.
Wie denn, was jetzt? Dachte das macht das Programm selbst beim beenden? Ich fange bald wieder an zu schreien, weil jeder Erklärer seine eigene Wahrheit hat.
Das ist doch logisch. klar macht das Programm das beim beenden, aber in der Regel ist es "schöner" es selbst zu machen um nur zwischendurch mehr speicher zu belegen.
Du möchtest ja nicht mehr Speicher belegen als unbedingt notwendig oder?
Aber die eigentliche Frage ist, ab wann ist das nötig? Dazu kommt es leider keine Einstimmige Antwort. Jeder erzählt was anderes.
Der Zeitpunkt ist klar, sobald du die Variable z.b. von TStringList nicht mehr brauchst...
Kostenlos liegt im Auge des Betrachters. Wenn ich etwas ohne Beschreibung bekomme, und erst mal lange dies und das ausprobieren muss, und dann immer noch nicht ganz klar damit komme, es also Sinnvoll für mein Zielt (Programm erstellen), dann hat es mich viel Zeit gekostet.
Dann nehme einfach viel Geld in die Hand und kauf dir was Fertiges, wenn du mehr Spaß am lesen hast, als am Ausprobieren und Erfahrung Sammeln.
. Es ist traurig, dass es immer wieder Leute gibt, die einerseits was tolles schaffen, und es auch der Welt zugänglich etc. macht, aber nicht bedenken, dass wenn sie die Deutungshoheit (wie es zu Handhaben ist etc.) Anderen überlassen, aus etwas Guten totaler Mist werden kann.
Es gibt Leute, die verstehen den Code den andere geschrieben haben und schauen sich Beispiele an.
Und auch habe ich durch die 5 Bücher auch 5 Unterschiedliche Erklärungen/Wege. Aber keiner der Erklärungen verursachte bei mir ein 'Aha-Effekt'! Also ein Verständnis für das Ganze.
Dann liegt dein Problem ganz wo anders...
Bei je
dem der 5 ist etwas nicht genau erklärt, oder fehlt sogar etwas.
So was führt zu viel Zeit-Aufwand durch lesen und lernen, und führt nicht wirklich zum Ziel.
Darum kaufe ich mir auch schon keine Bücher mehr, weil in der Regel höheren die dann auf, wenn es anfängt interessant zu werden.
Und ich habe den Eindruck, dass dies auch mit ein Grund ist, wieso OOP bei vielen an Bedeutung verloren hat. Weil bei mir hat eben gerade diese Art der Erklärung(!) in meinen 5 Büchern dazu geführt, dass ich mit OOP nicht viel Anfangen kann. Wie denn auch?
Du kannst 1000 Bücher lesen, und OOP immer noch nicht verstehen.
Du musst irgendwann einfach Anfangen, einfache dinge zu Programmieren mit OOP.
Nur so kannst du es dann auch verstehen.... Aber darum geht es in diesen Thread gar nicht...
Einer der Erklärungen widerspricht sogar auch noch den anderen. Ich weiß nicht mal so recht, wie man eine Erstellt, geschweige denn, was es im Hintergrund bewirkt, also worauf man achten soll, damit man keinen Schaden verursacht.
Das ist gar nicht so schwer, ich hatte am Anfang zwar auch meine Probleme, aber dann habe damit Irgendwann angefangen und siehe da, nun läuft es....
. Der eine erklärt in seinem Buch, dass dies eh am Ende des Programms wieder freigegeben wird
Ja, aber man sollte es dann tun, wenn man den Speicher nicht mehr braucht... Das gehört zum Guten Programmierstyle dazu...
Aber keiner scheint zu erklären, ab welchen Befehl (Zeichenbefehl, Variable-Zuweisung, etc.) eine Speicherreservierung entsteht, die man löschen muss (und wann man die löschen muss oder kann?).
Am Anfang ist das auch nicht wirklich Wichtig... Sowas kommt Schritt für schritt...