Gemeinkosten für die PLO - Seite 5

 
fxsaber:

Sie haben Ihre eigene Verpackung, der andere hat seine eigene. Die Frage war, ob es möglich ist, einen bequemeren Wrapper als MQL4 zu erstellen.

Ich glaube nicht, dass die Auswahl groß ist...

Persönlich benötige ich den Wrapper nur für plattformübergreifende Zwecke - um die Logik des Expert Advisors von den Besonderheiten dieser oder jener Plattform zu trennen

 
Andrei:

Natürlich muss man für die Schönheit der OOP mit Ressourcen und viel Zeit für die Fehlersuche bezahlen. OOP macht nur Sinn, wenn man es als bequeme Textumhüllung einsetzt oder nur minimal bei der Laufzeitinitialisierung... Eigentlich war OOP nur eine Marketingmaßnahme von Microsoft, um die Kosten für die Arbeitszeit der Programmierer zu erhöhen und den Kauf fortschrittlicherer Geräte zu fördern. Und sie sind selbst nicht dumm und schreiben die gesamte Software in C und Assembler.

Was für ein Visionär Sie sind...

 
govich:

Sie sind ein Träumer, nicht wahr?

Haben Sie etwas Sinnvolles zum Thema der Diskussion zu sagen?

 

Wieder einmal stieß ich auf...

In MQL ist es unmöglich, die Implementierung von Methoden "nicht krumm" vom Prototyp zu trennen, und es gibt keine Möglichkeit, dem Benutzer (Kunde, Tester, Freund) eine separate *.mqh-Datei und eine separate *.ex4-Datei zur Verfügung zu stellen (ähnlich wie *.h und .obj/lib/dll in C++)

 
Maxim Kuznetsov:

Wieder einmal stieß ich auf...

In MQL ist es unmöglich, die Implementierung von Methoden "bedingungslos" vom Prototyp zu trennen, und es gibt keine Möglichkeit, dem Benutzer (Kunde, Tester, Freund) eine separate *.mqh-Datei und eine separate *.ex4-Datei zur Verfügung zu stellen (ähnlich wie *.h und .obj/lib/dll in C++)

Könnten Sie die Aufgabe etwas genauer beschreiben? Es scheint ziemlich einfach zu sein, einen Header mit einer importierten Fabrik bereitzustellen, die saubere Schnittstellen liefert, und die gesamte Implementierung ist in ex4 eingepfercht.

 
Stanislav Korotky:

Können Sie die Aufgabe genauer beschreiben? Es scheint möglich zu sein, den Header mit einer importierten Fabrik zu versehen, die saubere Schnittstellen zurückgibt, und die gesamte Implementierung ist in ex4 gespeichert.

Die Aufgabe besteht darin, dem Benutzer die Klassenbibliothek mit dem geringsten Aufwand zur Verfügung zu stellen. Diese besteht aus mqh, wo die Klassen beschrieben werden, und ex4, wo ihre Implementierung gespeichert wird.

Die einzige Option, die bisher zur Verfügung steht, schleppt eine Menge Text mit Krücken, um diesen Engpass zu umgehen.

Wenn Sie einen kurzen und praktischen Weg kennen, um die CFoo-Implementierung in ex4 zu entfernen, teilen Sie das Rezept bitte mit.

class CFoo {
public:
   CFoo();                         //default
  CFoo(const CFoo orig); // copy
   ~CFoo();
   bool Set(string key,CFoo & link); 
   CFoo *Get(string key);
   bool Clear(string key);

};

 
Maxim Kuznetsov:

Die Aufgabe besteht darin, dem Benutzer eine Klassenbibliothek zur Verfügung zu stellen, bestehend aus: mqh, in dem die Klassen beschrieben werden, und ex4, in dem sie implementiert werden.

Die einzige Möglichkeit, diesen Engpass zu umgehen, besteht bisher darin, eine Menge Text mit Krücken zu verfassen.

Wenn Sie einen kurzen und bequemen Weg kennen, um die CFoo-Implementierung in ex4 zu entfernen, teilen Sie das Rezept bitte mit.

class CFoo {
public:
   CFoo();                         //default
  CFoo(const CFoo orig); // copy
   ~CFoo();
   bool Set(string key,CFoo & link); 
   CFoo *Get(string key);
   bool Clear(string key);

};

Nun, ich habe bereits einen Weg geschrieben - warum ist er nicht geeignet? Sie erstellen eine Factory-Methode oder -Funktion, die die in der Header-Datei beschriebene abstrakte Klasse (Schnittstelle) zurückgibt. Die gesamte Durchführung ist versteckt. Ein konkretes Beispiel finden Sie zum Beispiel in meinem Blog über die Bibliothek zur Optimierung von Fachleuten im laufenden Betrieb (auf Englisch).

Фабричный метод (шаблон проектирования) — Википедия
Фабричный метод (шаблон проектирования) — Википедия
  • ru.wikipedia.org
Шаблон проектирования Тип: Назначение: Структура: Плюсы: Минусы: Описан в Design Patterns Фабричный метод (англ.  также известен как Виртуальный конструктор (англ.  )) — порождающий шаблон проектирования, предоставляющий подклассам интерфейс для создания экземпляров некоторого класса. В момент создания наследники могут определить, какой...
 
Stanislav Korotky:

Nun, ich habe bereits eine Methode geschrieben - was ist daran falsch? Sie erstellen eine Factory-Methode oder -Funktion, die eine abstrakte Klasse (Schnittstelle) zurückgibt, die in der Header-Datei beschrieben ist. Die gesamte Durchführung ist versteckt. Ein konkretes Beispiel finden Sie zum Beispiel in meinem Blog über die Bibliothek zur Optimierung von Fachleuten im laufenden Betrieb (auf Englisch).

Versuchen Sie, den Quellcode zu werfen. Und jeder kennt die Links zum Wiki hier
 
Maxim Kuznetsov:
Versuchen Sie, den Quellcode einzuwerfen. Und jeder kennt die Links zum Wiki

Ist der Link zum Quell-Wiki nicht in Ordnung? ;-)

 
Stanislav Korotky:

Ist der Link zum Quell-Wiki nicht in Ordnung? ;-)

aber das wird es nicht :-)

Ich sage Ihnen - versuchen Sie es, es ist eine heftige Menge Code. Instantifiable Klasse "CFoo: public InterfaceCFoo" muss Feld InterfaceCFoo *privateContext enthalten (1:1-Verknüpfung herstellen), über Factory erstellen und löschen, alle Methoden delegieren und CFoo* Referenzen this<->privateContext hier und da übersetzen. Das ist "Sonnenuntergang von Hand", d.h. Ersetzung der Vererbung durch Delegation, und zwar an Ort und Stelle.