come creare oggetti in modo dinamico? (Alcune cose OOP) - pagina 4
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Assolutamente. Mi ci sono voluti mesi per creare il mio framework GUI con MQL, senza calcolare l'esperienza che avevo già dal passato creando librerie come queste. La parte più difficile non sono gli eventi, è più l'architettura e la quasi impossibilità di eseguire il debug del codice, a causa di tutti gli annidamenti e le ricorsioni ma anche a causa degli stati del mouse che diventano già non validi quando inizia il debug.
A proposito, ho offerto una collaborazione a MQ con queste librerie mesi fa e purtroppo non ho nemmeno ricevuto una risposta. Ma il fatto è che la libreria di controllo standard è solo un tentativo bello ma anche brutto rispetto a ciò che è effettivamente possibile. Si può fare molto meglio. Forse dovrei offrire la libreria al mercato qui, ma sto spaventando il gruppo di lavoro per scrivere l'intera documentazione per essa.
Questa non è affatto una domanda. L'OOP si basa sui principi della natura. La terra non ti nutre, fornisce solo le risorse e dipende da te se, quando e dove hai bisogno di cosa.
Vuoi dire che, quando si crea un quadro, ci si preoccupa solo di fornire le risorse? L'ho capito, ma in qualche modo lo trovo difficile da mettere in pratica perché la mia tendenza è troppo forte.
Per esempio, se creo un framework e ora creo il pulsante e il radio button che è una sorta di contenitore di pulsanti - quando arrivo a creare il radiobutton, la mia tendenza è di pensare all'oggetto dipendente, il pulsante in questo caso, e come comunico con esso. È un'abitudine della programmazione procedurale, mi chiedo se hai fatto il passaggio nel tuo passato da procedurale a OO e puoi indicarmi una chiara visione di ciò che devo focalizzare in questo caso. Perché tendo a concentrarmi più sul pulsante (oggetto dipendente) che sul radiobutton.
Non sono sicuro di essere stato chiaro, è solo una domanda per indicare le cose importanti su cui concentrarsi quando si crea un livello in un framework.
Puoi dire cosa intendi con questo? Ho la sensazione generale di quello che dici, ma non è molto chiaro.
Vuoi dire che quando crei un framework, ti preoccupi solo di fornire le risorse? L'ho capito, ma in qualche modo lo trovo difficile da mettere in pratica perché la mia tendenza è troppo forte.
Per esempio, se creo un framework e ora creo il pulsante e il radio button che è una sorta di contenitore di pulsanti - quando arrivo a creare il radiobutton, la mia tendenza è di pensare all'oggetto dipendente, il pulsante in questo caso, e come comunico con esso. È un'abitudine della programmazione procedurale, mi chiedo se hai fatto il passaggio nel tuo passato da procedurale a OO e puoi indicarmi una chiara visione di ciò che devo focalizzare in questo caso. Perché tendo a concentrarmi più sul pulsante (oggetto dipendente) che sul radiobutton.
Non sono sicuro di essere stato chiaro, è solo una domanda per indicare le cose importanti su cui concentrarsi quando si crea un livello in un framework.
Forse ho perso il punto, ma vorrei darvi la mia opinione.
Penso che tu sia troppo sulla "teoria" e che aspetti la luce da qualcun altro. Non c'è una soluzione perfetta, ci sono delle soluzioni e bisogna trovarle in base alla propria esperienza e ai propri bisogni concreti.
Questo argomento è partito da un caso pratico, e sa diventato una discussione oscura su OOP. C'è un'interessante serie di articoli sulla GUI, dovresti darci un'occhiata, poi provare a costruire un'interfaccia usando la Standard Library, e usando la libreria di questi articoli, e studiare il codice...o no.
Solo un suggerimento, perché non vedo davvero come potresti essere aiutato molto meglio.
Forse ho perso il punto, ma vorrei darvi la mia opinione.
Penso che tu sia troppo sulla "teoria", e aspetti la luce da qualcun altro. Non c'è una soluzione perfetta, ci sono soluzioni e devi trovarla in base alla tua esperienza e alle tue esigenze concrete.
Questo argomento è partito da un caso pratico, e sa diventato una discussione oscura su OOP. C'è un'interessante serie di articoli sulla GUI, dovresti darci un'occhiata, poi provare a costruire un'interfaccia usando la Standard Library, e usando la libreria di questi articoli, e studiare il codice... o no.
Solo un suggerimento, perché non vedo davvero come potresti essere aiutato molto meglio.
Alain, ho costruito un'interfaccia e ho letto gli articoli.
Forse non è il posto giusto per discutere di OO, potresti avere ragione.
Ho iniziato a discuterne perché Doerk ha presentato l'argomento come risposta all'argomento principiante e ha parlato del corretto approccio OO.
Il topic begginer stesso era interessato alla presentazione OO di Doerk, e penso che sia naturale discuterne qui.
Anche se si potrebbe avere ragione che forse è troppo teorico, ancora la mia opinione è che l'OO corretto non può senza coinvolgere un po' di teoria e alla fine diventa pratico.
La mia difficoltà è il pensiero corretto OO, mi chiedevo solo se per caso Doerk potrebbe conoscere dalla sua esperienza la difficoltà mentale che ho presentato.
C'è un'interessante serie di articoli sulla GUI, dovresti darci un'occhiata, poi provare a costruire un'interfaccia usando la Libreria Standard, e usando la libreria di questi articoli, e studiare il codice... o no.
L'ho appena scaricato per vedere cosa fa. E la prima impressione è che hanno fatto gli stessi errori che hanno fatto con la Standard Control Library. Già il primissimo esempio con una sola finestra di dialogo fa salire l'utilizzo della CPU dal 10% (senza) al 50-65% (caricato). Questa è già la prova migliore che gli autori non hanno l'esperienza necessaria per sviluppare una tale libreria e che questo non può essere - un - modo per farlo bene.
Non capisco comunque perché MQ non fornisce un framework GUI professionale invece di spiegare come (non) si fa. La maggior parte dei programmatori MQL vuole sicuramente sviluppare EA e indicatori, ma non vuole preoccuparsi di queste cose.
Inoltre, il pannello del loro esempio è morto nel tester della strategia, ed è qui che tutta questa roba GUI diventa comunque assurda. Questa non è una critica contro di te o contro ciò che hai scritto, io stesso so che semplicemente non c'è roba pubblica migliore disponibile per MQL qui.
Alain, ho costruito un'interfaccia e ho letto gli articoli.
Forse non è il posto giusto per discutere di OO, potresti avere ragione.
Ho iniziato a discuterne perché Doerk ha presentato l'argomento come risposta all'argomento principiante e ha parlato del corretto approccio OO.
Il topic begginer stesso era interessato alla presentazione OO di Doerk, e penso che sia naturale discuterne qui.
Anche se si potrebbe avere ragione che forse è troppo teorico, ancora la mia opinione è che l'OO corretto non può senza coinvolgere un po' di teoria e alla fine diventa pratico.
La mia difficoltà è il pensiero corretto OO, mi chiedevo solo se per caso Doerk potrebbe conoscere dalla sua esperienza la difficoltà mentale che ho presentato.
Non c'è nessun problema a discutere di OOP qui.
Non sono d'accordo sul tuo "l'OO non può senza coinvolgere qualche teoria", ma questo non importa.
Non c'è nessun problema a discutere di OOP qui.
Non sono d'accordo sul tuo "OO non può senza coinvolgere qualche teoria", ma questo non importa.
L'ho appena scaricato per vedere cosa fa. E la prima impressione mostra che hanno fatto gli stessi errori che hanno fatto con la Standard Control Library. Già il primissimo esempio con una sola finestra di dialogo fa salire l'utilizzo della CPU dal 10% (senza) al 50-65% (caricato). Questa è già la prova migliore che gli autori non hanno l'esperienza necessaria per sviluppare una tale libreria e che questo non può essere - un - modo per farlo bene.
Non capisco comunque perché MQ non fornisce un framework GUI professionale invece di spiegare come (non) si fa. La maggior parte dei programmatori MQL vuole sicuramente sviluppare EA e indicatori, ma non vuole preoccuparsi di queste cose.
Inoltre, il pannello del loro esempio è morto nel tester di strategia, ed è qui che tutta questa roba GUI diventa comunque assurda. Questa non è una critica contro di te o contro ciò che hai scritto, io stesso so che semplicemente non c'è roba pubblica migliore disponibile per MQL qui.
Doerk, molto probabilmente hai ragione, ma non è questo il mio punto.
Dovresti scrivere un esempio concreto del perché questo problema della CPU accade, spiegare ad Anatoli (autore degli articoli) qual è il problema. Mi dispiace dire che fino ad ora tutto quello che hai detto è quasi inutile, anche se hai ragione al 100%. È solo troppo generale e teorico. Senza offesa.
Il problema è che questo problema è troppo complesso per dare istruzioni precise. Ed è per questo che sto cercando di fornire alcune idee e modi possibili a coloro che sono interessati. Purtroppo non ho il tempo di scrivere un articolo né di pubblicare una libreria completamente documentata. Mi dispiace.