Gespräche über die PLO in der Lounge - Seite 11

 
Andrei:

Die Anzahl der Gesten in OOP kann im Prinzip nicht geringer sein, da alle diese Schnittstellen zusätzlichen Overhead bedeuten, der oft die Kosten für das Schreiben der Logik selbst übersteigt. Und dies, obwohl jede Funktion bereits eine Schnittstelle hat, d.h. es wird vorgeschlagen, einen weiteren Garten zu bauen, der im Grunde genommen sinnlos ist.

Gleichzeitig wird jede Änderung des Codes, sowohl in der Schnittstelle als auch in der Funktion, viel komplizierter, da das eine vom anderen abhängt, was bedeutet, dass die Zahl der möglichen Fehler und die Arbeitsintensität mindestens quadratisch ansteigen... Das ist doch irgendwie offensichtlich, oder?

Das Terminal ist eine Klasse im Verhältnis zu Ihrem Code. Wie oft müssen Sie etwas im Terminalcode ändern, der vor Ihnen verborgen ist und nur mit öffentlichen Methoden versehen ist - Funktionen zur Implementierung Ihrer Programme.
 
Andrei:

Die Anzahl der Gesten in OOP kann im Prinzip nicht geringer sein, da alle diese Schnittstellen zusätzlichen Overhead bedeuten, der oft die Kosten für das Schreiben der Logik selbst übersteigt. Und das, obwohl jede Funktion bereits eine Schnittstelle hat, d. h. wir müssen noch eine weitere Absicherung vornehmen, die im Grunde nutzlos ist.

In diesem Fall wird jede Änderung des Codes sowohl in der Schnittstelle als auch in der Funktion viel komplizierter, da das eine vom anderen abhängt, d.h. wir haben mindestens eine quadratische Zunahme möglicher Fehler und des Arbeitsaufwands... Das ist doch irgendwie offensichtlich, oder?

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Reden über OOP im Hinterhof

fxsaber, 2018.01.14 11:35

Die Programmierung selbst ist ein Spezialfall der Produktion. Der OOP-Ansatz ist ein prinzipieller Ansatz für die Entwicklung von allem. Es ist also sehr eng, von Programmierung zu sprechen. OOP wurde erfolgreich angewandt, BEVOR es in der Programmierung auftauchte.

Die Industriegeschichte kam zur objektorientierten PRODUKTION als nächste Stufe der Fördertechnik. Von OO-Programmierung zu sprechen, ist also eine enge Sichtweise. Als würde man über OO-Nähstiefel sprechen. Wir sprechen von algorithmischen Ansätzen für die Organisation jeglicher Produktion, einschließlich - und das ist ein sehr spezieller Fall - der Erstellung von Software.


Die OOP-Produktion hat sich im Vergleich zu herkömmlichen Montagelinien als wettbewerbsfähig erwiesen. Es gibt eine kurzfristige Planung der Produktion, wenn es notwendig ist, sie jetzt zum Laufen zu bringen. Und es gibt eine langfristige Perspektive - wenn man im Moment viele "Extras" anlegt, aber diese Grundlage ist förderlich, um die Produktion einfach zu steigern. Auch hier geht es nicht um die Programmierung, sondern um allgemeine Ansätze für die Produktion.


OOP-Ansätze sind auch in modernen Institutionen der Macht zu finden.

 
Artyom Trishkin:
Das Terminal ist eine Klasse im Verhältnis zu Ihrem Code. Wie oft müssen Sie etwas am Terminalcode ändern?

Dieses Beispiel ist falsch. Wir sprechen hier von Schnittstellen innerhalb Ihres Programms...

 
fxsaber:

Die Industriegeschichte kam zur objektorientierten PRODUKTION als nächstem Schritt der Fördertechnik.

Die OO-Programmierung hat auch ihre Verarbeitungspipelines, und OOP führt eine weitere Abstraktionsebene ein, die nur den Overhead jedes einzelnen Förderers und der gesamten Produktion erhöht.

 
Andrei:

Die OO-Programmierung hat auch ihre eigenen Verarbeitungsbänder, und OOP führt eine weitere Abstraktionsebene ein, die nur den Overhead jedes einzelnen Bandes und der gesamten Produktion erhöht.

Sie sind leider dumm. Man erfährt etwas über die Geschichte der Industrie und über OOP als eine der Etappen in dieser Geschichte, die eine große Rolle bei allen materiellen (und nicht nur) Dingen um einen herum gespielt hat. Und Sie sprechen immer wieder von einem Sonderfall der Programmierung.

Unkenntnis der Geschichte der menschlichen Entwicklung. Sie werden in der Erinnerung Ihrer direkten Nachkommen keine Spuren hinterlassen.

 
fxsaber:

Man erfährt etwas über die Geschichte der Industrie und über das OOP als eine Etappe in dieser Geschichte, die eine große Rolle bei allen materiellen (und nicht nur) Dingen um einen herum gespielt hat.

Ihr naiver Versuch, die PLO in die Geschichte der Industrie hineinzuziehen, ist amüsant, aber leider ungebildet.

 
Andrei:

Dieses Beispiel ist falsch. Wir sprechen hier von Schnittstellen innerhalb Ihres Programms...

Warum ist sie "falsch"?

Wie unterscheidet sich ein Programm von ALLER Software, die auf einem Computer läuft?

Schließlich handelt es sich um dieselbe Reihe von Anweisungen und Datensätzen wie in jedem Benutzerprogramm. Warum ist es falsch, dass hier oder dort ein Teil der Software keinen Zugang zu einem anderen Teil der Software hat, außer über etablierte Austauschprotokolle?


Es ist in Ordnung, wenn Sie ernsthaft programmieren - früher oder später werden Sie auf die Notwendigkeit einer Differenzierung der Zugriffsrechte stoßen.

Auch ich habe es damals, als ich vom echten in den sicheren Modus wechselte, gehasst, dass ich auf keine physische Speicheradresse zugreifen konnte. Ich habe sogar mit einem DMA-Controller herumgedreht, der Daten aus dem geschützten Systembereich in meinen kopiert hat (obwohl es ziemlich schwierig war, herauszufinden, was dort kopiert wurde, also habe ich es nicht getan). In meiner Jugend war ich empört - wie konnte ich keinen direkten Zugriff haben - es war fast eine Verletzung meiner Rechte... Und in dem Programm, damit ich keinen Zugang zu etwas habe?

Nun, da ich Erfahrungen sammle, habe ich oft festgestellt, dass die Differenzierung der Zugriffsrechte ein Segen für den Programmierer selbst ist, weil sie mich oft vor Fehlern in geschriebenen Modulen bewahrt hat. Sie nehmen eine Klasse, wollen sie benutzen, und sie hat keinen Zugriff auf einige Daten... Sie sind entrüstet, wie kann das sein, Sie fangen an, der Sache nachzugehen... und hoppla... Es gibt Dinge, die berücksichtigt werden müssen, und auf die Daten kann nicht direkt zugegriffen werden, es gibt "indirekte Wege", die Systemarchitektur ist so beschaffen, dass ich möglicherweise ungültige Daten erhalte, wenn ich direkt auf sie zugreife. Ich kann aber auch gültige Daten erhalten - es kommt auf den Zeitpunkt an. Und ein solcher Fehler ist sehr schwer zu erkennen.

Hier ist das einfachste Problem der Zugriff auf Daten in einem Cache. Wenn Sie zwischengespeicherte Daten benötigen und direkt darauf zugreifen - sind Sie dann sicher, dass Sie die richtigen Daten erhalten? Bei einem verfahrenstechnischen Ansatz ohne Differenzierung muss man wissen, wann man ihn verwenden kann und wann nicht, wann Daten gültig sind und wann nicht... Im OOP-Ansatz ist alles sehr einfach, Sie haben keinen Zugriff auf Cache-Daten, Sie können nur eine Funktion aufrufen, die die erforderlichen Daten zurückgibt, und wenn sie ungültig ist, holt sie gültige Daten. Ist er "komplizierter"? Stellen Sie sich nun vor, dass Sie diesen Cache ein Jahr nach dem Schreiben verwenden. Wenn Sie die Grundsätze der Cache-Aktualisierung und der Gültigkeitsdefinition völlig vergessen haben. Bei der OOP-Methode ist das nicht der Fall. Die Klassenfunktion wird Sie mit allem versorgen. Beim funktionalen Ansatz muss man sich jedoch im Detail merken, wann und wie der Cache aktualisiert wird, wann die Daten darin gültig sind und wann nicht.

 
Andrei:

Dieses Beispiel ist falsch. Wir sprechen hier von Schnittstellen innerhalb Ihres Programms...

Richtiger kann es nicht sein - es ist eine Hierarchie.
Ihr Programm mit dem OOP-Ansatz sieht die öffentlichen Methoden der Klasse, und Sie verwenden sie, ohne über ihre Komponenten nachzudenken. Genauso wie Sie die Funktionen der Standardsprache verwenden. Sie brauchen die Klasse nicht zu ändern, wenn Sie das Programm ändern. Genauso wie man die Standardfunktionen der Sprache nicht zu ändern braucht, wenn man den prozeduralen Ansatz verwendet.
 
Artyom Trishkin:
Das Terminal ist eine Klasse im Verhältnis zu Ihrem Code. Wie oft müssen Sie etwas im Terminalcode ändern, der vor Ihnen verborgen ist und nur mit öffentlichen Methoden - Funktionen zur Implementierung Ihrer Programme - versehen ist.

+++ )))

 
Artyom Trishkin:
Das Terminal ist eine Klasse im Verhältnis zu Ihrem Code. Wie oft müssen Sie etwas im Terminalcode ändern, das vor Ihnen verborgen ist, und es werden nur öffentliche Methoden - Funktionen für die Implementierung Ihrer Programme bereitgestellt.

Ein solcher Bedarf entsteht regelmäßig. Es ist nur wünschenswert, dass die Entwickler dies tun.

Ein einfaches Beispiel. Aus irgendeinem Grund hielten es die Entwickler nicht für notwendig, ein horizontales Koordinatengitter für Indikatordiagramme bereitzustellen. Und natürlich haben sie keine geeignete Methode dafür vorgesehen).

Grund der Beschwerde: