Il mio approccio. Il nucleo è il motore. - pagina 16
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
Al momento ho un solo cliente. Completo i suoi compiti molto rapidamente. 3-4 ore e una nuova finestra completamente funzionale è pronta. Insieme all'interfaccia di connessione. Inoltre, correggo rapidamente i bug nel motore e gli invio nuove versioni. 9 finestre in pochi giorni + modifiche al motore, correzioni di bug, aggiunta di caratteristiche... Tutto molto veloce.
Devi avere molto tempo libero.
Capisci che tu da solo non sei abbastanza. La massività del tuo motore dipenderà dal fatto che piaccia ad altri programmatori (tu da solo non sei sufficiente per tutti i clienti). E se ai progenitori non piace, allora... ahimè, il destino della tua creazione sarà glorioso.
I programmatori non dovranno entrare nel codice del motore. Otterranno l'interfaccia di connessione nel file. L'ho già testato. Tutto funziona.
Al momento ho un solo cliente. Completo i suoi compiti molto rapidamente. 3-4 ore e una nuova finestra completamente funzionale è pronta. Insieme all'interfaccia di connessione. Inoltre, correggo rapidamente i bug nel motore e gli invio nuove versioni. 9 finestre in pochi giorni + modifiche al motore, correzioni di bug, aggiunta di caratteristiche... Tutto molto veloce.
Lo dice bene? 3-4 ore per creare una finestra? Non ci sono minuti?
In realtà lo faccio da più di un anno ormai. E non mi confondo)).
Per confronto, implementate la stessa cosa usando OOP. Forse vi piacerà. :)
Lo dice bene? 3-4 ore per creare una finestra? Non ci sono minuti?
No. Puoi farlo in pochi minuti se copi il codice da un'altra finestra e fai delle modifiche. Ma io parlavo di crearlo da zero, pensando alla grafica e lavorando sullo stile.
A proposito, Peter, non dimenticare di aggiungere tutti i tipi di grafici, come indicatori, solo in windows, con supporto per un paio di formati di dati (OHLC, come Zigzag, ecc.). Spero che sia tutto facilmente implementabile nel tuo progetto.
Ci proverò.
Ci proverò.
Non ci proverò, lo farò). Aumenta l'utilità della tua creazione.
Lo dice bene? 3-4 ore per creare una finestra? non minuti?
Che assurdità... fare 3 finestre in MQL anche usando le librerie del toolkit standard di MT richiede 10 minuti e altri 20-30 minuti per adattare l'altezza e l'XY di pulsanti, modifiche, etichette...
Vedo 2 possibilità per cui il lavoro di Petr può essere utile:
- creazione di un'applicazione separata per generare il codice sorgente MQL, cioè il costruttore GUI e non entrare nei dettagli di come funziona, per dire Visual MQL++ )))
- Oppure: ci sono persone che creano le proprie difficoltà e poi le superano con successo © Wingston Churchill
Mi sembra che tutti i componenti OOP di Peter siano costantemente aggrappati ai dettagli.
E il nocciolo della questione è proprio la filosofia e l'architettura del sistema.
È stato giustamente detto sopra quali sono le questioni controverse, che sembrano essere vantaggi per Pietro e svantaggi per i suoi avversari:
- heap di variabili accessibili globalmente, nessun incapsulamento.
- mancanza di controllo del tipo
- una rigida dipendenza da una particolare implementazione dell'archiviazione dei dati.
E Peter ha detto correttamente che il concetto di OOP (almeno nei miei suggerimenti) è progettato per semplificare, "basato sulla convenienza del programmatore". Incapsulamento, controllo dei tipi, interfacce - tutto questo è progettato per eliminare il più possibile la possibilità stessa di errore, confusione, abuso. Proprio così.
Il concetto di Pietro è l'opposto. Tutti i dati sono accessibili da qualsiasi luogo, l'utente da qualsiasi punto del codice ha il pieno controllo su tutti gli oggetti del programma e può percepirli come vuole senza alcuna restrizione di tipo (beh, tranne le restrizioni di MQL).
Peter dice che questo concetto "permette di raggiungere il massimo sviluppo. L'usabilità viene dopo".
Personalmente, come programmatore, già non mi piace che la convenienza venga al secondo posto. Ma si può sacrificare questo se si ottiene effettivamente molto più sviluppo. Beh, voglio vedere cos'è. Dove l'approccio OOP con le restrizioni e l'incapsulamento non permette di raggiungere tale sviluppo, come questo approccio con accesso completo all'enorme array di proprietà, gettato in un array di dimensioni mostruose. (Per non parlare della necessità di ricordare tutto).
Come giustamente sottolineato sopra, l'approccio ricorda il TurboVision di Pascal. Anche se il controllo dei tipi e i vincoli di incapsulamento sono già stati implementati in quella libreria.