Gemeinkosten für die PLO - Seite 6
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
aber es funktioniert nicht :-)
Ich sage Ihnen - versuchen Sie es, es ist ein heftiger Code. Instantifiable Klasse "CFoo: public InterfaceCFoo" muss InterfaceCFoo *privateContext Feld enthalten (1:1 Beziehung herstellen), es über Factory erstellen und löschen, alle Methoden delegieren und CFoo* Referenzen this<->privateContext hier und dort übersetzen. Das ist "Sonnenuntergang von Hand", d.h. Ersetzung der Vererbung durch Delegation, und zwar an Ort und Stelle.
Erstellen Sie sie über die Fabrik und löschen Sie sie auf die übliche Weise. Ob Sie eine Delegation benötigen, hängt davon ab, wie der Inhalt der Bibliothek verwendet werden soll: Wenn die Bibliothek Klassen bereitstellt, die die Arbeit selbst erledigen, brauchen Sie nichts zu delegieren - rufen Sie einfach die Schnittstellenmethoden auf.
Übrigens, in Android/Java gibt es eine ähnliche Sache mit Kernel-Klassen - mangels Mehrfachvererbung muss man einen Delegaten in das Objekt einfügen und Wrapper-Methoden für seine Methoden erstellen. C'est la vie.
Ich sage Ihnen - probieren Sie es aus, es ist eine heftige Menge an Code. Instantifiable Klasse "CFoo: public InterfaceCFoo" muss InterfaceCFoo *privateContext Feld enthalten (1:1 Beziehung herstellen), es über Factory erstellen und löschen, alle Methoden delegieren und gleichzeitig CFoo* Referenzen this<->privateContext hier und dort übersetzen. Das ist "Sonnenuntergang von Hand", d.h. Ersetzung der Vererbung durch Delegation, und zwar an Ort und Stelle.
Und die Sprache, ein nüchterner Mensch kann ohne einen halben Liter nicht verstehen, worüber wir reden. :) Und dieses ganze OOP-Zeug und diese ganze chinesische Alphabetisierung ist dazu da, um einen einfachen Datenaustausch zu ermöglichen, der auf prozeduraler Ebene trivial zu realisieren ist...
OOP selbst ist nicht schuld daran, dass es bösartige OOP-Programmierer gibt. Gegen OOP im Allgemeinen ist nichts einzuwenden, Sie liegen mit Ihrer Meinung über OOP völlig falsch.
OOP selbst ist nicht schuld daran, dass es bösartige OOP-Programmierer gibt. Gegen OOP im Allgemeinen ist nichts einzuwenden, Sie liegen mit Ihrer Meinung über OOP völlig falsch.
Du kennst seine Geschichte nicht.
Wiederholte Verbote wegen direkter Sabotage. Reagieren Sie also nicht auf seine angriffslustige Ignoranz.
Im Allgemeinen ist an OOP nichts auszusetzen; Sie liegen mit Ihrer Meinung über OOP völlig falsch.
Ich werde Ihnen einige berühmte kritische Zitate aus dem Wiki über OOP von Leuten geben, die aus irgendeinem Grund nicht als ignorant bezeichnet werden:
Als Befreiung werde ich einige berühmte kritische Zitate aus dem Wiki über OOP von Leuten anführen, die aus irgendeinem Grund nicht als ignorant bezeichnet werden:
Und alle drei: Stepanov, geboren 1950, Wirth, geboren 1934, und der ebenso alte Killea (sein Buch wurde 1998 veröffentlicht) werden sich schämen, dies 2017 zu wiederholen.
Was sie gesagt haben, ist so lange her, dass es schon peinlich ist, sich daran zu erinnern. C++-Compiler waren um mindestens 2 Größenordnungen dümmer und primitiver in der Optimierung. In der Tat war von Optimierung keine Spur. Damals (ganz am Anfang der neunziger Jahre) habe ich selbst viel Assembler geschrieben und dachte ähnlich: "C/C++ ist langsam".
Es steht mir nicht zu, Links in Form von gerupften Zitaten zu führen. Außerdem haben Sie in diesem Thread bereits Ihre extreme Dumpfheit und aggressive Ignoranz unter Beweis gestellt.
Renat Fatkhullin:
Umso mehr haben Sie es bereits in diesem Thread geschafft, Ihre extreme Dumpfheit und aggressive Ignoranz zu zeigen.
Lassen Sie uns zusammenfassen. Hier ist meine Haupthypothese über OOP: "OOP macht nur Sinn als bequeme Textumhüllung oder bei minimaler Verwendung während der Laufzeitinitialisierung..." in Beitrag #10.
Und hier ist eine begründete Stellungnahme eines unabhängigen Experten mit einer ähnlichen Meinung und detaillierten Beweisen auf Code-Ebene.
http://rainman-rocks.livejournal.com/122876.html
"Die endgültige Schlussfolgerung aus all dem ist diese:
Der Hauptgrund für die Effektivität der objektorientierten Programmierung liegt darin, dass sie die Möglichkeit bietet, Modularität und Deklarativität zu gewährleisten. Modularität und Deklarativität sind die Werkzeuge, die die Effizienz der Entwicklung steigern - also "wie silberne Kugeln". Auf diese sollte man sich bei der Wahl einer Methode konzentrieren. OOP allein sollte nicht das Ziel sein."
Zusammengefasst. Hier ist meine grundlegende Hypothese über OOP: "OOP macht nur Sinn als bequeme Textumhüllung oder bei minimaler Verwendung in der Laufzeitinitialisierung..." in Beitrag #10.
Und hier ist eine begründete Stellungnahme eines unabhängigen Experten mit einer ähnlichen Meinung und detaillierten Beweisen auf Code-Ebene.
http://rainman-rocks.livejournal.com/122876.html
"Die endgültige Schlussfolgerung aus all dem ist diese:
Der Hauptgrund für die Effektivität der objektorientierten Programmierung liegt darin, dass sie die Möglichkeit bietet, Modularität und Deklarativität zu gewährleisten. Modularität und Deklarativität sind die Werkzeuge, die die Effizienz der Entwicklung steigern - also "wie silberne Kugeln". Auf diese sollte man sich bei der Wahl einer Methode konzentrieren. OOP an sich sollte nicht das Ziel sein."
Zeigen Sie Ihre persönlich durchgeführten Projekte, damit Ihre Meinung wenigstens ein bisschen akzeptiert wird. Sie können nicht einmal den zitierten Link verstehen - es ist nur eine Ode an OOP, einschließlich der Ausgabe.
Alle Software wird praktisch zu mehr als 90 % auf der Grundlage von OOP geschrieben (von den Treibern ganz zu schweigen). In der Tat ist es unmöglich, ein großes Projekt ohne OOP zu schreiben und dann zu pflegen. Und wenn es um das Geschäft geht, wird kein Wort über "nur eine Verpackung" akzeptiert. Die Softwareentwicklung ist seit langem ein etabliertes und bewährtes Geschäft.
Diejenigen, die sich über OOP beschweren, ohne etwas zu verstehen, wissen nicht, was moderne C++-Compiler tun. Von OOP ist im endgültigen Code oft überhaupt nichts mehr übrig. Ich spreche natürlich von C++.
Zeigen Sie Ihre persönlich realisierten Projekte, damit Ihre Meinung wenigstens ansatzweise akzeptiert wird. Sie können nicht einmal den zitierten Link verstehen - er ist nur eine Ode an OOP, einschließlich der Schlussfolgerung.
Lassen Sie mich noch einmal den Hauptgedanken dieses Artikels zitieren, damit kein Zweifel daran besteht, was er aussagt:
"Während OOP also versuchte, die strukturiert-prozedurale Programmierung zu ersetzen, kehrte sie schließlich zu fast derselben Sache zurück, nur in einer ausgefallenen Verkleidung. Es stellt sich die Frage, ob das Manöver überhaupt einen Sinn hatte...".
Entschuldigung, aber ich verstehe die Logik und den kausalen Zusammenhang nicht - warum braucht man irgendwelche realisierten Projekte, damit die eigene Meinung minimal berücksichtigt wird. In einer zivilisierten Diskussion reicht es in der Regel aus, wenn die vorgelegte Stellungnahme begründet und begründet wird.
Andernfalls kommen wir zu dem absurden Schluss, dass, wenn eine Person ein Projekt durchgeführt hat, alle seine nachfolgenden Aussagen zunächst von allen akzeptiert werden müssen, obwohl sie in Wirklichkeit vielleicht nicht ganz mit der Argumentation übereinstimmen oder sogar der Meinung anderer Fachleute widersprechen, die ebenfalls Projekte durchgeführt haben.
Auch hier gilt, dass es nicht sehr bescheiden ist, mit etwas zu prahlen, denn das ist schlecht für das Karma.
Das heißt, es gibt keine Projekte, also auch keine Erfahrung.
Gleichzeitig vergisst man nicht die Erfahrung und versucht, die ältesten Sprüche von einst erfahrenen(in Bezug auf ihre Zeit) Menschen herauszuziehen. Da Sie keine eigenen Erfahrungen haben, verstehen Sie nicht, dass die herausgenommenen Äußerungen schon lange nicht mehr funktionieren. Sie haben nicht funktioniert und waren nur eine Wahnvorstellung, die der damaligen Zeit eigen war. Es ist schon peinlich, sich diese Wahnvorstellungen ins Gedächtnis zu rufen.
Außerdem verstehen Sie nicht wirklich das Wesentliche dessen, was in den zitierten Links steht. Sie reißen Worte an sich und interpretieren sie falsch, obwohl es heißt "OOP ist besser als Krücken (und Krücken sind ein Versuch, OOP ohne OOP zu emulieren) und muss verwendet werden".