Spese generali per l'OLP - pagina 5

 
fxsaber:

Tu hai il tuo involucro, l'altro ha il suo. La domanda era se è possibile creare un wrapper più conveniente di MQL4.

Non credo che ci sia molto da scegliere...

Personalmente ho bisogno del wrapper solo per la multipiattaforma - per separare la logica di Expert Advisor dalle specifiche di questa o quella piattaforma

 
Andrei:

Naturalmente, bisogna pagare la bellezza dell'OOP con risorse e molto tempo speso per il debugging. L'OOP ha senso solo come un comodo involucro di testo o quando è usato minimamente durante l'inizializzazione di runtime... In realtà, OOP era solo una cosa di marketing di Microsoft per aumentare i costi delle ore di lavoro dei programmatori e per stimolare l'acquisto di attrezzature più avanzate. E loro stessi non sono stupidi e scrivono tutto il software in C e assembler.

Che visionario che sei...

 
govich:

Sei un sognatore, vero?

Hai qualcosa di significativo da dire sull'argomento della discussione?

 

Ancora una volta mi sono imbattuto in...

In MQL, è impossibile separare "non storto" l'implementazione dei metodi dal prototipo e non c'è modo di fornire all'utente (cliente, tester, amico/amica) un file *.mqh e un file *.ex4 separati (simile a *.h e .obj/lib/dll in C++)

 
Maxim Kuznetsov:

Ancora una volta mi sono imbattuto in...

In MQL, è impossibile separare "incondizionatamente" l'implementazione dei metodi dal prototipo e non c'è modo di fornire all'utente (cliente, tester, amico/amica) un file *.mqh e un file *.ex4 separati (simile a *.h e .obj/lib/dll in C++)

Potresti essere più specifico sul compito? Sembra essere abbastanza semplice fornire un'intestazione con una fabbrica importata che restituisce interfacce pulite, e l'intera implementazione è stipata dentro ex4.

 
Stanislav Korotky:

Puoi essere più specifico sul compito? Sembra che sia possibile fornire l'intestazione con una fabbrica importata, che restituisce interfacce pulite, e tutta l'implementazione è memorizzata all'interno di ex4.

Il compito è quello di dare all'utente la libreria di classi con il minimo sforzo, che consiste in: mqh dove le classi sono descritte ed ex4 dove è memorizzata la loro implementazione.

L'unica opzione ad oggi trascina un sacco di testo con le stampelle per aggirare questo collo di bottiglia.

Se conosci un modo breve e pratico per rimuovere l'implementazione di CFoo in ex4, per favore condividi la ricetta.

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:

il compito è quello di dare all'utente una libreria di classi composta da: mqh in cui le classi sono descritte ed ex4 in cui sono implementate.

L'unica opzione finora tira un sacco di testo con le stampelle per aggirare questo collo di bottiglia.

Se conosci un modo breve e conveniente per rimuovere l'implementazione di CFoo in ex4, per favore condividi la ricetta.

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);

};

Beh, ho già scritto un modo - perché non è adatto? Si crea un metodo factory, o una funzione, che restituisce la classe astratta (interfaccia) descritta nel file di intestazione. L'intera implementazione è nascosta. L'esempio reale può essere trovato, per esempio, nel mio blog sulla biblioteca di ottimizzazione degli esperti al volo (in inglese).

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

Beh, ho già scritto un metodo - che c'è di male? Si crea un metodo factory, o una funzione, che restituisce una classe astratta (interfaccia) descritta nel file di intestazione. L'intera implementazione è nascosta. L'esempio reale può essere trovato, per esempio, nel mio blog sulla biblioteca di ottimizzazione degli esperti al volo (in inglese).

Prova a lanciare il codice sorgente. E tutti conoscono i link al wiki qui
 
Maxim Kuznetsov:
Prova a lanciare il codice sorgente. E tutti conoscono i link al wiki

Il link alla fonte wiki non va bene? ;-)

 
Stanislav Korotky:

Il link alla fonte wiki non va bene? ;-)

ma non lo farà :-)

Ve lo dico - provate a farlo, è un sacco di codice feroce. La classe istanziabile "CFoo: public InterfaceCFoo" deve contenere il campo InterfaceCFoo *privateContext (fare un collegamento 1:1), crearlo e cancellarlo tramite factory, delegare tutti i metodi e tradurre i riferimenti CFoo* this<->privateContext qua e là. Si tratta di "tramontare il sole a mano", cioè di sostituire l'eredità con la delega, e sul posto.