Ist die Klassische OOP gescheitert?

Für Dinge zum Forum, Kritik, Verbesserungsvorschläge, Umfragen und ähnliches.
Antworten
pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Ist die Klassische OOP gescheitert?

Beitrag von pluto »

Für Dich ist es Freischwebend, für mich ist es eher umgekehrt, nämlich die Komponenten Freischwebend bzw. extern. Weil der Code befindet sich nicht direkt auf dem eigentlichen Programmierformular (?) ... -seite, -fläche, oder wie auch immer. Sondern eben ... extern. Das ist etwas, was mich schon immer ein wenig an den Komponenten gestört hat.

Genau das machen doch die Komponenten aus, die sind ausgelagert sind....

Ab wann soll man Vererben bzw. neue Komponente erstellten. Ab jeden Schritt? Also erst TTimer einfügen, dann Komponente erstellen. Davon (Ver)erben und dann die Farbauswahl dazufügen. Oder umgekehrt? Oder doch beides im einem Schritt?

Hä? Du leitest im Kontext der LCL in diesen Fall von TLabel ab. Dort erstellst du ein TTimer und dort wiederum fügst du die OnTimer Methode hinzu.... Fertisch...

Und was ist, wenn man später das eine (TTimer oder Farbe) braucht, aber nicht das andere? Dann zähneknirschend von einem Elternteil weiter unten (Ver)erben und das TTimer oder Farbe noch mal reinschreiben?

Doppelt hä? Der TTimer ist immer Extern, weil es eine Komponente ist die an vielen Punkten eingesetzt werden kann.

Wenn es sich um was Größeres (also gleich mehre Funktionen ein einem Vererbungsschritt dazu kommen), dass man dann auch noch oft braucht, macht es natürlich Sinn

Es geht nicht immer um Funktionen, sondern um Felder. Aber ja, dann kommt eine "Basis Klasse" oder die eigentliche Klasse dazwischen oder an die Reihe...

Aber umgekehrt ... findet man sich dann überhaupt noch zurecht? Weiß man noch, selbst wenn man für jedes Projekt extra Komponenten-Seite/-Reiter anlegt, welche Komponente was macht? Wissen das die Komponenten selber noch, wenn eifrig hin und her vererbt wird?

Das ist einer "meiner" größten Probleme in Sache der LCL.... Die ist derartig komplex, ich glaube kaum jemand versteht sie 100%ig und kann aus dem FF sagen, wer vom erbt. Aber das muss man zum Glück auch gar nicht... Dank der IDE... und den Code-Tools...

Was spart mehr Zeit? Ständig darüber nachzudenken, wie man alles mittels Komponenten machen kann, oder doch mal 2-3 Codezeilen direkt ins Formular reinschreiben?
... Oder kostet die Findung der Balance am meisten Zeit?? Oh oh ... .

Das ist der Punkt !!!

Es kommt immer auf die Sache an, ich denke Pauschal wird man das nicht beurteilen können.
Aus gründen der Einfachheit habe ich jetzt vom TLabel abgeleitet, weil ich EIN Feld extra gebraucht habe, hätte ich vielleicht auch über die Tag Eigenschaft machen können, aber so ist es "übersichtlicher"... Man muss einfach die Möglichkeiten nutzen, die die Jeweilige Sprache zuverfügung stellt.

In meinen Fall ist es sogar so, dass ich nicht mal die neuen Komponenten auf eine eigene erstellte (Reiter-)Seite einfügen kann.

Warum nicht? Meinst du die Komponenten Leiste von Lazarus? das kann man muss man aber nicht...
MFG
Michael Springwald

Erwin
Beiträge: 286
Registriert: Mi 16. Sep 2009, 14:15
OS, Lazarus, FPC: Xubuntu 22.04 / x86_64_linux-gtk 2 / L 2.2.0 / FPC 3.2.2

Re: Ist die Klassische OOP gescheitert?

Beitrag von Erwin »

pluto hat geschrieben:
In meinen Fall ist es sogar so, dass ich nicht mal die neuen Komponenten auf eine eigene erstellte (Reiter-)Seite einfügen kann.

Warum nicht? Meinst du die Komponenten Leiste von Lazarus? das kann man muss man aber nicht...

Also wenn ich mich noch richtig erinnere, war das so, dass es scheinbar nur die Vorhandenen Komponentenleisten akzeptierte. Ich konnte zwar eine weitere, mit den Namen 'Eigene Komponenten' hinzufügen. Aber ich konnte ihm nicht klar machen, dass er meine Komponenten in diese Leiste ablegen soll. Es war so, als würde für in der selbst gemachte Reiter/Leiste nicht existieren. Und eigene Grafik klappte auch nicht.
Aber das will ich hier nicht vertiefen. Wenn ich Lust und Nerven habe, können wir dafür Extra Thread aufmachen. Sondern mir ging es darum zu erwähnen, dass bei dem Ganzen auch noch anderweitig was schief laufen kann, was nicht passiert wäre, hätte ich gar nicht versucht, eine eigene Komponente zu erstellen.
Kann mir vorstellen, dass auch andere Fehler sich einschleichen können. Und je nach dem wo, bei welcher Vererbung ... oder vielleicht eine Urkomponente, die wegen einem Fehler von der einen Version zur anderen Ausgetauscht wird, aber eigene Komponenten genau mit diesem Fehler gut gearbeitet hatten ... könnte mir vorstellen, dass man in so machen Fällen, wenn es blöd läuft, man fast ewig nach dem Fehler suchen kann.

Anderseits ... scheinen die, die es nutzen, dennoch damit klar zu kommen?
Denke mal, dass mich das Thema vor allem deshalb interessiert, weil ich da noch nicht so sehr für mich entscheiden konnte, welchen Weg der Problemlösung ich nutzen soll, bzw. noch nicht heraus gefunden habe, mit welchem Weg ich am besten klar kommen würde.
Lazarus 2.2.0 / FP 3.2.4

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Ist die Klassische OOP gescheitert?

Beitrag von pluto »

Also wenn ich mich noch richtig erinnere, war das so, dass es scheinbar nur die Vorhandenen Komponentenleisten akzeptierte. Ich konnte zwar eine weitere, mit den Namen 'Eigene Komponenten' hinzufügen. Aber ich konnte ihm nicht klar machen, dass er meine Komponenten in diese Leiste ablegen soll. Es war so, als würde für in der selbst gemachte Reiter/Leiste nicht existieren. Und eigene Grafik klappte auch nicht.

Das sollte in einem neuen Thread geklärt werden... aber als tipp: schau dir mal von den vorhandenen Komponenten die register procedure an.
Ich hatte dazu vor Jahren mal eine Wiki Seite im FPC Wiki erstellt:
http://wiki.lazarus.freepascal.org/Buil ... ents_01/de

Sondern mir ging es darum zu erwähnen, dass bei dem Ganzen auch noch anderweitig was schief laufen kann, was nicht passiert wäre, hätte ich gar nicht versucht, eine eigene Komponente zu erstellen.

da ich dein Vorhaben nicht kenne und den Code nicht kenne, kann ich nur in meine Glaskugel schauen aber zur Zeit sagt sie mir auch nicht viel....

Anderseits ... scheinen die, die es nutzen, dennoch damit klar zu kommen?

Ja. Das liegt daran das zum einen die IDE komplett OpenSoruce ist, man kann sehr gute in den vorhandenen Soruce-Code schauen, wer vom wem Ableitet und es gibt eine reihe von Code-Tools. Die dich dabei unterstützen.

Denke mal, dass mich das Thema vor allem deshalb interessiert, weil ich da noch nicht so sehr für mich entscheiden konnte, welchen Weg der Problemlösung ich nutzen soll, bzw. noch nicht heraus gefunden habe, mit welchem Weg ich am besten klar kommen würde.

Es gibt immer mehrer Wege. das bedeutet jetzt nicht, dass du die OOP komplett vermeiden musst. Wähle den Weg der am besten für deine Problem Lösung geeignet ist.
Wenn du den nicht kennst, versuch einfach einiges. Schau dir an, was andere es lösen.
MFG
Michael Springwald

compmgmt
Beiträge: 351
Registriert: Mi 25. Nov 2015, 17:06
OS, Lazarus, FPC: Win 10 Pro | Lazarus 1.8.2 | FPC 3.0.4
CPU-Target: i386 + x86_64
Wohnort: in der Nähe von Stuttgart
Kontaktdaten:

Re: Die Klassische OOP gilt als gescheitert

Beitrag von compmgmt »

pluto hat geschrieben:
Schon klar, aber das decken ja schon die alten Objekte aus Turbo-Pascal-Zeiten ab. Deswegen wundert es mich ja, warum die Records noch zusätzlich aufgebohrt wurden.
Mich wundert es, dass man in Record auch proceduren und funktionen schreiben kann...
Macht durchaus sinn. Hier ein reales Beispiel von mir:

Code: Alles auswählen

type
  TCircle = record
    CenterX: Integer;
    CenterY: Integer;
    Radius: Single;
    function IsPointInCircle(x, y: Integer): Boolean; overload;
    function IsPointInCircle(p: TPoint): Boolean; overload;
  end;

Code: Alles auswählen

InitiateSystemShutdownExA(nil, nil, 0, true, false, $0005000F);
Have fun with this snippet ;)

MacWomble
Lazarusforum e. V.
Beiträge: 999
Registriert: Do 17. Apr 2008, 01:59
OS, Lazarus, FPC: Mint 21.1 Cinnamon / FPC 3.2.2/Lazarus 2.2.4
CPU-Target: Intel i7-10750 64Bit
Wohnort: Freiburg

Re: Ist die Klassische OOP gescheitert?

Beitrag von MacWomble »

... und warum ein Record und nicht eine Klasse?
Alle sagten, dass es unmöglich sei - bis einer kam und es einfach gemacht hat.

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Ist die Klassische OOP gescheitert?

Beitrag von pluto »

... und warum ein Record und nicht eine Klasse?

Ob das mit der "Initialisierung" zusammen hängt? Eine Klasse wäre hier aufjedenfall Sinnvoller, weil beim Init, gleich die Felder richtig mit Default Werten belegt werden kann.
MFG
Michael Springwald

braunbär
Beiträge: 369
Registriert: Do 8. Jun 2017, 18:21
OS, Lazarus, FPC: Windows 10 64bit, Lazarus 2.0.10, FPC 3.2.0
CPU-Target: 64Bit
Wohnort: Wien

Re: Ist die Klassische OOP gescheitert?

Beitrag von braunbär »

Pluto hat geschrieben:
Und die Parameter kann ich dann über den OI setzen, statt das "von Hand" zu programmieren. Natürlich kann man alles immer wieder neu machen, man kann aber auch in Assembler programmieren.

Das immer gleich alles Drastisch Falsch verstanden wird und sich alle Persönlich angegriffen fühlen....verstehe ich nicht...
Es gibt mehr zwischen "Vererbung" und ASM, ob du es glaubst oder nicht....

Entschuldige. Ich bin manchmal leicht sarkastisch - da habe ich nichts als persönlichen Angriff verstanden, und auch selbst nicht so gemeint.
Das Geniale am Konzept des FPC (und auch Dephi) Entwicklungssystems ist im Bereich der Oberflächenprogrammierung das Zusammenspiel zwischen den Objektklassen und dem Object Inspector.
Statt mühsam herumzukodieren kannst du einfach ein paar properties im OI setzen - Aber damit das mit Dingen funktionert, die nicht schon vorgegeben sind, muss man sich eben seine eigenen Komponenten ableiten.

Was ich nachvollziehen kann, ist das Unbehagen über die extreme Verschachtelungstiefe der Komponentenbaums. Eine etwas flachere Hierarchie wäre da sicher möglich gewesen und in der Hinsicht ist Kritik an unkontrolliertem Vererbungswildwuchs, wohl schon berechtigt.

Erwin hat geschrieben: Sondern mir ging es darum zu erwähnen, dass bei dem Ganzen auch noch anderweitig was schief laufen kann, was nicht passiert wäre, hätte ich gar nicht versucht, eine eigene Komponente zu erstellen.

Es kommt darauf an, wo du hin willst. Je leistungsfähiger ein Programmiersystem ist, desto länger brauchst du in der Regel, um dich einzuarbeiten. Ob sich das für das, was du machen willst, auszahlt, musst du selbst entscheiden.

So ist die Lazarus/FPC Umgebung auch für mich immer wieder von Neuem eine Herausforderung, obwohl ich mit Delphi viele Jahre Erfahrung habe. Im Detail ist es dann eben doch nicht ganz das Gleiche...

MacWomble hat geschrieben:... und warum ein Record und nicht eine Klasse?

Bei Klassen brauchst du die dynamische Speicherverwaltung, create und free, das ist mehr Overhead. Wenn du Vererbung nicht brauchst, genügen records. Wobei es ja im Prinzip egal ist, du kannst eben die von den Klassen gewohnte Syntax verwenden:
OOP: if Circle.IsPointInCircle(P)
Klassisch prozedural: If IsPointInCircle(Circle,P)
Umgesetzt wird es vom Compiler genau gleich, der gibt der Klassenmethode genauso den impliziten Parameter Circle mit, wie du es in einer "klassischen "Prozedur explizit machst.

Ich bin allerdings selbst von der Verwendung dieser Records weitgehend abgekommen, weil der Overhead nicht gar so groß ist, und Klassen doch um einiges flexibler sind. Sehr oft braucht man irgend wann im Lauf der Programmentwicklung genau das, wovon man beim Projektbeginn gemeint hat: Das brauche ich ganz sicher nicht., das spare ich mir jetzt einmal :)

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Ist die Klassische OOP gescheitert?

Beitrag von pluto »

Das Geniale am Konzept des FPC (und auch Dephi) Entwicklungssystems ist im Bereich der Oberflächenprogrammierung das Zusammenspiel zwischen den Objektklassen und dem Object Inspector.
Statt mühsam herumzukodieren kannst du einfach ein paar properties im OI setzen - Aber damit das mit Dingen funktionert, die nicht schon vorgegeben sind, muss man sich eben seine eigenen Komponenten ableiten.

Ja, die IDE vereinfacht schon vieles, erzeugt aber auch recht viel Overhead, dadurch.

Was ich nachvollziehen kann, ist das Unbehagen über die extreme Verschachtelungstiefe der Komponentenbaums. Eine etwas flachere Hierarchie wäre da sicher möglich gewesen und in der Hinsicht ist Kritik an unkontrolliertem Vererbungswildwuchs, wohl schon berechtigt.

Diese "Verschachtelungstiefe" kommt wohl auch von Delphi... Zum Teil....

So ist die Lazarus/FPC Umgebung auch für mich immer wieder von Neuem eine Herausforderung, obwohl ich mit Delphi viele Jahre Erfahrung habe. Im Detail ist es dann eben doch nicht ganz das Gleiche...

Stimmt. Oberflächlich vielleicht, wenn man von "Oben" schaut, aber je mehr man möchte, desto eher kommt man dahinter, dass es doch anders ist als erwartet...

Bei Klassen brauchst du die dynamische Speicherverwaltung, c

Nicht immer, beim Alten "Klassen" Konzept gibt es eine Statische Speicherverwaltung...
also object statt class....

Sehr oft braucht man irgend wann im Lauf der Programmentwicklung genau das, wovon man beim Projektbeginn gemeint hat: Das brauche ich ganz sicher nicht., das spare ich mir jetzt einmal

Ja, ich "leite" dann von einer "Komponente" ab und füge in der Regel ein Feld hinzu. Ein Feld z.b. Data oder ähnliches....Wäre toll, wenn alle Klassen so ein Feld von Anfang an hätten...
sagt jetzt nicht wieder, dass ist schlechter Programmier style... Die TListBox, TListView haben bei ihren "Einträgen" genau so ein Feld...
MFG
Michael Springwald

Erwin
Beiträge: 286
Registriert: Mi 16. Sep 2009, 14:15
OS, Lazarus, FPC: Xubuntu 22.04 / x86_64_linux-gtk 2 / L 2.2.0 / FPC 3.2.2

Re: Ist die Klassische OOP gescheitert?

Beitrag von Erwin »

braunbär hat geschrieben:So ist die Lazarus/FPC Umgebung auch für mich immer wieder von Neuem eine Herausforderung, obwohl ich mit Delphi viele Jahre Erfahrung habe. Im Detail ist es dann eben doch nicht ganz das Gleiche...

Du meinst aber Delphi? Nicht den Nachfolger Embar... und noch irgendwie. Weil bei dem E. ... ich habe mir das mal bei einem Bekannten angeschaut, der das hat ... das hat eine Komponenten-Flut ... da wäre ich sogar bereit gewesen, notfalls durch das Fenster abzuhauen.


Der große Vorteil von Komponenten ist vermutlich auch die Namensvergabe? Also wenn man mehr Blinklabels macht, dass man jedem davon extra Namen gehen kann und einfach darüber ansprechen und Werte ändern etc. kann. Allerdings ist jetzt wieder das mit dem Create aufgetaucht? Ich habe insgesamt den Eindruck, dass man mit dem Erstellen von eigenen Komponenten paar Vorteile von FPC/Lazarus dann opfern muss. Weil wenn ich das richtig verstanden habe, muss man sich, so lange man selbst nichts an Komponenten (und betrifft das vielleicht gar Prozeduren und Funktionen?) erstellt und macht, sich nicht um die Speicherverwaltung kümmern muss. Was sehr praktisch und entspannend ist. Aber so bald man verstärkt selbst eigene Teile erstellt (eigene Komponenten - und vielleicht zählt auch manche Prozedure/Funktion dazu?), scheint mir dieser Vorteil teils vorbei zu sein? Oder bringe ich da wieder vieles durcheinander? Jedenfalls ist es doch scheinbar so, je mehr man in den 'Angebotenen Teilen' (Komponenten, Funktionen, Prozedure) von FPC/Lazarus eingreift, desto wahrscheinlicher, dass man sich auch um Dinge (Speicherverwaltung) selbst kümmern muss, um die man sich sonst nicht kümmern müsste?
Und die Beschreibungen zu Komponenten und Co sind leider immer wieder mal alles andere als Standardsiert und Richtig.
Lazarus 2.2.0 / FP 3.2.4

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Ist die Klassische OOP gescheitert?

Beitrag von pluto »

Der große Vorteil von Komponenten ist vermutlich auch die Namensvergabe?

Was genau meinst du damit? Klar, kann ich, wenn ich eine neue Komponente erstelle, oder von einer Ableite auch ein neuen Namen geben....
Ob das jetzt EIN GROßER Vorteil ist, wage ich zu bezweifeln..... es ist einfach so...

Also wenn man mehr Blinklabels macht, dass man jedem davon extra Namen gehen kann und einfach darüber ansprechen und Werte ändern etc. kann. Allerdings ist jetzt wieder das mit dem Create aufgetaucht?

Hä? Jede Klasse muss einmal mit Create "Installiesiert" werden. Das hat erst mal nichts mit Komponenten zu tun...

Ich habe insgesamt den Eindruck, dass man mit dem Erstellen von eigenen Komponenten paar Vorteile von FPC/Lazarus dann opfern muss.

welche Vorteil muss man Opfern? Komponenten/Klassen bereichern im allgemeinen die Fähigkeiten von FPC/Lazarus, auch wenn sie zu mehr unübersichtlich führen.
Wie du schon bei "Delphi" beim bekannten gesehen, hast, weiß du ja wohin das führen kann....
Hier muss man für sich den Mittelweg finden, zwischen einfachen Units, wo Proceduren und Funktionen und Strukturen drin sind oder eben ob man das als Klasse aufbaut.

Weil wenn ich das richtig verstanden habe, muss man sich, so lange man selbst nichts an Komponenten (und betrifft das vielleicht gar Prozeduren und Funktionen?) erstellt und macht, sich nicht um die Speicherverwaltung kümmern muss.

Das ist ein Trugschluss:
Du musst dich immer um die Speicherverwaltung kümmern, sobald die Klassen manuell erstellst. Nehmen wir an:
Du erstellt eine TStringList, die solltest du am ende auch wider Freigeben.

Automatisch erstellte Komponenten werden in der Regel auch Automatisch wieder Freigeben, aber nur hier.

Was sehr praktisch und entspannend ist. Aber so bald man verstärkt selbst eigene Teile erstellt (eigene Komponenten - und vielleicht zählt auch manche Prozedure/Funktion dazu?), scheint mir dieser Vorteil teils vorbei zu sein?

Das ist kein Vorteil, dass ist einfach "Programmieren"... das Freigeben von nicht mehr gebrauchten Speicher gehört dazu. Wie beim Streichen von Wänden, die Vorbereitungen, einfach dazu gehören.

Jedenfalls ist es doch scheinbar so, je mehr man in den 'Angebotenen Teilen' (Komponenten, Funktionen, Prozedure) von FPC/Lazarus eingreift, desto wahrscheinlicher, dass man sich auch um Dinge (Speicherverwaltung) selbst kümmern muss, um die man sich sonst nicht kümmern müsste?

Genau. Entweder man Programmiert oder eben nicht...
Das gehört einfach dazu.... Das hat nichts mit eingreifen oder so zu tun.
Jedes Programm, egal wie einfach es ist, wird früher oder später Speicher belegen, welches auch wieder manuell freigegeben werden sollte oder sogar muss...

Und die Beschreibungen zu Komponenten und Co sind leider immer wieder mal alles andere als Standardsiert und Richtig.

Das ist jetzt schon deutlich besser als 2006, als ich mit Lazarus angefangen habe... So gut wie bei Delphi wird es wohl nie werden, aber das ist auch gar nicht das Ziel. Lazarus ist OpenSoruce. Die Kern Entwickler Entwicklern Lazarus in ihrer Freizeit. Sie opfern ihre Freizeit. Klar, haben sie keine Lust, eine Komplexe Doku zu schreiben... es gibt aber eine, fpc-wiki...nicht immer aktuell, aber ausreichend.
Dafür ist Lazarus Kostenlos und sie Sorucen sind eine Gold-Grube... Da kann man viel Lernen...

Jeder für sich muss entscheiden, ob Programmieren was für ihn ist oder eben nicht.
Je mehr Programmiersprachen man in laufe der Zeit lernt, je desto mehr kann man beurteilen was gut ist und was schlecht ist.
Letztens habe ich gehört: Erst ab 10 Programmiersprachen kann man z.b. Beurteilen, ob die Klassische OOP gescheitert ist oder nicht. Alles andere wäre nicht aussage Kräftigt.

Ich denke aber, wie viele können wirklich über 10 Programmiersprachen? Damit meine ich jetzt nicht nur die Syntax sondern auch die Konzepte, die komplette Umgebung...
Und kennen dann noch die feinen Unterschiede zwischen den einzelnen Versionen...
MFG
Michael Springwald

braunbär
Beiträge: 369
Registriert: Do 8. Jun 2017, 18:21
OS, Lazarus, FPC: Windows 10 64bit, Lazarus 2.0.10, FPC 3.2.0
CPU-Target: 64Bit
Wohnort: Wien

Re: Ist die Klassische OOP gescheitert?

Beitrag von braunbär »

Erwin hat geschrieben:
braunbär hat geschrieben:So ist die Lazarus/FPC Umgebung auch für mich immer wieder von Neuem eine Herausforderung, obwohl ich mit Delphi viele Jahre Erfahrung habe. Im Detail ist es dann eben doch nicht ganz das Gleiche...

Du meinst aber Delphi? Nicht den Nachfolger Embar... und noch irgendwie. Weil bei dem E. ... ich habe mir das mal bei einem Bekannten angeschaut, der das hat ... das hat eine Komponenten-Flut ... da wäre ich sogar bereit gewesen, notfalls durch das Fenster abzuhauen.

Was ist das Problem bei dieser "Komponentenflut"? Du brauchst zu Beginn nur einige wenige Komponenten kennen und verwendest die. Und wenn du ein Problem hast, das du mit den dir bekannten Komponenten nicht lösen kannst, dann KANNST du schauen (und eventuell sogar hier fragen), ob es vielleicht schon eine fertige Komponente gibt, die das macht, was du brauchst, statt es selber auszuprogrammieren.
Ich habe es schon vorher geschrieben - natürich ist die Lernkurve bei einem derart umfangreichen System wie der LCL (oder Delphi) flach und es ist am Anfang mühsam. Aber wenn man einmal herausgefunden hat, wie es geht, dann spart es sehr viel Aufwand, weil man eben auf fertigen und (zumindest meistens :D ) gut getesteten Code zurückgreifen kann.

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Ist die Klassische OOP gescheitert?

Beitrag von pluto »

Ich habe es schon vorher geschrieben - natürich ist die Lernkurve bei einem derart umfangreichen System wie der LCL (oder Delphi) flach und es ist am Anfang mühsam. Aber wenn man einmal herausgefunden hat, wie es geht, dann spart es sehr viel Aufwand, weil man eben auf fertigen und (zumindest meistens :D ) gut getesteten Code zurückgreifen kann.

Das ist der Größte Vorteil von Lazarus bzw. von solchen Umgebungen...

Das Problem ist natürlich der Anfang, da sehe ich auch bei mir, ich Arbeite mich "gerade" wieder in eine für mich neue Umgebung ein und verstehe in der regel nur "Bahnhof"...
MFG
Michael Springwald

Erwin
Beiträge: 286
Registriert: Mi 16. Sep 2009, 14:15
OS, Lazarus, FPC: Xubuntu 22.04 / x86_64_linux-gtk 2 / L 2.2.0 / FPC 3.2.2

Re: Ist die Klassische OOP gescheitert?

Beitrag von Erwin »

pluto hat geschrieben:Was genau meinst du damit? Klar, kann ich, wenn ich eine neue Komponente erstelle, oder von einer Ableite auch ein neuen Namen geben....
Ob das jetzt EIN GROßER Vorteil ist, wage ich zu bezweifeln..... es ist einfach so...

Mit Namensvergabe meinte ich nicht den Namen der Komponente, sondern den Namen der eingesetzten Komponente. Als Beispiel: Man zeichnet 3 einfache Häuser (Quadrat und Dreieck oben drauf). Dies kann man, wenn nicht alles täuscht, auch als Komponente mache. 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. 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.

pluto hat geschrieben:welche Vorteil muss man Opfern? Komponenten/Klassen bereichern im allgemeinen die Fähigkeiten von FPC/Lazarus, auch wenn sie zu mehr unübersichtlich führen.

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

pluto hat geschrieben:
Weil wenn ich das richtig verstanden habe, muss man sich, so lange man selbst nichts an Komponenten (und betrifft das vielleicht gar Prozeduren und Funktionen?) erstellt und macht, sich nicht um die Speicherverwaltung kümmern muss.

Das ist ein Trugschluss:
Du musst dich immer um die Speicherverwaltung kümmern, sobald die Klassen manuell erstellst. Nehmen wir an:
Du erstellt eine TStringList, die solltest du am ende auch wider Freigeben.

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.

pluto hat geschrieben:Das ist kein Vorteil, dass ist einfach "Programmieren"... das Freigeben von nicht mehr gebrauchten Speicher gehört dazu. Wie beim Streichen von Wänden, die Vorbereitungen, einfach dazu gehören.

Aber die eigentliche Frage ist, ab wann ist das nötig? Dazu kommt es leider keine Einstimmige Antwort. Jeder erzählt was anderes.

pluto hat geschrieben:
Und die Beschreibungen zu Komponenten und Co sind leider immer wieder mal alles andere als Standardsiert und Richtig.

Das ist jetzt schon deutlich besser als 2006, als ich mit Lazarus angefangen habe... So gut wie bei Delphi wird es wohl nie werden, aber das ist auch gar nicht das Ziel. Lazarus ist OpenSoruce. Die Kern Entwickler Entwicklern Lazarus in ihrer Freizeit. Sie opfern ihre Freizeit. Klar, haben sie keine Lust, eine Komplexe Doku zu schreiben... es gibt aber eine, fpc-wiki...nicht immer aktuell, aber ausreichend.
Dafür ist Lazarus Kostenlos und sie Sorucen sind eine Gold-Grube... Da kann man viel Lernen...

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. 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.
Da schreiben dann Viele eine Anleitung dazu, die voller Fehler ist. Da sind sogar einige dabei, die lesen von anderen deren Dokus oder Buch, und schreiben mit ihren eigenen Worten dann eine Anleitung zu der Programmier-Sprache, wo vieles hinten und vorne nicht stimmt, weil dieser Schreiber nicht wirklich was davon versteht und auch nicht kann, so kurz wie manche sich damit beschäftigen.
Ich habe ca. 7 Bücher über Delphi. In ca. 5 wird das mit den Komponenten behandelt. In den meisten ist es sogar so, dass sie sich viel mehr Zeit mit Banalem, wie Variablen sich nehmen (weil die davon selber viel verstehen), aber sich kaum (manchmal nur halb so viel) Zeit für eigene Komponenten-Erstellung nehmen. 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. Bei jedem 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.
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? 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 mit dem Speicherfreigeben (was laut dem einen bei Komponente Pflicht ist, beim anderem wiederum nicht) ist auch so eine Sache. Der eine erklärt in seinem Buch, dass dies eh am Ende des Programms wieder freigegeben wird. Der anderen man soll den Speicher frei geben, so bald man es nicht mehr im Programm braucht. Der nächste schreibt, man soll sofort nach der Erstellung & Datenfüllung frei geben - was auch klappte und dennoch weiterhin vorhanden war (? was mich irritiert - weil ich den Sinn/Logik nicht verstehe). 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?).
Lazarus 2.2.0 / FP 3.2.4

Benutzeravatar
m.fuchs
Lazarusforum e. V.
Beiträge: 2636
Registriert: Fr 22. Sep 2006, 19:32
OS, Lazarus, FPC: Winux (Lazarus 2.0.10, FPC 3.2.0)
CPU-Target: x86, x64, arm
Wohnort: Berlin
Kontaktdaten:

Re: Ist die Klassische OOP gescheitert?

Beitrag von m.fuchs »

Erwin hat geschrieben:
pluto hat geschrieben:Du erstellt eine TStringList, die solltest du am ende auch wider Freigeben.

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.

Nicht jeder hat eine eigene Wahrheit, du bist bloß immer noch auf dem gleichen Trip wie vor einem Jahr und würfelst fröhlich Dinge durcheinander.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de

pluto
Lazarusforum e. V.
Beiträge: 7178
Registriert: So 19. Nov 2006, 12:06
OS, Lazarus, FPC: Linux Mint 19.3
CPU-Target: AMD
Wohnort: Oldenburg(Oldenburg)

Re: Ist die Klassische OOP gescheitert?

Beitrag von pluto »

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...
MFG
Michael Springwald

Antworten