Regole della struttura. Imparare a strutturare i programmi, esplorare le possibilità, gli errori, le soluzioni, ecc. - pagina 3
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
Dai, non avevo nessun modello, poi ho iniziato con la procedura, poi sono passato al modello a oggetti.
E in generale, per default MQ ci dà un modello basato sugli eventi. All'inizio ci vengono dati gli eventi attraverso i quali tutto accade.
Stiamo parlando di mq5?
Quindi stiamo parlando della stessa cosa.
Dal ramochiamato "Errori, bug, domande":
Un problema molto tipico per l'inizio della progettazione: come organizzare (strutturare) la gestione degli eventi in un programma in modo che esso (il programma) possa essere ulteriormente sviluppato e allo stesso tempo sia minima la rielaborazione di ciò che è già stato fatto.
Vuoi discutere delle opzioni?
In generale, questo è un problema più globale e non riguarda solo l'organizzazione di un buon modello di evento. Molto dipende dalla lingua stessa. Purtroppo, i mezzi linguistici di MQL5 sono al livello degli anni '80 del secolo scorso. I moderni standard di programmazione sono molto lontani dai principi originali di programmazione OOP. Oggi la decomposizione è preferibile all'ereditarietà, il polimorfismo è assicurato da collegamenti orizzontali non gerarchici a livello di interfaccia, e il riutilizzo del codice è assicurato da ricche collezioni di librerie standard, design decomposto e inclusione trasparente di build di terze parti nel progetto.
Esiste una letteratura per esempio?
In particolare su questo argomento:
Quale lingua considera come un modello (in termini di modernità e usabilità)?
Java/C#
E non si tratta nemmeno del mio pregiudizio (anche se non ne sono esente), ma perché questi linguaggi sono il prodotto finale di una lunga evoluzione della tecnologia di programmazione. Sono stati creati nel nostro tempo e si sono basati sull'esperienza dei loro predecessori.
Prima di scrivere un grande progetto, è una buona idea stabilire una chiara infrastruttura stabilita per sostenere il progetto:
Esiste una letteratura per esempio?
Certo che c'è.
// Ma non dimentichiamo che la comunicazione dal vivo è a volte molto (ordini di grandezza) più efficace per l'apprendimento che i libri (anche quelli buoni).
--
Il libro è stato molto utile un tempo (primi anni 90):
B.Liskov, J.Gatag. "Usare astrazioni e specifiche nello sviluppo del software".
Da esso, ho imparato bene il punto principale della programmazione orientata agli oggetti, che non è la possibilità aggiuntiva di tagliare il programma in comodi "cubi" - questo è solo una comodità aggiuntiva di accompagnamento. Il punto principale è l'astrazione dei dati.
Tu pensi in modo orientato agli oggetti, io penso in modo funzionale )
1. L'astrazione procedurale (algoritmica) è una caratteristica della programmazione funzionale. L'entità di astrazione è la procedura (funzione). Permette di separare una richiesta di eseguire un'azione o un calcolo dalla sua implementazione. Il codice della funzione è isolato in un blocco separato (procedura, funzione), a questo codice si fa riferimento tramite il disaccoppiamento dei parametri formali/reali (questa è l'essenza e la caratteristica principale dell'approccio procedurale). Il programma è in grado di rimanere invariato quando è necessario cambiare il modo (algoritmo) di calcolo o di azione (per esempio, scrivere su un file).
Ma se un programma ha bisogno di cambiare qualsiasi struttura di dati di base (array globali per esempio), avrà bisogno di riscrivere molte procedure che lavorano con questi dati. -- Questa è una limitazione di base dello stile di programmazione procedurale.
2) Astrazione dei dati - incapsulamento delle strutture di dati di base (insieme alle operazioni di base su di essi) in entità separate ("classi"), in conformità con la regola fondamentale: mai riferirsi ad essi (dati incapsulati) direttamente, ma solo ed esclusivamente attraverso le funzioni della stessa classe, appositamente create per loro ("interfaccia"). Così, si ottiene l'astrazione della forma di memorizzazione dei dati dai modi di trattare questi dati.E c'è un'opportunità senza precedenti (nella programmazione procedurale) - sviluppare un programma senza preoccuparsi in anticipo dei modi di rappresentazione dei dati. Poiché i dati sono accessibili attraverso un'interfaccia standard immutabile, è possibile migliorare i modi di rappresentazione dei dati in qualsiasi fase dello sviluppo del progetto, e questo cambiamento non comporta la necessità di cambiare altre parti del progetto. Nella programmazione procedurale era impossibile - la struttura di base dei dati determinava strettamente i modi della loro elaborazione.
Mi hanno anche insegnato a disegnare su carta, un linguaggio algo semplificato, prima di scrivere il programma, ma non mi ci sono mai abituato.
Al giorno d'oggi, nessun programmatore normale disegna diagrammi di flusso. Sono tutte sciocchezze teoriche progettate per insegnare agli scolari, ma non per lavorare in progetti reali.
Disegno su carta, è più comodo per me, a volte ci vogliono fino a 50 fogli fino a quando non emerge una struttura chiara. Si possono, naturalmente, usare editor speciali, ma ognuno di loro per me è scomodo (limitato), impossibile realizzare un volo di fantasia, insomma rallentano il lavoro.
E cosa succederà alla vostra chiara struttura se nel mezzo, o anche più vicino alla fine del progetto, il cliente cambierà improvvisamente:
Questo è un buon test per vedere quanto il vostro progetto è pronto e resiliente al cambiamento. In pratica, bisogna sempre fare i conti con i cambiamenti dei requisiti iniziali. È quindi meglio abbandonare del tutto il paradigma "Provvedere a tutto" per il paradigma "Compito - Soluzione".