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

 

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.

 
C-4:
(fcplm)
 
C-4:

"È così Mihalych" (c)... Questo è quello a cui alludo anch'io.

TheXpert:
(fcplm)

Assolutamente no.

 
C-4:
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.

 
A100:
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.

 
Urain:

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.

 
A100:

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, l'eredità viene abbandonata a favore dell'inclusione. Riuscite a immaginare l'atteggiamento nei confronti delle eredità multiple?
 
Vladix:
Oggi si cerca di abbandonare l'eredità a favore dell'inclusione. Riuscite a immaginare l'atteggiamento nei confronti delle eredità multiple?
Senza ereditarietà multipla, non si possono organizzare relazioni orizzontali a livello di interfaccia. Il paradigma è semplice: qualsiasi oggetto può supportare qualsiasi numero di interfacce. Ma l'eredità multipla di per sé è certamente un male. Non per niente è vietato in C#, mentre l'uso delle interfacce è al contrario incoraggiato.
 
UrainC'è la FAQ seduta sul quadruplo e nessun metodo astratto o ereditarietà multipla lo preoccupa.


A narkarkal :https://www.mql5.com/ru/forum/13114
 

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.

Motivazione: