Il mio approccio. Il nucleo è il motore. - pagina 14
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
Il formato è semplice, ma non è un lavoro in corso. Intendo quando ci sono molte proprietà negli oggetti.
Ecco un esempio del tuo approccio, effettivamente utilizzato, i principi sono gli stessi. Parsing lessicale del testo, è molto difficile fare qualcosa manualmente. Solo automazione. E non dire che è conveniente.
L'array di prototipi mostrato è il risultato dell'inizializzazione manuale delle proprietà dell'oggetto con valori predefiniti. È visto solo dallo sviluppatore.
Kernel principale - è compilato automaticamente dai prototipi di elementi. Poi i prototipi vengono convertiti in elementi concreti. Anche automaticamente.
Per quanto riguarda il lavoro con il costruttore, ci sono semplici parole chiave e una comoda forma di disegno. Non ci sono queste tabelle.
Ecco un altro esempio che si adatta alla tua idea, solo un sacco di elementi dinamici. Ci sono intere strategie, tre nell'esempio. Non c'è molta convenienza qui. Nel file allegato.
Cioè, per mantenere la dimensionalità dell'array, alcuni dei vostri oggetti hanno proprietà false. È molto flessibile, non si può dire nulla al riguardo.
Ahimè, dobbiamo sopportare temporaneamente questo inconveniente. D'altra parte, un kernel bidimensionale fornisce un accesso estremamente comodo e veloce, costruendo loop e molto altro. Se fate un kernel unidimensionale, non ci saranno proprietà "false". Ma la convenienza diventerà molte volte inferiore. Oppure, potreste semplicemente mettere le proprietà del testo e dell'icona in una serie di proprietà Core. E il problema sarà eliminato. Lo farò in futuro.
Ecco un altro esempio che si adatta alla tua idea, solo un sacco di elementi dinamici. Ci sono intere strategie, tre nell'esempio. Non c'è molta convenienza qui. Nel file allegato.
Ho inizialmente avvertito i lettori che il mio approccio non è finalizzato alla comodità di un programmatore. Offro la concezione del più potente e veloce sviluppo di un programma.
Naturalmente, si dirà che lo sviluppo più veloce di un programma è quello di inserire blocchi già pronti. Sì, ma la qualità del programma scende e le spese generali crescono. Unire i blocchi non è la soluzione migliore in termini di efficienza.
Inizialmente ho avvertito i lettori che il mio approccio non è focalizzato sulla facilità di programmazione. Offre il concetto di sviluppo più potente e veloce di un programma.
È conveniente quando il programmatore non modifica/crea direttamente tali dati.
Usare il codice che lavora con questi dati è abbastanza comodo.
Inizialmente ho avvertito i lettori che il mio approccio non è focalizzato sulla facilità di programmazione. Offre il concetto del più potente e veloce sviluppo di programmi.
Come possono coesistere insieme questi due punti: mancanza di comodità per il programmatore e sviluppo veloce del programma? Come si può sviluppare un programma rapidamente, se non è conveniente farlo?
Qual è il problema del controllo? Aggiungete una proprietà e aumentate la dimensione delle righe del kernel. Questo è tutto.
E cosa farete se sarà necessario fare un pulsante non rettangolare, ma circolare o triangolare?
Se usate OOP, creerete una classe base Button, che ha un metodo astratto Draf - questo metodo è responsabile del disegno dei pulsanti. Per un pulsante rotondo, dovrete creare un erede di Button, che sarà sufficiente per sovrascrivere il metodo Draf, che implementerà il disegno del pulsante rotondo. Per un pulsante rettangolare, basterà anche creare un erede di Button e sovrascrivere il metodo Draf per disegnare un pulsante rettangolare.
Come sarebbe il tutto se usassi il tuo metodo?
Ecco un altro esempio che si adatta alla tua idea, solo un sacco di elementi dinamici. Ci sono intere strategie, tre nell'esempio. Non c'è molta convenienza qui. Nel file allegato.
Impossibile!
È una cosa bellissima... è un automa impilabile.
con una conoscenza minima di assembler e Forth, è un gioco da ragazzi. Se ci fossero dei commenti, non sarebbe più complicato di MQL.
Questo è utile quando il programmatore non modifica/crea direttamente tali dati.
Usare il codice che lavora con questi dati è abbastanza comodo.
Vedrete che un array di prototipi viene creato una volta sola. E poi, viene cambiato MOLTO raramente. Solo in caso di serie modifiche del programma.
Impossibile!
È una cosa bellissima, una macchina a pila chiara.
Se conoscete il meno possibile l'assembler e il Forth, si legge in un attimo. Se ci fossero dei commenti, non sarebbe più complicato di MQL.
È un bell'aggeggio). Siete d'accordo che è più facile scrivere programmi in MQL che in assembler. Sto parlando di usabilità, efficienza.