come creare oggetti in modo dinamico? (Alcune cose OOP) - pagina 3

Nuovo commento
 

BTW, sei consapevole che la build 1325 ha introdotto i puntatori alle funzioni?
Questo fa qualche differenza nell'applicazione della comunicazione triangolare?

MQL5: Aggiunto il supporto per i puntatori alle funzioni per semplificare la disposizione dei modelli di eventi.

Per dichiarare un puntatore a una funzione, specificare il tipo "puntatore a una funzione", per esempio:

typedef int (*TFunc)(int,int);

Ora, TFunc è un tipo, ed è possibile dichiarare la variabile puntatore alla funzione:

TFunc func_ptr;

La variabile func_ptr può memorizzare l'indirizzo della funzione per dichiararla in seguito:

int sub(int x,int y) { return(x-y); }
int add(int x,int y) { return(x+y); }
int neg(int x)       { return(~x);  }

func_ptr=sub;
Print(func_ptr(10,5));

func_ptr=add;
Print(func_ptr(10,5));

func_ptr=neg;           // error: neg is not of  int (int,int) type
Print(func_ptr(10));    // error: there should be two parameters

I puntatori alle funzioni possono essere memorizzati e passati come parametri. Non è possibile ottenere un puntatore a un metodo di classe non statico.

 
Non sono sicuro che l'uso dei puntatori di funzione sia implementato anche con MT4. Se è così, naturalmente, è anche possibile farlo in questo modo, purché tali puntatori possano essere gestiti anche da array, perché questo è possibile con i puntatori di classe.
 

Probabilmente è solo per MT5, e da quello che ho visto non è ancora per i metodi, solo per le funzioni.

Comunque non ho ancora capito come si definisce l'abilità di terze parti all'interno della classe base, per esempio nel contesto della linea di tendenza e del contenitore, dove si trova il terzo oggetto.

Ma cercherò di leggere di nuovo.

 
Quello che mi sembra mancare nella comprensione del modello degli eventi in connessione con OO e MQL5, è quale sia il giusto tipo di dispacciamento degli eventi.
Voglio dire, come e dove decidere chi (quale classe) riceverà cosa (evento).
È chiaro che il dispatcher superiore, quello nativo della lingua, cioè il linguaggio ::OnChartEvent è scritto solo una volta in un progetto, nella classe di primo livello.

Allora da qui, qual è il modo o i modi corretti di distribuire gli eventi ai diversi oggetti?
Dovrebbe esserci una classe di eventi di dispacciamento? Dovrebbe essere fatto solo nel ::OnChartEvent basato su dichiarazioni if?
 
Ok, penso di aver capito. C'è un vero problema di spostamento di concetto quando si passa dal procedurale all'oop.
Se ho capito bene, allora quello che intendi è un modo per la CTrendLine di informare il suo incrocio di prezzi a un oggetto ereditario CTrade per mezzo di un evento, senza dover sapere dell'esistenza di CTrade, è giusto?
 
Amir Yacoby:
Quello che mi sembra mancare nella comprensione del modello degli eventi in connessione con OO e MQL5, è quale sia il giusto tipo di dispacciamento degli eventi.
Voglio dire, come e dove decidere chi (quale classe) riceverà cosa (evento).
È chiaro che il dispatcher superiore, quello nativo della lingua, cioè il linguaggio ::OnChartEvent è scritto solo una volta in un progetto, nella classe di primo livello.

Quindi da qui, qual è il modo o i modi corretti di distribuire gli eventi ai diversi oggetti?
Dovrebbe esserci una classe di eventi di dispacciamento? Dovrebbe essere fatto solo nel ::OnChartEvent basato su dichiarazioni if?
Questa non è affatto una domanda. OOP si basa sui principi della natura. La terra non ti nutre, fornisce solo le risorse e sta a te se, quando e dove hai bisogno di cosa.
 
Amir Yacoby:
Ok, penso di aver capito. C'è un vero problema di spostamento di concetto quando si passa dal procedurale all'oop.
Se ho capito bene, allora quello che intendi è un modo per la CTrendLine di informare il suo incrocio di prezzi a un oggetto ereditario CTrade per mezzo di un evento, senza dover sapere dell'esistenza di CTrade, è giusto?
Io sostengo di sì.
 
Così in realtà ogni CObject ora ha un posto di un oggetto che è il ricevitore di eventi, e ha anche un metodo di registrazione per l'oggetto di ascolto per iscriversi come tale e un metodo mittente di eventi e un metodo gestore di eventi utilizzato dal ricevitore.

Questo è bello, mi ricorda il modello dell'osservatore, solo che con l'osservatore ha più di un possibile destinatario, il m_reciever è un array di oggetti.

In realtà, una volta volevo implementare l'osservatore e a causa della mancanza di interfacce in MQL o dell'ereditarietà multipla non l'ho fatto. Non ho pensato alla tua buona idea che lo stesso oggetto può forzare l'interfaccia su entrambi i lati.


 
Amir Yacoby:
Così in realtà ogni CObject ora ha un posto di un oggetto che è il ricevitore di eventi, e ha anche un metodo di registrazione per l'oggetto di ascolto per iscriversi come tale e un metodo mittente di eventi e un metodo gestore di eventi utilizzato dal ricevitore.

Questo è bello, mi ricorda il modello dell'osservatore, solo che con l'osservatore ha più di un possibile destinatario, il m_reciever è un array di oggetti.

In realtà, una volta volevo implementare l'osservatore e a causa della mancanza di interfacce in MQL o dell'ereditarietà multipla non l'ho fatto. Non ho pensato alla tua buona idea che lo stesso oggetto può forzare l'interfaccia su entrambi i lati.


Solo per incoraggiarvi, ho usato molto gli ascoltatori con MQL4.
 
Ovo Cz:
Solo per incoraggiarti, ho usato molto gli ascoltatori con MQL4.

Grazie, ma non mi sento incoraggiato (:

Sono riuscito a farlo, ma non con un contratto tra l'editore e l'ascoltatore, voglio dire, l'editore doveva presumere che l'ascoltatore avesse il metodo di gestione, ma nulla obbligava che lo avesse.
Oppure, dovrei ereditare tutti gli ascoltatori da un oggetto ascoltatore principale - ma poi ovviamente perderei tutto il punto perché non possono ereditare altre classi.

Comunque, sono un professionista della programmazione, ma sicuramente non in OO dove non ho ancora esperienza, e non sono in competizione con nessuno di voi programmatori oo esperti come Doerk.
Quello che sono venuto a sapere è che essere procedurale ti dà una buona logica e capacità di programmazione, ma il cambiamento è mentalmente difficile, specialmente se un orientato alla procedura come me affronta la missione di costruire un framework OO, è uno stato mentale totalmente diverso. E il framework della parte GUI è il framework più dettagliato con molti eventi di cui prendersi cura, penso che voi ragazzi sarete d'accordo che tra i framework è il più difficile da costruire.

12345
Nuovo commento
Motivazione: