Interessante Sicht auf die PLO
Das ist kein Problem der OOP, sondern ihrer Anwendung, und noch mehr derjenigen, die sie anwenden. Sie sind diejenigen, die das Gefühl haben...
Enthusiasmus, ja sogar Ekstase, dass man mit Hilfe von OOP unglaublich viel schreiben kann
unglaublich komplizierten Code (und konkurrieren sogar darin :). Sie halten sich für eine besondere Elite.
Sie haben sogar ihr eigenes "großes Buch" erfunden, das sie lesen und lesen und lesen, aber nicht lesen können.
aber sie können es nicht lesen. Es heißt "Design Patterns" - in menschlicher Sprache
heißt übersetzt "Die ultimative Kunst des Schreibens von unscharfem, verwirrendem und verwirrendem Code". Wenn aber.
das ist eine sehr, sehr coole Sache, die unglaublich vereinfacht und
vereinfacht und vereinfacht das Leben.
Na bitte, schon immer vermutet)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Sie sollten sich darüber im Klaren sein, dass solche Artikel höchstwahrscheinlich von Leuten geschrieben werden, die mit dem RP und seinen verwirrenden Haken, die 20 Tabs umfassen können, nicht vertraut sind....
Harte FP ist etwas anderes. Dann fängt man an, über Lakonismus und Bequemlichkeit von OOP nachzudenken, man kann einen Teil der Funktionalität im Voraus deklarieren und so weiter..... Im Grunde genommen die Ähnlichkeit des einen mit dem anderen. Das ist nur solche Artikel sind oft von Menschen, die nur prozeduralen Code gemeistert haben geschrieben - und das ist nicht einmal in der Nähe von FP, so dass, wenn Sie nicht wissen, was die Haken und lebendige Nutzung von ihm, kein FP ist aus der Frage
Auch viele der in dem Artikel aufgeführten "sterbendenSprachen" unterstützen die volle Funktionalität von FP und OOP, warum sollten sie sterben? und einige von ihnen sind die bestbezahltenin der GUSEs geht eher um die "Spaghettifizierung" in OOP, ohne überhaupt an ein "Ertrinken" in FP zu denken. Meiner Meinung nach ist das prozedurale Paradigma realistisch und ressourcenschonender als OOP.
nur, dass der Code selbst auf oop länger ist? nun, ja, es gibt einen Konstruktor, und in einigen Fällen ist der Code darauf normalerweise länger.... Technisch gesehen sollte der Einsatz von FP effizienter für die Erzeugung von Maschinencode sein.... aber der Code wird dadurch nicht einfacher und es ist unmöglich, normale Wrapper zu erstellen, was die Eingabe betrifft...
Heutzutage findet man oft eine Mischung aus dem einen und dem anderen - die Wege kommen sich nicht in die Quere
nur, dass der Code selbst auf oop länger ist? nun, ja, es gibt einen Konstruktor, und in einigen Fällen ist der Code darauf normalerweise länger.... Technisch gesehen sollte der Einsatz von FP effizienter für die Erzeugung von Maschinencode sein.... aber der Code wird dadurch nicht einfacher und es ist unmöglich, normale Wrapper zu erstellen, was die Eingabe betrifft...
Heutzutage kann man oft eine Mischung aus dem einen und dem anderen sehen.
Ohne OOP und FP funktioniert alles einfacher und schneller (ja, ohne "Schönheiten", Panels usw.), aber es ist manchmal schwierig, selbst den eigenen Code zu verstehen)
Ohne OOP und FP funktioniert alles einfacher und schneller (ja, ohne "Schönheiten", Panels usw.), aber es ist manchmal schwierig, selbst den eigenen Code zu verstehen).
Beherrschen Sie zuerst das eine oder das andere, oder besser beides, und entscheiden Sie dann, was Sie bevorzugen. Und mit einer solchen Herangehensweise wie jetzt werden Sie sich mit der Zeit in Fedoseev verwandeln, der allem zustimmt, was Sie nicht verstehen (d.h. fast allem).
Das ist eine destruktive Reaktion auf das Thema und eine destruktive Diskussion. Sagen Sie mir als Anhänger der prozeduralen Programmierung, wie man die "Spaghettisierung" in OOP vermeidet, wie man parst und ob es sinnvoll ist, die "Spaghetti" eines anderen zu verwenden?
Schließlich dient OOP vor allem der Lesbarkeit und der Programmierung im Team, d.h. für große Projekte. Ein Expert Advisor, der ein Symbol zu seinem Diagramm mit der Kontrolle des maximalen Risikos des Gleichgewichts / Fonds auf dem Konto handelt, gut, kann nicht ein großes Projekt genannt werden - es ist ausreichend und profitabler in Speicher / Geschwindigkeit - prozedurale Programmierung.
Fragen:
- Nachteile/Vorteile von OOP (als Imperativ) aus persönlicher Erfahrung
- Nachteile/Vorteile von FP (als deklarativ) aus persönlicher Erfahrung.
Und eine Meinung zu den Aussichten ist natürlich interessant, vor allem in Richtung paralleles Rechnen. Ich sehe keinen Sinn darin, das Thema Quantum zu berühren.
Sagen Sie mir als prozeduralem Programmierer, wie man "Spaghettisierung" in OOP vermeiden kann
Das Rezept ist in dem zitierten Artikel angegeben: Bemühen Sie sich, deterministische Funktionen zu schreiben.
Wie demontiert man und ist es sinnvoll, die "Spaghetti" von jemand anderem zu verwenden?
Guter Code, ja, aber kein Spaghetti.
Schließlich ist OOP vor allem für die Lesbarkeit und die Programmierung im Team, d.h. für große Projekte, gedacht.
Richtig.
Ein EA, der mit einem Symbol auf einem Chart handelt, dem er mit maximaler Risikokontrolle des Kontostandes/Kontoguthabens beigefügt ist, kann nicht als großes Projekt bezeichnet werden - daher ist die prozedurale Programmierung ausreichend und profitabler in Bezug auf Speicher/Geschwindigkeit.
Um nach Australien zu reisen, ist es bequemer, ein Flugzeug zu benutzen (OOP), um in eine benachbarte Stadt zu reisen, genügt ein Auto oder sogar ein Fahrrad (PP). Man muss nur das bequemere Mittel wählen, um das Ziel zu erreichen.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Na bitte, schon immer vermutet)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23