Ist die Klassische OOP gescheitert?

Für Dinge zum Forum, Kritik, Verbesserungsvorschläge, Umfragen und ähnliches.

Re: Die Klassische OOP gilt als gescheitert

Beitragvon theo » 15. Jan 2019, 16:46 Re: Die Klassische OOP gilt als gescheitert

pluto hat geschrieben:
Ist OOP gescheitert?
Das reicht doch völlig um darüber zu diskutieren.

Ich wollte es jetzt nicht einfach als Fakt so dahinstellen


Genau das tust du aber mit deinem Titel.
Mein Vorschlag war eine Frage: Ist OOP gescheitert?
Das behauptet nichts.

Aber irgendwie habe ich das Gefühl, du willst hier einfach nur schwurbeln.
In Teilen Deutschlands sagt man:
"Rüttle nicht am Watschenbaum, die Frucht ist reif, du merkst es kaum!"
:lol:
theo
 
Beiträge: 8116
Registriert: 11. Sep 2006, 18:01

Beitragvon pluto » 15. Jan 2019, 16:57 Re: Die Klassische OOP gilt als gescheitert

Genau das tust du aber mit deinem Titel. Mein Vorschlag war eine Frage: Ist OOP gescheitert? Das behauptet nichts.

Ach so... Die Idee ist nicht schlecht, vielleicht rettet das, dass Thema ja noch, wer weiß... ich pass den Titel erneut an.

Aber irgendwie habe ich das Gefühl, du willst hier einfach nur schwurbeln.

Nein, das möchte ich nicht im gegenteil. Ich gebe zu, ich habe wohl einige Fehler gemacht,
aber ich dachte halt, dass wir Ernsthaft darüber sprechen und nicht das es so ausartet... Schade.... Wirklich...

Ich für mein Teile sehe es inzwischen so:
Ob ihr es jetzt glaube oder nicht, spielt keine Rolle. Es ändert sich ja nichts...
Könnte aber gut, sein, dass dieses Thema früher oder später wider ein Thema wird, weil die "neuen" Erkenntnisse inzwischen mehrfach belegt wurden sind.

In den Fall, das wir so weiter "Diskutieren", wie bisher, steige ich aus, wenn sich die Art und weise Ändert dann alles gut....
Sowas kann man nicht belegen, womit soll ich sowas belegen, wenn die Links und die Aussage vom bekannten nicht Ausreicht?

Ich bin davon überzeugt, jedoch mache ich weiter wie bisher...
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6848
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon m.fuchs » 15. Jan 2019, 17:14 Re: Die Klassische OOP gilt als gescheitert

Timm Thaler hat geschrieben:
m.fuchs hat geschrieben:Morgen sagen ich dann die Erde ist keine Kugel sondern eine Kartoffel...

Woher kommt eigentlich diese Mode, Zitate falsch zuzuordnen? Ich habe das nicht geschrieben.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de
m.fuchs
 
Beiträge: 2005
Registriert: 22. Sep 2006, 18:32
Wohnort: Berlin
OS, Lazarus, FPC: Winux (L 1.8.4, FPC 3.0.4) | 
CPU-Target: x86, x64, arm
Nach oben

Beitragvon m.fuchs » 15. Jan 2019, 17:16 Re: Die Klassische OOP gilt als gescheitert

pluto hat geschrieben:In den Fall, das wir so weiter "Diskutieren", wie bisher, steige ich aus, wenn sich die Art und weise Ändert dann alles gut....
Sowas kann man nicht belegen, womit soll ich sowas belegen, wenn die Links und die Aussage vom bekannten nicht Ausreicht?

Weil die "Aussage eines Bekannten" kein Beleg ist und zu deinen Links habe ich dir ja schon was geschrieben.
Ist mir auch egal, glauben darfst du ja gerne was du willst. Allerdings solltest du keine Weltuntergangsstimmung verbreiten, wie mit diesen BILD-artigen Überschriften.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de
m.fuchs
 
Beiträge: 2005
Registriert: 22. Sep 2006, 18:32
Wohnort: Berlin
OS, Lazarus, FPC: Winux (L 1.8.4, FPC 3.0.4) | 
CPU-Target: x86, x64, arm
Nach oben

Beitragvon pluto » 15. Jan 2019, 17:20 Re: Ist die Klassische OOP gescheitert?

Ich habe mir eben überlegt: Vielleicht sollte ich den Thread neustarten? Wir haben jetzt 5 Seiten.... vielleicht sollten wir den Thread zu den Akten legen (Speeren oder löschen)...

Am Anfang habe ich einfach ein Fehler gemacht, der wurde mir aber erst "heute" klar... das ich was behaupte ohne das näher auszuführen....
Das war einfach zu Allgemein... Bei einem anderen Thread wurde mir das klar, dass ich selbst solche Allgemeinen Aussagen einfach "hasse".... ohne irgendwelche Gründe beizulegen....
Sie müssen ja nicht mal belegt sein...
Ich weiß nicht ob es zum Thema auch Studien gibt, aber wer glaubt noch Studien?

Ist mir auch egal, glauben darfst du ja gerne was du willst. Allerdings solltest du keine Weltuntergangsstimmung verbreiten, wie mit diesen BILD-artigen Überschriften.

Ich habe es nicht als "Weltuntergangsstimmung" angesehen... Darf man nicht mal was behaupten ohne das es gleich als Welteruntergang angesehen wird? So wichtig ist die OOP ja nun auch wieder nicht...

Egal.... Neustartet oder Ende des Themas... bevor wir uns hier weiter verzetteln, was zu nichts führt würde ich sagen...
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6848
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon pluto » 15. Jan 2019, 17:38 Re: Ist die Klassische OOP gescheitert?

Bevor ich es vergesse:
Ich bedanke mich schon mal an alle beteiligten für einige neue Erkenntnisse... Im Umgang mit dem Thema: Einen Thread zu führen.
Auch wenn es eher eine art Schlammschlacht war, als eine echte Diskussion.
Ich selbst habe einiges jedenfalls gelernt...

Was ich "Grass" fand: Das es gleich mit Weltuntergangsstimmung gleichzusetzen ist... Das zeigt mir, dass einige scheinbar, um jeden Preis bei gewohnten Sachen bleiben wollen.
Es nicht mal in Erwägung ziehen, dass es vielleicht(egal wie nah oder fern) es doch stimmen könnte....
Einer meinte ja sogar ich würde hier nur rumtrollen, dabei fand ich das Thema eigentlich interessant...

Ich habe es halt falsch Angefangen, darum hat sich alles in die Falsche Richtung entwickelt...zu einer Schlammschlacht...

Vielleicht gibt es bestimmte Themen hier, worüber nicht gesprochen werden sollte... ohne gleiche wie bei Wikipedia üblich jeden Absatz zu einem entsprechenden "belegt" oder "quelle" führt...
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6848
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon Timm Thaler » 15. Jan 2019, 18:06 Re: Ist die Klassische OOP gescheitert?

pluto hat geschrieben:Woher kommt eigentlich diese Mode, Zitate falsch zuzuordnen? Ich habe das nicht geschrieben.


Da musst Du die Forensoftware fragen.
Timm Thaler
 
Beiträge: 841
Registriert: 20. Mär 2016, 22:14
OS, Lazarus, FPC: Win7-64bit Laz1.9.0 FPC3.1.1 für Win, RPi, AVR embedded | 
CPU-Target: Raspberry Pi 3
Nach oben

Beitragvon pluto » 15. Jan 2019, 18:25 Re: Ist die Klassische OOP gescheitert?

pluto hat geschrieben:
Woher kommt eigentlich diese Mode, Zitate falsch zuzuordnen? Ich habe das nicht geschrieben.


Da musst Du die Forensoftware fragen.

Die Frage kam jetzt aber nicht von mir....

edit: Ich würde einfach den Namen ändern oder gleich weglassen....
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6848
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon BeniBela » 15. Jan 2019, 22:19 Re: Ist die Klassische OOP gescheitert?

Natürlich ist klassische OOP gescheitert.

Deshalb verwenden wir hier ja FPC und nicht Java.
BeniBela
 
Beiträge: 253
Registriert: 21. Mär 2009, 17:31
OS, Lazarus, FPC: Linux (Lazarus SVN, FPC 2.4) | 
CPU-Target: 64 Bit
Nach oben

Beitragvon pluto » 15. Jan 2019, 22:24 Re: Ist die Klassische OOP gescheitert?

Natürlich ist klassische OOP gescheitert.

Deshalb verwenden wir hier ja FPC und nicht Java.

Was siehst du als Klassische OOP?
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6848
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon Erwin » 16. Jan 2019, 22:47 Re: Ist die Klassische OOP gescheitert?

Also 'gilt' finde ich, ist ein etwas schwer ein zu sortierendes Wort. Für mich ist 'gilt' ein Wort zwischen Meinung und Tatsache. Meist ist es doch eher so, dass sich Leute zu etwas treffen (Pokern?), und dann sich darauf einigen, welcher der vielen Pokerregeln nun in diesem Spiel 'gelten'. Und so kann man auch einer der ursprünglichen Überschriften verstehen, finde ich: Es gibt halt Programmierer, für diese (!) 'gilt' OOP als gescheitert.

Ich finde es gut, dass Pluto die Diskussion angeregt hat. Das hat mich nachdenklich gemacht, was den Umgang mit OOP und dem ganzen betrifft.
Hoffe ich bringe da jetzt nichts durcheinander, aber mit OOP ist doch nicht nur Klassen, sondern auch die Erstellung von Komponenten gemeint, mittels Vererbung?
Ich wollte mal eine Blink-Label-Komponente schreiben. Also mit Vererbung vom Label. Hat eine Zeit lang gedauert, bis ich begriff, wie das geht, und irgendwie wollte das mir nicht so ganz zusagen. Theoretisch hätte ich auch stattdessen einfach 'IF Voraussetzung=True then TTimerLabel.Enabled:=True' schreiben können. Und die zusätzlichen Codezeilen ('If LabelFarbe=1 then LabelFarbe := 2 else LabelFarbe :=1') in den TTimer packen können. Denke mal, dass dies kaum einen Unterschied gespielt hätte. Oder ich hätte den TTimer gleich auf True einstellen können, und innerhalb des TTimers abfragen, ob das betreffende Label die Voraussetzung für das Blinken erfüllt, und in den IF-Block dann das mit den Farben.

Denke mal, dass ist auch Teils einer der wesentlichen Fragen, ab wann es Sinn macht, wegen 1-2 Erweiterungen, gleich zu Vererben, anstatt es per Codezeilen zu regeln?
Zumindest beschäftigt mich diese Frage in dem Zusammenhang. Einerseits hat es (zumindest Gedanklich, weil das mit dem Vererben ... bekomme ich nicht so einfach hin) was sehr Verführerisches. Anstatt zu einer Komponente etc. 2-3 Codezeilen zu schreiben, gleich eine neue zu erstellen, und sich nie mehr um diese 2-3 Codezeilen kümmern müssen, und alles was zusammen gehört, ist zusammen. Und die Komponenten-Palette wird dabei auch unübersichtlicher ... .

Hoffe mal, ich habe nicht das Thema verfehlt ... aber Klassen und Komponente ... ist doch teils das gleiche, oder?
Win 7 / Lazarus 1.6 / FP 3.0.0 / x86_64-win64-win32/win64
Erwin
 
Beiträge: 222
Registriert: 16. Sep 2009, 13:15
OS, Lazarus, FPC: Xubuntu 16.04 / x86_64_linux-gtk 2 / L 1.6+dfsg-1 / FPC 3.0.0 | 
Nach oben

Beitragvon pluto » 17. Jan 2019, 00:08 Re: Ist die Klassische OOP gescheitert?

Also 'gilt' finde ich, ist ein etwas schwer ein zu sortierendes Wort. Für mich ist 'gilt' ein Wort zwischen Meinung und Tatsache. Meist ist es doch eher so, dass sich Leute zu etwas treffen (Pokern?), und dann sich darauf einigen, welcher der vielen Pokerregeln nun in diesem Spiel 'gelten'. Und so kann man auch einer der ursprünglichen Überschriften verstehen, finde ich: Es gibt halt Programmierer, für diese (!) 'gilt' OOP als gescheitert.

Ja, wäre aufjedenfall schlauer gewesen... Ich bin halt davon ausgegangen, dass es eine Tatsache ist und allgemein bekannt ist.
Ich bin halt nicht davon ausgegangen, dass es "eine" Meinung ist...
Aber deine gilt "Deutung" finde ich gut.... Im Nachhinein weiß man es immer besser.

Ich bin dabei ein neuen Thread vorzubereiten, ob ich ihn auch erstellen werde weiß ich allerdings derzeit nicht...
Auf Grund der gemachten Erfahrung. Auf der anderen Seite, habe ich aus meinen "Fehlern" gelernt und habe vor den zweiten Thread komplett anders zu führen, als den ersten...

Ich finde es gut, dass Pluto die Diskussion angeregt hat. Das hat mich nachdenklich gemacht, was den Umgang mit OOP und dem ganzen betrifft.

Ich glaube Persönlich das höchsten zwei oder drei Leute von Anfang an verstanden haben, um was es mir geht... Auch wenn ich mich "falsch" ausgedrückt hatte im ersten Beitrag in der Ursprungsversion.

Hoffe ich bringe da jetzt nichts durcheinander, aber mit OOP ist doch nicht nur Klassen, sondern auch die Erstellung von Komponenten gemeint, mittels Vererbung?

Unter anderem. In der Modernen Entwicklung werden die GUIS heutzutage komplett mit der Klassischen OOP aufgebaut, also mit Vererbung... Genau.

Ich wollte mal eine Blink-Label-Komponente schreiben. Also mit Vererbung vom Label. Hat eine Zeit lang gedauert, bis ich begriff, wie das geht, und irgendwie wollte das mir nicht so ganz zusagen. Theoretisch hätte ich auch stattdessen einfach 'IF Voraussetzung=True then TTimerLabel.Enabled:=True' schreiben können

Ja, oder halt die Farbe ändern...

Und die zusätzlichen Codezeilen ('If LabelFarbe=1 then LabelFarbe := 2 else LabelFarbe :=1') in den TTimer packen können. Denke mal, dass dies kaum einen Unterschied gespielt hätte. Oder ich hätte den TTimer gleich auf True einstellen können, und innerhalb des TTimers abfragen, ob das betreffende Label die Voraussetzung für das Blinken erfüllt, und in den IF-Block dann das mit den Farben.

Es gibt verschiedene Möglichkeiten:
Im OnTimer Event wäre sowas hier bestimmt sinnvoll:
if MyLabel.color = clBlue then
mache es Rot
else
mache es Blau
Den Timer würde ich dann alle 2 oder 3 Sekunden aufrufen oder so.

Denke mal, dass ist auch Teils einer der wesentlichen Fragen, ab wann es Sinn macht, wegen 1-2 Erweiterungen, gleich zu Vererben, anstatt es per Codezeilen zu regeln?

Genau. Dafür eine eigene Komponente zu schreiben, ist aus MEINER Sicht einfach übertrieben, es sei denn es gibt noch mehr Möglichkeiten und auch gute Gründe...

Anstatt zu einer Komponente etc. 2-3 Codezeilen zu schreiben, gleich eine neue zu erstellen, und sich nie mehr um diese 2-3 Codezeilen kümmern müssen, und alles was zusammen gehört, ist zusammen. Und die Komponenten-Palette wird dabei auch unübersichtlicher ... .

Eine eigene Komponente zu schreiben ist aufjedenfall ein Einfacher weg, genau so, wie eben diese Code Zeilen in eine Funktion zu packen, die man möglich einfach aufrufen kann z.b. mit einem beliebigen Label.

Hoffe mal, ich habe nicht das Thema verfehlt ... aber Klassen und Komponente ... ist doch teils das gleiche, oder?

Ja... Komponenten sind intern Klassen. Kannst du dir bei der LCL schön ansehen...
Schau dir das mal bei TLabel zum Beispiel an und schau dir an, wie weit die Vererbung runter geht und wie viele Klassen es im Einzelnen sind.
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6848
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon braunbär » 17. Jan 2019, 17:26 Re: Ist die Klassische OOP gescheitert?

pluto hat geschrieben:Ich glaube Persönlich das höchsten zwei oder drei Leute von Anfang an verstanden haben, um was es mir geht.

Wenn ich ganz ehrlich bin, verstehe ich es auch jetzt noch nicht. es gibt sicher schlecht designte Klassen, daran ist aber nicht das OOP Konzept schuld. Es ist richtig, dass Programme, die Vererbung intensiv nutzen, unter Umständen dann schwerer lesbar sind. Aber deshalb Unmengen ähnlichen Code immer wieder neu zu scheiben, scheint mir dann doch nicht die optimale Lösung für das Problem zu sein. Es wird halt in der EDV-Welt wie in vielen anderen Bereichen auch alle paar Monate eine neue Sau durchs Dorf getrieben.

Erwin hat geschrieben:Ich wollte mal eine Blink-Label-Komponente schreiben. Also mit Vererbung vom Label. Hat eine Zeit lang gedauert, bis ich begriff, wie das geht, und irgendwie wollte das mir nicht so ganz zusagen

Naja. Wenn man mit OOP Programmierung anfangt, ist es natürlich etwas verwirrend. Aber das scheint mir als Argument gegen Vererbung doch etwas schwach.
Wenn es schon eine Komponente gibt, die fast die ganze Funktionalität bietet die ich brauche, aber nicht alles kann, was ich will, dann fällt mir eigentlich nichts praktischeres ein als Vererbung zu nutzen.

pluto hat geschrieben:Genau. Dafür eine eigene Komponente zu schreiben, ist aus MEINER Sicht einfach übertrieben,

Verstehe ich nicht. Wenn ich in meinem Programm Edit-Felder haben will , die sich auf eine bestimmte Art verhalten, was das Standard edit nicht kann, dann schreibe ich eine Komponente mit der Eigenschaft. Warum soll ich mich bei jedem neuen Edit-Feld, das ich ins Formular einfüge, darum kümmern müssen, dass es das macht, was ich haben will? 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.
Der Punkt ist: Es ist doch nicht mehr Aufwand, die gewünschten Features in eine abgeleitete Komponente zu packen, als andersrum.

Erwin hat geschrieben:Theoretisch hätte ich auch stattdessen einfach 'IF Voraussetzung=True then TTimerLabel.Enabled:=True' schreiben können

Irgendwie machst du es ja genauso so, wenn du die Komponente ableitest. Nur eben in einer Methode der Komponente (wo es ja hingehört), statt in eine frei "schwebende" Prozedur des Programms. Und vor allem: wenn du das an mehreren Stellen brauchst, dann nimmst du einfach überall deine abgeleitete Komponente und brauchst dich um nichts weiter kümmern.
braunbär
 
Beiträge: 286
Registriert: 8. Jun 2017, 17:21

Beitragvon pluto » 17. Jan 2019, 17:51 Re: Ist die Klassische OOP gescheitert?

Wenn ich ganz ehrlich bin, verstehe ich es auch jetzt noch nicht. es gibt sicher schlecht designte Klassen, daran ist aber nicht das OOP Konzept schuld. Es ist richtig, dass Programme, die Vererbung intensiv nutzen, unter Umständen dann schwerer lesbar sind. Aber deshalb Unmengen ähnlichen Code immer wieder neu zu scheiben, scheint mir dann doch nicht die optimale Lösung für das Problem zu sein.

Von neu schreiben hat ja keiner was gesagt... In Rust, wird es so gelöst, laut Wikipedia:
Zitat von Wikipedia: https://de.wikipedia.org/wiki/Rust_(Programmiersprache)#Typsystem
Die sonst für objektorientierte Programmierung übliche Vererbung gibt es in Rust allerdings nicht, Polymorphie wird stattdessen durch Traits und generische Programmierung ermöglicht


Es wird halt in der EDV-Welt wie in vielen anderen Bereichen auch alle paar Monate eine neue Sau durchs Dorf getrieben.

Dies ist jetzt aber keine neue Erkenntnis... Rust z.b. wird z.b. seit 2010 entwickelt, ob die Sache mit der Vererbung dort schon von Anfang an anders gelöst wurde, weiß ich nicht...

Verstehe ich nicht. Wenn ich in meinem Programm Edit-Felder haben will , die sich auf eine bestimmte Art verhalten, was das Standard edit nicht kann, dann schreibe ich eine Komponente mit der Eigenschaft.

Das ist wäre dann eine Art Container... wenn ich diesen "Container" mehrfach verwenden möchte oder es plane...

arum soll ich mich bei jedem neuen Edit-Feld, das ich ins Formular einfüge, darum kümmern müssen, dass es das macht, was ich haben will?

Auch hierfür gibt es allgemeine Lösungen.... Angenommen, du möchtest, alle Felder prüfen, ob die Eingaben den regeln entsprechen....
Dann brauchst du bloß eine Funktion schreiben, die alle Felder durchgeht(allgemein, auch für andere Projekte) und in dieser Funktion prüfen, ob die Felder den Regeln entsprechend gefüllt worden sind oder nicht.... dafür jetzt eine extra Komponente zu schreiben, ist doch etwas übertrieben oder?
Wenn es dir jetzt darum gehen würde....

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

Der Punkt ist: Es ist doch nicht mehr Aufwand, die gewünschten Features in eine abgeleitete Komponente zu packen, als andersrum.

Es geht immer darum wie man es schreiben... Es gibt bestimmt ZIG Möglichkeiten, ein Problem zu lösen ohne gleich auf die Vererbung nutzen zu müssen....
Mit Lösungen meine ich jetzt, die, die sich wiederverwenden lassen....

Irgendwie machst du es ja genauso so, wenn du die Komponente ableitest. Nur eben in einer Methode der Komponente (wo es ja hingehört), statt in eine frei "schwebende" Prozedur des Programms. Und vor allem: wenn du das an mehreren Stellen brauchst, dann nimmst du einfach überall deine abgeleitete Komponente und brauchst dich um nichts weiter kümmern.

Oder du schreibst dir eine allgemeine Funktion, der du ein TLabel übergeben kannst, wo ist das Problem?

Ich selbst habe Programmieren NIE von A bis Z gehabt. Ich habe es NIE in der Schule gehabt.... daher kenne ich viele Details nicht bzw. noch nicht...
Es gibt immer mehr als EINE Lösung, für ein Problem, eine Lösung, die vielleicht sogar noch besser ist...

Bleiben wir bei den Blink Beispiel, dass ist eine gute Idee...
1. Einfach per "Timer" lösen, für eine Label Komponente.
2. per Timer Lösen für Mehrer Komponenten. Z.B. mit der Tag Eigenschaft(ist zwar unschön, geht aber).
3. Eine eigene Methode/procedure schreiben, die mit einem TLabel aufgerufen wird...
4. Es kann ausgelagert werden in eine eigene Unit.
Es gibt bestimmt noch viel mehr Möglichkeiten....

..... Als gleich eine neue Klasse ableiten und es dort einbauen. Aber es kommt immer darauf an, was ihr wollt und wie ihr es umsetzten wollt....
Wenn ihr unbedingt per Vererbung machen, wollt bitte... kann aber den allgemeinen Regeln der Vererbung widersprechen, auch wenn es Funktionieren wird.
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6848
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon Erwin » 17. Jan 2019, 21:13 Re: Ist die Klassische OOP gescheitert?

braunbär hat geschrieben:Irgendwie machst du es ja genauso so, wenn du die Komponente ableitest. Nur eben in einer Methode der Komponente (wo es ja hingehört), statt in eine frei "schwebende" Prozedur des Programms. Und vor allem: wenn du das an mehreren Stellen brauchst, dann nimmst du einfach überall deine abgeleitete Komponente und brauchst dich um nichts weiter kümmern.

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. Des weiteren scheinst Du der Ansicht zu sein, dass alles in Komponenten rein soll? Das finde ich verwirrend. So wie damals, als ich statt Terminal/Texteingabe (Schneider CPC) nur noch Grafik (Atari ST) hatte. Ich nutze GUI etc., weil es schneller und einfacher geht. Und in Fällen von Linux-Distri, wenn es so weit auch oft klappt, überschreite ich irgendwann den Zeitpunkt, wo ich mich dann mit Grafischer Oberfläche wohler fühle. Aber dennoch läuft das wesentliche außerhalb der grafischen Darstellung ab. Bei Lazarus ist das eben die GUI und die Komponenten, ... so lange die funktionieren ... aber für mich laufen die eher außerhalb des eigentlichen Formulars ab. Aber es scheint meist zu funktionieren ist ... schneller (?) ... zumindest lässt sich damit vieles bequemer gestalten.

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

In meinen Fall ist es sogar so, dass ich nicht mal die neuen Komponenten auf eine eigene erstellte (Reiter-)Seite einfügen kann. Was aber eher Nebensache sein darf, aber einen dennoch aufhält, zumindest so lange, bis ich das herausgefunden habe, was da schief läuft.
Win 7 / Lazarus 1.6 / FP 3.0.0 / x86_64-win64-win32/win64
Erwin
 
Beiträge: 222
Registriert: 16. Sep 2009, 13:15
OS, Lazarus, FPC: Xubuntu 16.04 / x86_64_linux-gtk 2 / L 1.6+dfsg-1 / FPC 3.0.0 | 
Nach oben

» Weitere Beiträge siehe nächste Seite »
VorherigeNächste

Zurück zu Allgemeines



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

porpoises-institution
accuracy-worried