Mein Ansatz. Der Kern ist der Motor. - Seite 135
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
Da gibt es ein anderes Problem. Die Begrenzung der Kernelemente und Parameter. Ich weiß, wie die Lösung aussehen sollte. Ich hatte nur noch keine Gelegenheit, es zu tun.
Das ist der Grund für meine Frage. Wenn man 21 Fäden in den Kern eingenäht hat, ist das nicht sehr gut, und man kann es nicht einfach reparieren.
Nein. Es ist externer Code, der für den Konstruktor geschrieben wird. Damit wird die Tabelle reproduziert. Dann klicke ich auf die Schaltfläche und alle Verbindungsdateien und der Boot-Kernel für den Motor werden gedruckt. Dann funktioniert alles.
Soweit ich weiß, handelt es sich um einen Autogenerator, der den Autoconnect-Code und einen Teil des Kernel-Codes erzeugt. Dies ist eine interessante Lösung.
Ich habe es noch nicht getestet.
Das funktioniert bei mir. Aber es scheint ein Problem mit dem Schließen einer Zeile zu geben, wenn ein Stopp ausgelöst wird. Manchmal bleibt der Streit bestehen. Dies ist ein Problem mit der Erkennung von geschlossenen Aufträgen in dem von mir geschriebenen Code. Der Tisch hat damit nichts zu tun.
1. Das ist der Grund für meine Frage. Wenn man 21 Zeilen im Kernel hat, ist das nicht gut und man kann es nicht einfach reparieren.
2. Soweit ich weiß, handelt es sich um einen Autogenerator, der den Autoconnect-Code und einen Teil des Kernel-Codes generiert. Interessante Lösung.
1. genau. Im Konstruktor kann eine begrenzte Anzahl von Elementen vorgegeben werden. Eine dynamische Tabelle muss also aus einer begrenzten Anzahl von Zeilen bestehen, aber gleichzeitig unbeschränkt sein. Die Lösung besteht lediglich darin, spezielle Arrays für die hinzugefügten Parameter zu erstellen und ihre Werte durch die Tabellenzellen zu blättern.
2. Ja. Der Konstruktor erstellt den Kernel für die Maschine auf der Grundlage des von Ihnen zitierten Codes. + druckt die Verbindungsdateien. Dann habe ich den Kernel in den Motor (DRIVE) eingesetzt. Danach kann die Engine die gewünschte GUI abspielen. Die Schnittstellendateien stellen eine Verbindung mit dem EA her und beginnen mit ihm zu interagieren.
Um nicht unbegründet zu sein, werde ich Ihnen schließlich ein Beispiel für den "Kern" selbst geben. Genauer gesagt, handelt es sich um eine Boot-Datei. Es gibt mehrere Kerne.
Ich möchte Sie daran erinnern, dass er automatisch auf der Grundlage des KIB-Codes gedruckt wird. Dann wird sie in den Motor eingebaut. Außerdem arbeitet der Motor mit ihm.
Nikolay, lassen Sie uns über das Thema sprechen. Nehmen Sie zum Beispiel die Klasse CCanvas, mit der ich mich bereits beschäftigt habe. Also habe ich alle Funktionen herausgenommen. Sie wurden von der Klassenumhüllung unabhängig gemacht. Warum ist es jetzt schlimmer? Es wurde einfacher, mit ihnen zu arbeiten. Ich habe eine Animation mit diesen Funktionen erstellt. Davor habe ich kaum Animationen mit dieser Klasse gesehen.
Warum also dieser Wrapper?
Du zeichnest auch auf einer Leinwand. Sie könnten einfach eine bestimmte Funktion aufrufen und zeichnen. Aber nein. Sie wickeln und wickeln und wickeln. Erklären Sie mir also, warum?
Ja, weil es mega-bequem ist. Aber es ist sehr schwer zu verstehen, bis man es selbst benutzt.
Ich bin nicht in der Lage, so zu denken, dass es für mich bequem ist. Deshalb ist es für mich nicht günstig. Wrap around, Darstellung der Objektorientierung. Einordnen, wann notwendig und wann nicht notwendig...
Man hat den Eindruck, dass die OOP selbst dem Mechanismus, dem sie dienen soll, in die Quere kommt. 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.
Nikolay, fangen Sie an, Mega-Mechanismen zu erstellen (10-mal größer als die Kanvas-Klasse), und Sie werden verstehen, wo und wie OOP unpraktisch wird.
Ich weiß nicht, wie ich so denken soll, dass ich mich wohl fühle. Deshalb ist es für mich unangenehm. Umhüllung, Darstellung der Objektorientierung. Klassifizierung, wann notwendig und wann nicht notwendig...
Man hat den Eindruck, dass die OOP selbst dem Mechanismus, dem sie dienen soll, in die Quere kommt. 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.
Nikolay, fangen Sie an, Mega-Mechanismen zu erstellen (10-mal größer als die Kanvas-Klasse), und Sie werden verstehen, wo und wie OOP unpraktisch wird.
Ihre Worte sagen nur eines aus:
...
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 ist nicht genug Code vorhanden, 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 seriös genug sein, um bei der Erstellung OOP 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 maximal ausschöpft. Ich habe einen solchen Ansatz für mich gefunden.