Regole della struttura. Imparare a strutturare i programmi, esplorare le possibilità, gli errori, le soluzioni, ecc. - pagina 10

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
Non sono estraneo alla programmazione statale e l'ho usata io stesso per diversi anni. Tuttavia, dopo qualche tempo di utilizzo di questo metodo ho deciso di abbandonarlo e ho sviluppato un modello più trasparente, più semplice e più adatto al trading sulla sua base.
Leggi attentamente questo articolo: La programmazione automatica come un nuovo modo di creare sistemi di trading automatizzati
Poi leggete attentamente questi commenti su di esso.
Poi, molto, molto animatamente, contemplate una targa sgradevole dell'articolo e pensate a cosa potrebbe significare:
Se, dopo aver letto tutto questo, state ancora dicendo: "Wow! La programmazione statale è così figa!". - Beh, contateci.
Aggiungerei che il problema principale della programmazione dello Stato sono le situazioni che producono molti modi inutili (vedi colonna N Stato). Nella programmazione dello Stato, ogni modalità dovrebbe descrivere le proprie regole separatamente. Spieghiamo con un esempio: diciamo che siamo in modalità di acquisto. Tutto va bene fino a quando il robot decide di aprire un'altra posizione. E perché no? Le condizioni di uscita dalla vecchia posizione non sono state soddisfatte ed è troppo presto per chiuderla, mentre un nuovo segnale non dovrebbe essere perso. Ed è qui che iniziano i problemi, perché al momento dell'arrivo di un nuovo segnale il robot è in modalità Buy, mentre le regole per aprire una nuova posizione sono in modalità State (in attesa e alla ricerca di nuovi segnali di entrata). Ora in modalità Buy dobbiamo ridescrivere le stesse regole di apertura delle posizioni che si usano in modalità State. E se una nuova posizione è opposta in direzione (copertura)? Questa posizione è aperta, ma cosa farne? Dopotutto, la sua logica di gestione è descritta in modalità Sell, mentre il robot è in modalità Buy. Possiamo semplicemente passare alla modalità Sell, ma cosa fare con la rimanente posizione Buy? In generale, in questo caso dobbiamo scrivere un altro modo inutile come BuyAndSell. La ridondanza dei modi produce un'altra situazione: una stessa azione viene eseguita da diverse sezioni di codice. Tutto sommato, per coloro che amano il casino della programmazione esponenziale, questo è il migliore.
"È così Mihalych" (c)... Questo è quello a cui alludo anch'io.
(fcplm)
Assolutamente no.
Stavo solo pensando che se MQL5 supportasse l'ereditarietà multipla e una classe potesse dichiarare metodi astratti, si aprirebbe un modo per usare le interfacce, il che sarebbe ottimo per i grandi progetti.
I metodi astratti non sono esplicitamente vietati (spesso uso una notazione alternativa),
E l'eredità multipla sarebbe un enorme vantaggio.
I metodi astratti non sono esplicitamente proibiti.
Per citare Rosh: come ti aiuta a segare la legna da ardere?
La FAQ di Von è seduta sul quadruplo e se ne frega dei metodi astratti e dell'ereditarietà multipla.
Non importa se ci saranno metodi astratti o meno, in ogni caso, il compito di strutturare il progetto non sarà risolto.
A proposito, più varianti di implementazione di una e più difficile è scegliere quale variante usare.
Così si scopre che il programmatore spesso si blocca nel compito della bellezza del codice. È un'arte per il bene dell'arte.
Ho notato, in generale (parlando per me), che più timbri di pianificazione del progetto, più è facile.
Poi si può cambiare, modificare, ri-modificare, sovra-modificare,
Ma la struttura iniziale (anche se non è grande) dà il tono a tutta la costruzione.
Per citare Rosh: in che modo questo vi aiuta a segare la legna da ardere?
Poi si può cambiare, ri-modificare, ri-modificare, ri-modificare,
ma la struttura iniziale (anche se non è grande) dà il tono a tutta la costruzione.
La velocità di segare la legna da ardere aumenterà.
Se avete già un'idea chiara di come e cosa dovrebbe apparire - probabilmente potete fare tutto in modo intelligente in MQL4.
E se non c'è una tale nozione - significa che ci saranno molti cambiamenti e aggiunte. E l'eredità multipla permette cambiamenti con costi minimi.
Sono d'accordo con i metodi astratti - è solo una bella forma di registrazione.
La velocità di taglio della legna da ardere aumenterà.
Se avete già un'idea chiara di come e cosa dovrebbe apparire - probabilmente potete fare tutto in modo intelligente in MQL4.
E se non avete una tale idea - significa un sacco di cambiamenti e aggiunte. E l'eredità multipla in particolare permette di fare dei cambiamenti con costi minimi.
Oggi si cerca di abbandonare l'eredità a favore dell'inclusione. Riuscite a immaginare l'atteggiamento nei confronti delle eredità multiple?
FAQ:
Assolutamente no.
Non lo è. Usando un interruttore... caso e l'utilizzo di un modello di macchina a stati sono due cose diverse. Dal testo si capisce che non esiste uno schema, proprio come nell'articolo che hai citato.
Si legge qualcosa come "Ho inventato un sistema di vincita unico..." e poi una dichiarazione storta di Martin.