Ist die Klassische OOP gescheitert?

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

Re: OOP gilt als gescheitert

Beitragvon Warf » 14. Jan 2019, 16:52 Re: OOP gilt als gescheitert

pluto hat geschrieben:Nachrichtenaustausch... Ich dachte immer es geht um Struktur... Ich habe jetzt ein Problem und das möchte ich möglich gut strukturieren...

Ist ja Interessant.. Daher kommt die OOP?

Stelle ich mir auch Problematisch vor... wie soll das im Einzelfall gehen?
Nehmen wir als Beispiel wenn möglich eine GUI


Ja die LCL implementiert das sogar nichtig gut, durch das widgetset design. Zu deinem Beispiel, nehmen wir an ich will in der LCL einen neuen Coolen Button verwenden den ich mit OpenGL und tollen shadern schön bunt und Blinkend selbst zeichnen will, ohne dabei mein Programm was bisher TButton verwendet kaputt zu machen. Dafür kann ich im Widgetset die Implementation des Buttons überarbeiten, oder einfach die klasse TCustomButton durch eine eigene Implementation austauschen. Wenn du dir die Definition von TButton hier mal anschaust, die enthält absolut keine Funktionalität, sondern definiert nur alle Properties die vorhanden sein Müssen. Man kann also problemlos den CustomButton verändern, solang das Interface zu TButton erhalten bleibt merkt man als "Endnutzer" (doofes wort für einen Programmierer) nichts davon.

Der Fokus auf Nachrichtenaustausch sieht man auch in Großen Frameworks wie der LCL oder .Net, wo praktisch alles über Events gemacht wird. Somit kann man Objekte einfach austauschen, ohne das es kaputt geht da man nur die events neu registrieren muss, und niemand annahmen über die Objekte selbst macht

Richtig, oder das Konzept durcheinander bringen kann... weil dann alles angepasst werden muss...
Z.B. ich füge ein Parameter in einer Methode hinzu, die überall überladen wird...

Man sollte sich halt im klaren sein das sobald man virtual irgendwo hinschreibt und das projekt nicht trivial klein ist, man im nachhinein nichts mehr ändern kann ohne massiven aufwand. Daher sollte man auch lieber sparsam mit dem vritual keyword sein und sich wirklich überlegen ob man es auch tatsächlich braucht.

JavaScript hat ja keine OOP sondern, Protype oder so ähnlich...

Jain, es ist einfach ein neuer ansatz zu OOP, die Idee ist die selbe, man hat Objekte die miteinander kommunizieren, nur halt komplett anders aufgezogen. Was man davon hält ist jedem selbst überlassen (ich mag es nicht)

Andere sagen wieder, dass OOP in Firmen bereits verboten wurde bzw. nicht verwendet wird....
Ich finde die OOP in sehr vielen Punkte recht gut, nur halt das mit der Vererbung ist so eine Sache...
Zum beispiel Java erlaubt Mehrfach Vererbung, in anderen Sprachen gilt das als Schlechter Programmierstile....

Also das ist zumindest das was mir so von meinem Software Technik prof damals gesagt wurde. OOP ist das beste was du machen kannst, solang es gut durchdacht ist

Ich mache mir in der Regel vorher "Grobe" Gedanken und schreibe sie mir mit einem Text Editor auf.... weil beim Programmieren kann man das eine oder andere schnell "vergessen"...
meisten erstelle ich mir eine reihe von Prototypen, dann weiß ich genau wo hin die "reise" geht... inzwischen bin ich sogar dazu übergangen und sage: dann mache ich das eine bestimmte zeit und erwarte das ich das in der Zeit dann auch schaffe, was auch gut Funktioniert....

Eine art Grober Zeitplan hilft natürlich auch, damit man sich nicht verzettelt...


Tatsächlich bringt die UML da schon einiges, da die genau für OOP ausgelegt ist, kann man damit halt diagramme machen die man immer wieder ansehen kann und direkt versteht. Ich hab das problem das ich meine Schriftlichen Notizen von vor einem jahr kaum noch nachvollziehen kann was ich überhaupt damit meine
Warf
 
Beiträge: 1047
Registriert: 23. Sep 2014, 16:46
Wohnort: Aachen
OS, Lazarus, FPC: Mac OSX 10.11 | Win 10 | FPC 3.0.0 | L trunk | 
CPU-Target: x86_64, i368, ARM
Nach oben

Beitragvon pluto » 14. Jan 2019, 17:08 Re: OOP gilt als gescheitert

Nun gibt es ein paar Links:
https://www.yegor256.com/2016/08/15/wha ... mming.html
https://www.leaseweb.com/labs/2015/08/o ... nally-bad/
https://content.pivotal.io/blog/all-evi ... g-bullshit
https://de.wikipedia.org/wiki/Kreis-Ellipse-Problem

Alternativen zu OOP und Konzepte, die in OOP fehlen:
https://de.wikipedia.org/wiki/Funktiona ... rammierung
https://en.wikipedia.org/wiki/Algebraic_data_type

Und über richtige Konzepte:
https://unglueit-files.s3.amazonaws.com ... 3a851d.pdf


Das ist immer noch kein praktisches Beispiel, sondern nur die Beschreibung von ein paar Properties. Was wäre denn die konkrete Aufgabestellung?

OK. Stellen wir uns vor, wir haben ein Quadrat und ein Rechteck. Die wollen wir nun in der OOP beschreiben.
Mit Hilfe eine Basis Klasse... Was haben diese beiden Formen Gemeinsam?

Dann baue ich mir ein TGeometrischesGebilde mit den beiden abstrakten Funktionen BerechneUmfang und BerechneFlaeche. Dann leite ich fröhlich alle meine Gebilde von dieser Basisklasse ab.
Und die erhalten dann notwendige Eigenschaften (TRechteck bekommt zwei Seiten, TQuadrat nur eine, TKreis hat einen Radius) und implementieren alle diese beiden Funktionen. Voilà: OOP.

was ist wenn du alle Klassen mit einer Breite und einer Höhe beschreiben möchtest?
Dann hast du eine Breite und Höhe beim Quadrat, obwohl das hier gar nicht gebraucht wird.

Einspruch. Hast du denn eine Alternative die nicht OOP ist und übersichtlicher? Und vor allen Dingen ohne Code-Dopplung. Die Komplexität der LCL hängt mit der hohen Masse an Funktionalität zusammen.

Eine Alternative habe ich natürlich nicht... darum habe ich das Konzept aufgegeben, weil ich überzeugt bin es hat Fehler im Konzept....

Ja, aber vielleicht hast du aus anderen Gründen den Überblick verloren. Wie hast du die Anforderungen erstellt? Wie die Architektur? Wie war dein Projektmanagement?

Die Anforderungen sind einfach:
Ich möchte Formatierten Text anzeigen können und bearbeiten können.
D.h. jeder Buchstabe soll anders aussehen können. Es soll ein Automatischen Zeilenumbruch geben.
Es soll Listen, Tabellen, Grafiken eingebetten werden können. Es sollen Style Eigenschaften Vererbt werden
und soweiter....
Architektur: grob kann ich dazu folgendes sagen:
es gibt eine Statische Struktur und eine Dynamische Struktur. Die Dynamische Struktur ist dabei deutlich Komplexer und wird häufiger neu aufgebaut z.b. bei einer Fenster Größen Änderung

Projektmanagement: Darüber habe ich mir noch nie Gedanken gemacht, kann mir auch nichts darunter vorstellen, vielleicht weil ich in der Regel bis auf einige Ausnahmen alleine Programmiere..

Das ist aber nur deine persönliche Sichtweise. Ich benötigt onClick im Label schon häufiger.

TLabel soll aber nur ein Text anzeigen...

So ein großes Framework ist sicherlich erst einmal gewöhnungsbedürftig. Aber es deckt auch echt sehr viel ab.

Klar, dass ist teil des Problems. Ist deckt viel zu viel ab. Wir können auch GLScene als Beispiel nehmen...

Du kannst auch einfach alles von Hand machen, eigene Objekte erstellen die nur die von dir nötigen Methoden haben. Oder einfach direkt nur auf den Bildschirm zeichnen.

Da fangen die Problem an... Den Ansatz habe ich auch schon Verfolgt. Und habe direkt auf TCanvas gesetzt...
Aber dann brauche ich immer noch eine LCL Komponente, um es anzeigen zu können, so wie in GLScene zum Beispiel.

Oder du nimmst gleich Assembler und fängst ganz unten an. Das ist bestimmt am ressourcenschonendsten. Aber es ist halt unglaublich viel Aufwand. Da ist ein fertiges Framework doch deutlich einfacher.

Es geht auch darum, eine gute Mischung zu finden, wo die Nachteile nicht, die Vorteile überwiegen...

Hm, das kommt jetzt bei mir nicht so gut an.

Dann entschuldige ich mich für meine Aussage....ich hatte halt den Eindruck... dein erster Beitrag hier war ja gleich: Du wolltest belege für meine Behauptung haben...
Das kam bei mir nicht gut an...

Wenn sie dich stört, dann lass sie doch weg.

Dann nützt mir die OOP aber kaum was...

Das geht ganz gut mit generischen Klassen, aber hast du doch nicht letztens beschwert dass du die nicht nutzen willst?

Richtig.... Aber vielleicht muss ich mir das doch noch mal genauer ansehen...

Da gibt es drei Dinge die das verhindern können: Unittests, Unittests, Unittests.

und dann hast du dort ein Fehler drin, den du nicht sofort siehst... und dann? Und du hast doppelte arbeit...
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6827
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon braunbär » 14. Jan 2019, 17:41 Re: OOP gilt als gescheitert

Die Aussage im Threadtitel ist m.E. schlicht falsch. Was soll heißen "gilt als gescheitert". Welche Instanz bestimmt das denn?

Das Problem ist ein völlig anderes: Es gibt zu wenige gute und zu viele schlechte Programmierer, aber weil der Bedarf an Programmierern immer noch steigt, sinkt die Meßlatte weiter. OOP (inklusive Vererbung) ist ein sehr mächtiges Tool, das einem Programmierer, der damit richtig umgehen kann, die Arbeit gewaltig erleichtern kann. Was m.E. allerdings abzulehnen ist, das ist der fundamentalistische Ansatz mancher OOP-Fans, die am liebsten alles und jedes in eine Klasse packen wollen, auch wenn es überhaupt keinen Nutzen bringt. Das ist aus meiner Sicht ebenso unsinnig wie z.B. die bedingungslose Ablehnung des goto oder eine strikte Zeienbeschränkung für Prozeduren.

pluto hat geschrieben:
Und ist das schlimm? Ich muss die doch nicht nutzen...

sagen wir, es ist Speicher Verschwendung...

Nein, ist es nicht (oder wenn, dann nur völli marginal).
Methoden, die in einer abgeleiteten Klasse nicht verwendet werden, brauchen überhaupt keinen Speicher. Und wenn sie in anderen abgeleiteten Klassen verwendet werden, dann ist die Grundfuktionalität für alle Klassen, die es brauchen, nur einmal in der Basisklasse implementiert und kann bei Bedarf sogar dann mittels inherited genutzt werden, wenn in der abgeleiteten Klasse noch etwas anderes zusätzlich passiert. (Der zusätzliche Speicherbedarf ist bei aktuellen Comutern völlig vernachlässigbar -in den 8080 Zeiten war das natürlich anders). Das ist eigentlich ein geniales Konzept. Aber wie bei allen anderen mächtigen Tools kann man natürlich auch damit eine Menge Mist bauen, wenn man sich nicht überlegt, wie man es einsetzt.

pluto hat geschrieben:Andere sagen wieder, dass OOP in Firmen bereits verboten wurde bzw. nicht verwendet wird....

Schlimm, dass es so viele Firmen gibt, denen das noch nicht gesagt worden ist. Die setzen immer noch OOP ein, und manche von diesen Firmen sind noch nicht einmal pleite... :D

m.fuchs hat geschrieben:Du spielst vermutlich auf die Advanced Records an. Warum auch immer die erfunden worden: sie sind nicht nur Records sondern Klassen/Objekte.

Ja, der Grund ist wohl, dass Klassen immer im Heap liegen, dass man sich aber Konstrukte, in denen Daten und Methoden gemeinsam gekapselt sind, durchaus auch statisch bzw. im Stack wünschen kann.
braunbär
 
Beiträge: 274
Registriert: 8. Jun 2017, 17:21

Beitragvon pluto » 14. Jan 2019, 17:47 Re: OOP gilt als gescheitert

Die Aussage im Threadtitel ist m.E. schlicht falsch. Was soll heißen "gilt als gescheitert". Welche Instanz bestimmt das denn?

Ich habe hier geschrieben: GILT nicht das es IST... Neue Programmiersprachen....
Der Titel ist unglücklich gewählt, ich hätte schreiben sollen: Das Klassische OOP ist gescheitert... so wie wir es kennen...

Die Gründe kann man gut in den Links sehen... ich habe mir nur den Deutschen Link angesehen, da ich Probleme mit englisch habe...

Nein, ist es nicht (oder wenn, dann nur völli marginal).

Methoden, die in einer abgeleiteten Klasse nicht verwendet werden, brauchen überhaupt keinen Speicher.

OK... Sie führen aber auch nicht zu mehr Übersicht...

Schlimm, dass es so viele Firmen gibt, denen das noch nicht gesagt worden ist. Die setzen immer noch OOP ein, und manche von diesen Firmen sind noch nicht einmal pleite..

Ich muss mich hier korrigieren: Die Klassische OOP ist verboten.... oder wird nicht mehr dort eingesetzt... einige diese Firmen kenne wir alle und sie nicht Pleite... Belege habe ich dafür jetzt keine...
Gebe ich zu...
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6827
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon Timm Thaler » 14. Jan 2019, 18:39 Re: OOP gilt als gescheitert

pluto hat geschrieben:sagen wir, es ist Speicher Verschwendung...


Ist das so? Werden Objekteigenschaften, auf die ich nicht zugreife, in die Exe mit einkompiliert?
Timm Thaler
 
Beiträge: 779
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 m.fuchs » 14. Jan 2019, 18:40 Re: OOP gilt als gescheitert

pluto hat geschrieben:
Das ist immer noch kein praktisches Beispiel, sondern nur die Beschreibung von ein paar Properties. Was wäre denn die konkrete Aufgabestellung?

OK. Stellen wir uns vor, wir haben ein Quadrat und ein Rechteck. Die wollen wir nun in der OOP beschreiben.
Mit Hilfe eine Basis Klasse... Was haben diese beiden Formen Gemeinsam?

Das kommt auf den Anwendungsfall an. Ein Beispiel habe ich gegeben.

pluto hat geschrieben:
Dann baue ich mir ein TGeometrischesGebilde mit den beiden abstrakten Funktionen BerechneUmfang und BerechneFlaeche. Dann leite ich fröhlich alle meine Gebilde von dieser Basisklasse ab.
Und die erhalten dann notwendige Eigenschaften (TRechteck bekommt zwei Seiten, TQuadrat nur eine, TKreis hat einen Radius) und implementieren alle diese beiden Funktionen. Voilà: OOP.

was ist wenn du alle Klassen mit einer Breite und einer Höhe beschreiben möchtest?
Dann hast du eine Breite und Höhe beim Quadrat, obwohl das hier gar nicht gebraucht wird.?

Dann habe ich wohl etwas falsch gemacht. Wenn ich etwas konsequent falsch machen möchte, dann wird es auch falsch. Das ist überall so.

pluto hat geschrieben:Architektur: grob kann ich dazu folgendes sagen:
es gibt eine Statische Struktur und eine Dynamische Struktur. Die Dynamische Struktur ist dabei deutlich Komplexer und wird häufiger neu aufgebaut z.b. bei einer Fenster Größen Änderung

Das ist keine Architektur. Und ich glaube damit (und den anderen Antworten) ist schon ein mögliches Problem gefunden. Entwicklung ist deutlich mehr als nur Programmieren. Insbesondere bei komplexen System.

pluto hat geschrieben:
Das ist aber nur deine persönliche Sichtweise. Ich benötigt onClick im Label schon häufiger.

TLabel soll aber nur ein Text anzeigen...

Falsch. Du möchtest gerne, dass TLabel nur einen Text anzeigt. Ist aber eben nur deine Meinung.

pluto hat geschrieben:
So ein großes Framework ist sicherlich erst einmal gewöhnungsbedürftig. Aber es deckt auch echt sehr viel ab.

Klar, dass ist teil des Problems. Ist deckt viel zu viel ab.

Dann benutze es nicht, wenn es dir zu mächtig ist.

pluto hat geschrieben:
Du kannst auch einfach alles von Hand machen, eigene Objekte erstellen die nur die von dir nötigen Methoden haben. Oder einfach direkt nur auf den Bildschirm zeichnen.

Da fangen die Problem an... Den Ansatz habe ich auch schon Verfolgt. Und habe direkt auf TCanvas gesetzt...
Aber dann brauche ich immer noch eine LCL Komponente, um es anzeigen zu können, so wie in GLScene zum Beispiel.

Du kannst auch direkt mit dem Win32/GTK/QT/sonstewas kommunizieren und darüber zeichnen. Oder direkt mit der Grafikkarte.

pluto hat geschrieben:
Da gibt es drei Dinge die das verhindern können: Unittests, Unittests, Unittests.

und dann hast du dort ein Fehler drin, den du nicht sofort siehst... und dann? Und du hast doppelte arbeit...

Ohje, dann hör einfach auf zu programmieren, dann geht auch nix schief. :wink:
Es kann immer etwas sein und alle machen Fehler. Es gibt keine perfekten System und man kann nie alle Eventualitäten voraussehen.
Mit guter Planung kann man eine Menge Sorgen schon vorher loswerden.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de
m.fuchs
 
Beiträge: 2000
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 » 14. Jan 2019, 18:43 Re: OOP gilt als gescheitert

braunbär hat geschrieben:
m.fuchs hat geschrieben:Du spielst vermutlich auf die Advanced Records an. Warum auch immer die erfunden worden: sie sind nicht nur Records sondern Klassen/Objekte.

Ja, der Grund ist wohl, dass Klassen immer im Heap liegen, dass man sich aber Konstrukte, in denen Daten und Methoden gemeinsam gekapselt sind, durchaus auch statisch bzw. im Stack wünschen kann.

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.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de
m.fuchs
 
Beiträge: 2000
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 » 14. Jan 2019, 18:51 Re: OOP gilt als gescheitert

pluto hat geschrieben:https://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html

Viele Zitate von berühmten Menschen, die sich kritisch mit OOP auseinandersetzen. Insbesondere mit bestimmten Implementationen von OOP.
Kein "OOP ist tot!"

pluto hat geschrieben:https://www.leaseweb.com/labs/2015/08/object-oriented-programming-is-exceptionally-bad/

Artikel der sich kritisch mit OOP auseinandersetzt und zum nachdenken vor dem Programmieren anregt.
Kein "OOP ist tot!"

pluto hat geschrieben:https://content.pivotal.io/blog/all-evidence-points-to-oop-being-bullshit

Artikel darüber dass OOP (aus Sicht des Autors) Riesenmist ist.
Kein "OOP ist tot!"

pluto hat geschrieben:https://de.wikipedia.org/wiki/Kreis-Ellipse-Problem

Ähnliches Problem wie mit Rechteck und Quadrat. Und ein wichtiger Satz aus der Bewertung des Problems:
"Es lässt sich nicht unabhängig vom konkreten Anwendungsfall festlegen, ob Kreis sich als Spezialisierung von Ellipse eignet oder nicht."
Genau was ich oben schon sagte.
Kein "OOP ist tot!"


So, hast du sonst noch etwas hinzuzufügen? Belege habe ich noch immer keine gesehen.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de
m.fuchs
 
Beiträge: 2000
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 » 14. Jan 2019, 18:54 Re: Die Klassische OOP gilt als gescheitert

Ist das so? Werden Objekteigenschaften, auf die ich nicht zugreife, in die Exe mit einkompiliert?

Ich bin immer davon ausgegangen, dass es so ist...

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

Falsch. Du möchtest gerne, dass TLabel nur einen Text anzeigt. Ist aber eben nur deine Meinung.

Stimmt natürlich...

Ohje, dann hör einfach auf zu programmieren, dann geht auch nix schief.

Ne, ich lass einfach die Unittest weg.... dann habe ich auch eine Fehler quelle weniger....

Mit guter Planung kann man eine Menge Sorgen schon vorher loswerden.

Das stimmt natürlich...

So, hast du sonst noch etwas hinzuzufügen? Belege habe ich noch immer keine gesehen.

Nein mehr habe ich bisher nicht...

Aber ich habe ja schon den Titel geändert und auch mein ersten Beitrag... Es ist falsch zu behaupten(was ich gemacht habe) das die OOP gescheitert ist, aber die Klassische OOP ist gescheitert in der Form...
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6827
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

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

pluto hat geschrieben:Ne, ich lass einfach die Unittest weg.... dann habe ich auch eine Fehler quelle weniger....

Entschuldige bitte, aber entweder willst du trollen (was ich mir bei dir einfach nicht vorstellen kann) oder du weißt nicht wovon du redest.
Du hast keine Fehlerquelle weniger.
Eine Analogie zu deiner Aussage wäre: "Ich gehe nicht zum TÜV, weil der Prüfer das Formular falsch ausfüllen könnte. So ist mein Auto sicherer."

pluto hat geschrieben:Aber ich habe ja schon den Titel geändert und auch mein ersten Beitrag... Es ist falsch zu behaupten(was ich gemacht habe) das die OOP gescheitert ist, aber die Klassische OOP ist gescheitert in der Form...

Das macht es nicht besser.
Software, Bibliotheken, Vorträge und mehr: https://www.ypa-software.de
m.fuchs
 
Beiträge: 2000
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 » 14. Jan 2019, 19:34 Re: Die Klassische OOP gilt als gescheitert

Entschuldige bitte, aber entweder willst du trollen (was ich mir bei dir einfach nicht vorstellen kann) oder du weißt nicht wovon du redest.

Ich möchte nicht trollen.... aber bei Unittest sehe ich einfach keine Vorteile...
aber das wäre was für ein neuen Thread...

Du hast keine Fehlerquelle weniger.
Eine Analogie zu deiner Aussage wäre: "Ich gehe nicht zum TÜV, weil der Prüfer das Formular falsch ausfüllen könnte. So ist mein Auto sicherer."

Hier habe ich ja keine Wahl, wenn ich ein Auto hätte und es nutzen möchte, MUSS ich ja zum TÜV und hier sind auch andere Leute am Werk, die das Auto Prüfen. Ich prüfe das Auto ja nicht selbst, aber den Unit test würde ich ja selbst schreiben.

So, jetzt wird es Kompliziert... Der vom Verein hat mir folgendes geschrieben:
Es geht mehr um Polymorphie und nicht gerade um OOP.

In der 90er hat man behauptet, dass Polymorphie sehr wichtig ist. Die
ganze OOP in Java, Pascal, C++ ist für Polymorphie entwickelt. Leider
kann man jetzt ganz gut sehen, dass die Polymorphie kaum verwendet wird
und zu viele Nachteile bringt.

https://i.warosu.org/data/g/img/0561/69 ... 063651.png

Viele moderne Sprachen unterstützen "klassische" OOP, weil die Leute
dazu gewohnt sind. Die wichtigsten Konzepten haben aber mit OOP nichts
zu tun. In C++11 ist das Wort `class` oft nicht für OOP verwendet,
sondern um FP oder ADT zu simulieren (zusammen mit `template`).

Grundsätzlich braucht man das Wort `class` gar nicht. (In manchen
Programmiersprachen wie z.B. Haskell hat dieses Wort ganz andere
Bedeutung).

Es geht um Mathematik.

Die Datentypen in der Programmiersprache müssen bestimmte mathematische
Eigenschaften haben. Wenn nicht, wird die Sprache entweder nicht
eindeutig oder widerspricht sich selbst, was nicht zulässig ist.

Die Möglichkeit, die Funktionen in der Klasse zu überladen, führt dazu,
dass viele andere Möglichkeiten verboten werden. Das war in der 90er
noch nicht bekannt.

In OOP hat jede Methode der Klasse immer Seiteneffekten, als die auch
Zugriff zu dem Objekt automatisch hat. Das widerspricht sehr wichtige
Konzept von "reiner Funktion" ("pure function"): eine Funktion, die für
gleiche Parameter immer den gleichen Wert liefert. Solche Funktion hat
keine Zustandsvariablen, die während einer Berechnung geändert werden.

Beispiel:

int foo(int a, int b) {
return a + b;
}

Diese Funktion ist rein, als `foo(2, 2)` immer 4 ist. Es ist egal, ob
wir die nur einmal oder mehrmals aufrufen.

int state = 0;

int bar(int x) {
state += x;
return state;
}

Und diese Funktion ist nicht rein.

Reine Funktionen sind sehr wichtig, als man die beliebig kombinieren
darf. Die Reihenfolge der Aufrufe ist nicht wichtig. Moderne
Programmiersprachen sind sehr gut geeignet, um reine Funktionen zu
schreiben. Sogar in C++ ist das möglich. Dazu muss man aber auf
`virtual`, `override`, `abstract` usw. verzichten, und in Pascal heißt
das, das man in solchem Programm keine OOP haben darf.

Noch wichtig ist https://de.wikipedia.org/wiki/Typinferenz


Leider kann man sich ja nicht mehr Neu anmelden, sonst würde ich ihm Vorschlagen sich hier einfach mit einzuklinken... um selbst belege und beweise zu liefern. Das wäre bestimmt Interessant...

Ich möchte jetzt nicht 100% belegen das ICH recht habe oder der bekannte vom Verein, ich möchte aber auch nicht, dass es so einfach als unwahr abstempelt wird...
Jeder der sich an etwas gewöhnt hat, möchte es Ungere aufgeben... da bin ich nicht anders...
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6827
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon pluto » 14. Jan 2019, 19:38 Re: Die Klassische OOP gilt als gescheitert

Nachtrag vom bekannten vom Verein,
> Kein "OOP ist tot!"

OOP ist nicht tot. OOP ist nur nicht weiter entwickelt als Theorie, und
alle neue Erfindungen in der Theorie der Programmiersprachen haben mit
OOP nichts zu tun. Viele moderne Programmiersprachen verzichten auf
direkte Unterstützung von OOP, als die einfach nichts bringt, wenn die
Sprache bereits gutes Typensystem mit ADT und Unterstützung der FP hat.

Die "richtige" Programmierung ist auf Kategorientheorie basiert. Das
ist der OOP ähnlich, aber nicht gleich. OOP ist nur für (relativ
seltene) Fälle geeignet, wenn OOP und KT "zufällig" gleiche Ergebnisse
bringen. Klasse in der Kategorientheorie ist der Klasse in OOP ähnlich,
aber nicht gleich. Beispiel: Haskell.
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6827
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon Timm Thaler » 14. Jan 2019, 21:43 Re: OOP gilt als gescheitert

m.fuchs hat geschrieben:Falsch. Du möchtest gerne, dass TLabel nur einen Text anzeigt. Ist aber eben nur deine Meinung.


Ich hätte jetzt gesagt: Genau das macht es auch, denn ein OnClick Event auf Labels gibts es unter Windows eh nicht.

Also hab ich es mal ausprobiert: Es gibt ein OnClick Event auf Labels unter Windows. Wozu auch immer das gut ist?

Was beweist: Man kann alt wer'n wie ne Kuh und lernt doch immer noch dazu.
Timm Thaler
 
Beiträge: 779
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 sstvmaster » 14. Jan 2019, 22:03 Re: OOP gilt als gescheitert

Timm Thaler hat geschrieben:Also hab ich es mal ausprobiert: Es gibt ein OnClick Event auf Labels unter Windows. Wozu auch immer das gut ist?


URL Link, Hilfe Fenster, ...?
Zuletzt geändert von m.fuchs am 14. Jan 2019, 22:26, insgesamt 1-mal geändert.
Grund: Zitat korrekt zugeordnet
OS: Windows 7 32/64bit
Lazarus 1.8.4, 32bit
Lazarus 2.1.0 Trunk 3.3.1, 32bit
sstvmaster
 
Beiträge: 105
Registriert: 22. Okt 2016, 22:12
OS, Lazarus, FPC: Lazarus 2.0 RC3 + 2.1.0 Trunk 3.3.1 / Win32, Windows 7 32+64bit | 
CPU-Target: 32Bit
Nach oben

Beitragvon pluto » 14. Jan 2019, 22:37 Re: Die Klassische OOP gilt als gescheitert

Was beweist: Man kann alt wer'n wie ne Kuh und lernt doch immer noch dazu.

Eine Kuh heute zu Tage wird auch nicht mehr so alt wie früher...

URL Link, Hilfe Fenster, ...?

Rate mal wofür es Buttons gibt...
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6827
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

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

Zurück zu Allgemeines



Wer ist online?

Mitglieder in diesem Forum: Niesi und 0 Gäste

porpoises-institution
accuracy-worried