Record sul mercato - pagina 31
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
Probabilmente perché non lavoro per un'azienda. E trovo più facile usare la programmazione procedurale piuttosto che l'OOP.
C'è stato molto dibattito su questo, naturalmente.
Bene, proprio nell'ultima settimana ho fatto alcune modifiche all'algoritmo di stima della qualità del trading per la mia TS League. E sono molto contento che tutto sia basato su interfacce virtuali.
Il punto è che prima il prelievo massimo era stimato solo dal bilancio. E volevo stimarlo per equità. Ma per fare questo, quando si analizza la storia - per ogni transazione è necessario richiedere la serie temporale, e vedere quale è stato il drawdown massimo della transazione, basato sui prezzi di allora.
Ora ricordate, che il mio codice è portatile, significa che basato sulla stessa interfaccia - sia MT4 che MT5 funzionano. Di conseguenza, per ogni piattaforma - chiama la classe appropriata con le proprie funzioni, che sono notevolmente diverse. Così, mentre modificavo il codice - probabilmente una dozzina di volte mi sono trovato in una situazione in cui non ero in grado di accedere direttamente ai dati richiesti - le interfacce non lo permettevano. E ogni volta mi assicuravo di essere corretto, che le interfacce mi avevano limitato - se avessi "pasticciato" con quei dati direttamente - avrebbe causato errori in altre parti del programma. I dati di cui avevo bisogno, dovevo accedere in un modo diverso, attraverso query aggiuntive, che mi permettevano di essere sicuro che nessun'altra parte fosse interessata.
In sintesi: ancora una volta sono convinto che il principio "in ogni luogo l'utente deve avere accesso solo a quelle strutture di cui ha bisogno al momento e nessun altro" è assolutamente corretto. Non si può permettere all'utente di avere sempre accesso a tutto - è pieno di errori di modifica.
Ma d'altra parte - le persone che sono abituate a uno stile procedurale - si limitano semplicemente in questi casi a ricordare quali dati possono essere cambiati da una data posizione e quali no.
Bene, proprio nell'ultima settimana ho fatto alcune modifiche all'algoritmo di valutazione della qualità del trading per la mia Lega TS. E sono molto contento che tutto sia basato su interfacce virtuali.
Il punto è che prima il prelievo massimo era stimato solo dal bilancio. E volevo stimarlo per equità. Ma per fare questo, quando si analizza la storia - per ogni transazione è necessario richiedere la serie temporale, e vedere quale è stato il drawdown massimo della transazione, basato sui prezzi di allora.
Ora ricordate, che il mio codice è portatile, significa che basato sulla stessa interfaccia - sia MT4 che MT5 funzionano. Di conseguenza, per ogni piattaforma - chiama la classe appropriata con le proprie funzioni, che sono notevolmente diverse. Così, mentre modificavo il codice - probabilmente una dozzina di volte mi sono trovato in una situazione in cui non ero in grado di accedere direttamente ai dati richiesti - le interfacce non lo permettevano. E ogni volta mi assicuravo di essere corretto, che le interfacce mi avevano limitato - se avessi "pasticciato" con quei dati direttamente - avrebbe causato errori in altre parti del programma. I dati di cui avevo bisogno, dovevo accedere in un modo diverso, attraverso query aggiuntive, che mi permettevano di essere sicuro che nessun'altra parte fosse interessata.
In sintesi: ancora una volta sono convinto che il principio "in ogni luogo l'utente deve avere accesso solo a quelle strutture di cui ha bisogno al momento e nessun altro" è assolutamente corretto. Non bisogna lasciare che l'utente abbia sempre accesso a tutto ciò di cui ha bisogno - potrebbe causare errori di modifica.
Ma, d'altra parte - le persone abituate allo stile procedurale - si limitano in questi casi a ricordare quali dati possono e non possono essere cambiati dal posto dato.
Beh, questa è la concorrenza. Non si può evitare. Non si arrenda, continui ad andare avanti e vinca. Altrimenti, rimarrete indietro.
Dimenticatevi dell'OLP. Se questa domanda vi preoccupa, posso dirvi che nella programmazione bisogna usare solo ciò di cui si può fare a meno. Se potete fare con lo stile procedurale, fatelo.
Il mio principio:"Se puoi fare a meno di qualcosa nel risolvere un compito, dovresti assolutamente farne a meno".
Il cane ha bisogno di una quinta gamba? :)
Esattamente.
Questo è il tipo di competizione di cui avete bisogno.
Sarai sorpreso, ma soffro ancora di programmazione procedurale.
Sono entrato in Pascal quando avevo 14 anni e non posso cambiare me stesso. E ho "imparato le lezioni" molto tempo fa, ma non posso cambiare idea...
Probabilmente perché non lavoro per un'azienda. E trovo più facile usare la programmazione procedurale piuttosto che l'OOP.
I principi OOP non differiscono molto dalla programmazione procedurale, tanto più nei programmi MQL i compiti sono altamente specializzati e spesso non ha senso sviluppare la struttura interna di una classe. Più del 90% degli esempi che usano le classi in Codobase non sono altro che programmazione procedurale "wrapped in class", perché i compiti che sono risolti da una classe sono eseguiti solo una volta e l'ereditarietà e il polimorfismo non sono usati (perché non c'è bisogno).
E i problemi seri, dove non c'è modo senza OOP - è un grafico. Questo problema è già stato risolto ed è in libero accesso e bisogna solo sapere come usarlo o modificarlo (come l'ereditarietà).
L'hanno già fatto ed è liberamente disponibile, si tratta solo di sapere come usarlo (grafica in MQL) o come ereditarlo (come usare l'ereditarietà).
ZZZY: è quello che non dirò sull'usabilità in termini di ALGLIB - certamente dovrebbe essere "avvolto" in una classe normale!
Igor Makanu:
...
E i compiti seri in cui non si può fare a meno di OOP sono la grafica...
Molto controverso))
Molto controverso))
I principi della OOP non differiscono molto dalla programmazione procedurale, specialmente nei programmi MQL i compiti sono altamente specializzati e spesso non ha senso sviluppare la struttura interna di una classe. Più del 90% degli esempi che usano le classi in Codobase non sono altro che programmazione procedurale "wrapped in class", perché i compiti che sono risolti da una classe sono eseguiti solo una volta e l'ereditarietà e il polimorfismo non sono usati (perché non ce n'è bisogno).
E i problemi seri, dove non c'è modo senza OOP - è un grafico. Questo problema è già stato risolto ed è in libero accesso e bisogna solo sapere come usarlo o modificarlo (come l'ereditarietà).
L'hanno già fatto ed è liberamente disponibile, si tratta solo di sapere come usarlo (grafica in MQL) o come ereditarlo (come usare l'ereditarietà).
ZZZY: è quello che non dirò sull'usabilità in termini di ALGLIB - certamente dovrebbe essere "avvolto" in una classe normale!
Dipende per cosa.
Per la facilità d'uso da parte di altri utenti?
È possibile, sì.
In modo che gli utenti non abbiano l'impulso di "fare casino" e causare danni.
Uso 5 funzioni di disegno per la mia grafica (testo, pulsante, casella di controllo, campo, sfondo) !)
Tutto è chiaro per me. Gli altri non hanno bisogno di vederlo.
Esattamente.
Questo è il tipo di competizione di cui abbiamo bisogno.
Sogno che tale concorrenza cresca nel nostro mercato. Solo il Mercato ha bisogno di essere ripulito.
Per perfezionare il nuoto, la piscina deve essere prima pulita e poi riempita d'acqua. In breve, sono necessarie le giuste condizioni.
Se la piscina è sporca, nessuno vorrà competere. :)Bene, proprio quest'ultima settimana ho fatto alcune modifiche all'algoritmo di valutazione della qualità del trading per la mia TS League. E sono molto contento che tutto sia basato su interfacce virtuali.
Il punto è che prima il prelievo massimo era stimato solo dal bilancio. E volevo stimarlo per equità. Ma per fare questo, quando si analizza la storia - per ogni transazione è necessario richiedere la serie temporale, e vedere quale è stato il drawdown massimo della transazione, basato sui prezzi di allora.
Ora ricordate, che il mio codice è portatile, significa che basato sulla stessa interfaccia - sia MT4 che MT5 funzionano. Di conseguenza, per ogni piattaforma - chiama la classe appropriata con le proprie funzioni, che sono notevolmente diverse. Così, mentre modificavo il codice - probabilmente una dozzina di volte mi sono trovato in una situazione in cui non ero in grado di accedere direttamente ai dati richiesti - le interfacce non lo permettevano. E ogni volta mi assicuravo di essere corretto, che le interfacce mi avevano limitato - se avessi "pasticciato" con quei dati direttamente - avrebbe causato errori in altre parti del programma. I dati di cui avevo bisogno, dovevo accedere in un modo diverso, attraverso query aggiuntive, che mi permettevano di essere sicuro che nessun'altra parte fosse interessata.
In sintesi: ancora una volta sono convinto che il principio "in ogni luogo l'utente deve avere accesso solo a quelle strutture di cui ha bisogno al momento e nessun altro" è assolutamente corretto. Non bisogna lasciare che l'utente abbia sempre accesso a tutto ciò di cui ha bisogno - potrebbe causare errori di modifica.
Ma, d'altra parte - le persone che sono abituate a uno stile procedurale - semplicemente si limitano in questi casi, ricordando quali dati possono essere cambiati da un dato posto e quali no.
Con tutto il rispetto, ma i vostri argomenti sono come quelli di un uomo molto vecchio che spiega e dimostra la necessità del bastone su cui si appoggia. Dicono che senza di essa cadrò sicuramente. Questo è vero. Ma non per tutti.
Molto controverso))
Forse, ma sono anche un "dinosauro della fine degli anni '90" ho visto Turbo Pascal e i rudimenti della grafica sotto forma di librerie che non importa come la giri - si ottiene ancora Norton Commander ))))
Ma con l'avvento (e il mio passaggio) a Delphi, come si dice, è lì che la vita è iniziata.... Non riesco a immaginare come fare finestre attive, caselle di controllo, ecc. senza OOP, credo in teoria, ma non vedo nemmeno come si possa fare senza OOP, come si dice che ci si abitua a una cosa buona!
Con tutto il rispetto, i vostri argomenti sono come quelli di un uomo molto vecchio che spiega e dimostra la necessità del bastone su cui si appoggia. Senza, sono destinato a cadere. Questo è vero. Ma non per tutti.
Lei, se ricordo bene, ricorda perfettamente tutto ciò che si trova nella sua enorme serie di dati. Io, invece, non ricordavo queste cose nemmeno quando ero giovane. Ora, quando sono vecchio, non posso certo ricordare tutto ciò che intendevo quando ho scritto un certo blocco. Questo "bastone" mi aiuta molto. Ma sono d'accordo che se qualcuno è in grado di conservare nella sua memoria tutto il necessario, può farne a meno.
Tuttavia, ho già citato più volte il codice rispettato di fxsaber, dove lui stesso non ha saputo dirmi esattamente come funziona. È solo che ha dei controlli molto complicati e non ovvi che sono davvero difficili da ricordare. E l'uomo non ricorda. Il consenso era che "questo codice è stato controllato molte volte, quindi ci si può fidare". Ma cosa succederà se alcuni protocolli di lavoro cambiano? Il codice diventa immediatamente non valido, e in questo caso - invece di correggere ciò che è cambiato - dovrà essere riesaminato fino a trovare proprio questo posto cambiato.
Ecco a cosa servono questi "bastoni". I prodotti software oggi sono così complicati che non è realistico tenere a mente tutte le loro complessità. Questo è il motivo per cui si usano diverse tecniche (OOP è solo una di queste).