Mein Ansatz. Der Kern ist der Motor. - Seite 137
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
Peter, du hast wirklich etwas über die Anwendung von OOP missverstanden.
Nikolai, bauen Sie HIERARCHY oder erstellen Sie Zeichenmechanismen?
Wenn Sie HIERARCHY bauen (sich nicht um das Zeichnen kümmern), dann ist es klar, warum Sie überall OOP brauchen.
Wenn Sie einen Zeichenmechanismus erstellen, der auf der Grundlage EINER Klasse funktioniert, dann brauchen Sie die Klasse selbst nicht.
Klasse, - von dem Wort Klassifizierung. Die Klassifizierung ist eine Einteilung nach Merkmalen. Klasse ist eine Ableitung von Klassifizierung. Wenn es nur eine Klasse gibt, gibt es auch keine Klassifizierung.
In diesem Fall ist Klasse also abstrakter Blödsinn. Das macht keinen Sinn.
...
Man hat den Eindruck, dass die OOP selbst dem Mechanismus, dem sie dienen soll, vorauseilt. Das heißt, der Mechanismus muss nach Integrität streben, also nach der kleinsten Anzahl seiner Blöcke. Aber OOP zwingt diese Blöcke, sich aus irgendeinem Grund zu vermehren. Infolgedessen ist die Struktur der Mechanismen zerrissen und sie funktionieren nicht gut. Und sie entwickeln sich noch schlechter.
...
Vielleicht sollten Sie OOP zumindest ein wenig studieren, anstatt darüber zu phantasieren? Du phantasierst nicht einmal, du bist im Delirium.
Nikolai, ist dir jemals in den Sinn gekommen, dass deine Liebe zu OOP durch fast nichts gerechtfertigt ist außer durch abstrakte Gründe?
Wenn Sie mit diesem OOP gigantische Mechanismen erstellen würden, wäre es klar, warum Sie es so sehr brauchen. Sie würden ausdrücklich begründen, warum Sie OOP brauchen. Aber Sie schaffen relativ kleine Mechanismen. Es gibt nicht genügend Code, um Rückschlüsse auf die Vor- und Nachteile dieses oder jenes Ansatzes zu ziehen. Aber Sie reden trotzdem weiter über OOP. OOP ist nur ein Werkzeug, das für sich genommen keinen Sinn hat. Das heißt, wenn es keinen Mechanismus gibt, der gemacht werden muss, ist OOP nicht notwendig. Aber wenn es einen Mechanismus gibt, dann sollte er ernsthaft genug sein, um OOP bei der Erstellung zu erfordern.
Die meisten derjenigen, die sich für OOP einsetzen, machen nichts Ernstes. Sie tun nur kleine Dinge. Ihr Glaube an OOP ist jedoch unerschütterlich. Andere, die viel ernsthaftere Mechanismen entwickeln, schreien viel seltener nach der Großartigkeit von OOP. Einige äußern sich sogar kritisch (das ist schon ein paar Mal vorgekommen).
Ihr Argument muss also durch die Praxis untermauert werden, nicht nur durch die Theorie. Ich kann zum Beispiel mit Anatoly über die Vorteile von OOP in der GUI-Entwicklung streiten, weil wir Lösungen und ihre Nuancen in der Praxis vergleichen können. Aber bei Ihnen kann ich mein Argument nicht anbringen, weil Sie es nicht verstehen werden. Das werden Sie, aber Sie werden es nicht verstehen (nichts für ungut). Anatoly hingegen kann es sehr gut verstehen. Die unterschiedliche Erfahrung bei der Schaffung globaler Mechanismen ist der Hauptgrund für die Missverständnisse.
Als Praktiker kann ich Ihnen Folgendes sagen: Der Ansatz muss so beschaffen sein, dass er das Potenzial des Gehirns eines bestimmten Programmierers maximiert. Ich habe einen solchen Ansatz für mich gefunden.
Die Fantasien über OOP werden immer wilder und wilder...
Die Ernsthaftigkeit der Arbeit wird durch das Ergebnis bestimmt, nicht durch die Anzahl der verbrachten Jahre.
Leider ist das kein Unsinn.
Für das Zeichnen auf der Leinwand ist kein Klassen-Wrapper erforderlich. Eine Liste von Funktionen ist ausreichend. Sie brauchen keine Zugriffsrechte auf die Methode, um zu zeichnen. Und Sie wissen das. Aber Sie leugnen diese Tatsache. Sie leugnen das Offensichtliche.
Oh ja, um eine Banane zu essen, muss man die Schale abziehen. Aber wenn eine Kuh Hörner hat, dann ist jeder, der Hörner hat, eine Kuh.
Nun, solche Leute gibt es hier nicht viele. Ich bin wahrscheinlich einer von ihnen. Allerdings nicht, um Sie zu belehren. Nur um eine vernünftige Antwort zu hören. Warum sollten Sie beim Zeichnen auf die Klassenfunktionen durch Objekte verweisen, wenn Sie nur EINE Klasse verwenden?
Da sich die Zeichenfunktionen auf der Leinwand nur auf das Zeichnen auf der Leinwand beziehen und auf nichts anderes, gibt es keinen Grund, sie in einem separaten Behälter aufzubewahren, weshalb sie in einer Klasse zusammengefasst sind. Aber Sie würden es sowieso nicht verstehen.
Nikolai, bauen Sie HIERARCHY oder erstellen Sie Zeichenmechanismen?
Wenn Sie HIERARCHY bauen (sich nicht um das Zeichnen kümmern), dann ist es klar, warum Sie überall OOP brauchen.
Wenn Sie einen Zeichenmechanismus erstellen, der auf der Grundlage EINER Klasse funktioniert, dann brauchen Sie die Klasse selbst nicht.
Klasse, - von dem Wort Klassifizierung. Die Klassifizierung ist eine Einteilung nach Merkmalen. Klasse ist eine Ableitung von Klassifizierung. Wenn es nur eine Klasse gibt, gibt es auch keine Klassifizierung.
In diesem Fall ist Klasse also abstrakter Blödsinn. Das macht keinen Sinn.
Was hat die Hierarchie damit zu tun? OOP macht ausgiebigen Gebrauch von Vererbung... ...und ein weiterer Haufen zügelloser Fantasie...
...und die Kirsche auf dem Sahnehäubchen:
Ich hatte ein ähnliches Projekt mit einer anderen, ziemlich teuren Software, und ich habe die Idee auch mit Umgehungslösungen umgesetzt (um keine zusätzlichen Module zu kaufen).
Ich hatte ein ähnliches Projekt auf einem anderen, ziemlich teuer spezielle Software, auch die Idee von Workarounds umgesetzt (um nicht zu kaufen zusätzliche Module), es funktionierte, aber mit einigen Kunden endete in einer Sackgasse und die Zeit verschwendet wurde
Aber das war ein ganz anderes Feld, es war leicht, Kunden zu finden.