Genau das tust du aber mit deinem Titel.pluto hat geschrieben:Ich wollte es jetzt nicht einfach als Fakt so dahinstellenIst OOP gescheitert?
Das reicht doch völlig um darüber zu diskutieren.
Ach so... Die Idee ist nicht schlecht, vielleicht rettet das, dass Thema ja noch, wer weiß... ich pass den Titel erneut an.Genau das tust du aber mit deinem Titel. Mein Vorschlag war eine Frage: Ist OOP gescheitert? Das behauptet nichts.
Nein, das möchte ich nicht im gegenteil. Ich gebe zu, ich habe wohl einige Fehler gemacht,Aber irgendwie habe ich das Gefühl, du willst hier einfach nur schwurbeln.
Woher kommt eigentlich diese Mode, Zitate falsch zuzuordnen? Ich habe das nicht geschrieben.Timm Thaler hat geschrieben:m.fuchs hat geschrieben:Morgen sagen ich dann die Erde ist keine Kugel sondern eine Kartoffel...
Weil die "Aussage eines Bekannten" kein Beleg ist und zu deinen Links habe ich dir ja schon was geschrieben.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?
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...Ist mir auch egal, glauben darfst du ja gerne was du willst. Allerdings solltest du keine Weltuntergangsstimmung verbreiten, wie mit diesen BILD-artigen Überschriften.
Da musst Du die Forensoftware fragen.pluto hat geschrieben:Woher kommt eigentlich diese Mode, Zitate falsch zuzuordnen? Ich habe das nicht geschrieben.
Die Frage kam jetzt aber nicht von mir....pluto hat geschrieben:
Woher kommt eigentlich diese Mode, Zitate falsch zuzuordnen? Ich habe das nicht geschrieben.
Da musst Du die Forensoftware fragen.
Was siehst du als Klassische OOP?Natürlich ist klassische OOP gescheitert.
Deshalb verwenden wir hier ja FPC und nicht Java.
Ja, wäre aufjedenfall schlauer gewesen... Ich bin halt davon ausgegangen, dass es eine Tatsache ist und allgemein bekannt ist.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 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.Ich finde es gut, dass Pluto die Diskussion angeregt hat. Das hat mich nachdenklich gemacht, was den Umgang mit OOP und dem ganzen betrifft.
Unter anderem. In der Modernen Entwicklung werden die GUIS heutzutage komplett mit der Klassischen OOP aufgebaut, also mit Vererbung... Genau.Hoffe ich bringe da jetzt nichts durcheinander, aber mit OOP ist doch nicht nur Klassen, sondern auch die Erstellung von Komponenten gemeint, mittels Vererbung?
Ja, oder halt die Farbe ändern...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
Es gibt verschiedene Möglichkeiten: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.
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...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?
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.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 ... .
Ja... Komponenten sind intern Klassen. Kannst du dir bei der LCL schön ansehen...Hoffe mal, ich habe nicht das Thema verfehlt ... aber Klassen und Komponente ... ist doch teils das gleiche, oder?
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.pluto hat geschrieben:Ich glaube Persönlich das höchsten zwei oder drei Leute von Anfang an verstanden haben, um was es mir geht.
Naja. Wenn man mit OOP Programmierung anfangt, ist es natürlich etwas verwirrend. Aber das scheint mir als Argument gegen Vererbung doch etwas schwach.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
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.pluto hat geschrieben:Genau. Dafür eine eigene Komponente zu schreiben, ist aus MEINER Sicht einfach übertrieben,
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.Erwin hat geschrieben:Theoretisch hätte ich auch stattdessen einfach 'IF Voraussetzung=True then TTimerLabel.Enabled:=True' schreiben können
Von neu schreiben hat ja keiner was gesagt... In Rust, wird es so gelöst, laut Wikipedia: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.
Die sonst für objektorientierte Programmierung übliche Vererbung gibt es in Rust allerdings nicht, Polymorphie wird stattdessen durch Traits und generische Programmierung ermöglicht
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...Es wird halt in der EDV-Welt wie in vielen anderen Bereichen auch alle paar Monate eine neue Sau durchs Dorf getrieben.
Das ist wäre dann eine Art Container... wenn ich diesen "Container" mehrfach verwenden möchte oder es plane...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.
Auch hierfür gibt es allgemeine Lösungen.... Angenommen, du möchtest, alle Felder prüfen, ob die Eingaben den regeln entsprechen....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?
Das immer gleich alles Drastisch Falsch verstanden wird und sich alle Persönlich angegriffen fühlen....verstehe ich nicht...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.
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....Der Punkt ist: Es ist doch nicht mehr Aufwand, die gewünschten Features in eine abgeleitete Komponente zu packen, als andersrum.
Oder du schreibst dir eine allgemeine Funktion, der du ein TLabel übergeben kannst, wo ist das Problem?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.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.
Verein
Links
Suche
