Il mio approccio. Il nucleo è il motore. - pagina 138
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
"Espandere il potenziale creativo dei sostenitori di OOP", Vereshchagin, Tela, Olio
Grazie a tutti voi per i post informativi.
Oggi testeremo la comunicazione tra l'EA e il motore tramite risorse. L'ho appena completato. Dovrebbe funzionare anche nel tester.
State lavorando con la classe CCanvas. È l'unico nel vostro sviluppo.
La classe fa parte del sistema. Se è UNO, non c'è sistema.
Allora perché creare oggetti di classe e fare riferimento alle sue funzioni secondo le regole OOP?
PRATICAMENTE non avete bisogno di OOP nel trattare una sola classe.
Ma voi usate l'OOP nel trattare con UNA classe. Non c'è bisogno di OOP, però.
Peter, in OOP, gli oggetti classe sono creati in modo da poter lavorare con più oggetti che non dipendono l'uno dall'altro. Quando si lavora con CCanvas e si ha un solo grafico tutto va bene, OOP non è davvero necessario qui. Ma quando hai bisogno di visualizzare diversi grafici in aree diverse, è difficile da fare senza OOP e creare istanze multiple di CCanvas.
O un altro esempio. Recentemente mi è stato chiesto di modificare un Expert Advisor procedurale in modo che potesse fare trading su diversi simboli simultaneamente (in esecuzione su un grafico). Lo stile procedurale avrebbe richiesto sforzi lunghi e complessi per farlo commerciare indipendentemente su diversi simboli allo stesso tempo. Al contrario, ho semplicemente messo l'intero codice procedurale in una classe e creato tre esemplari. Ho specificato un set individuale di impostazioni per ciascuno di essi, compreso il simbolo di lavoro, ecc. Il codice ha funzionato correttamente al primo tentativo. Il codice ha funzionato come avrebbe dovuto al primo tentativo. L'utente era soddisfatto.
Anche tu stai usando OOP nel tuo kernel. Anche se lo fai implicitamente:
Per non essere infondato, permettetemi infine di darvi un esempio di questo stesso "nocciolo". Più precisamente, è un file di avvio. Ci sono diversi nuclei in esso.
Vi ricordo che viene stampato automaticamente, in base al codice KIB. Poi messo nel motore. Poi, il motore lavora con esso.
Ogni vostro kernel è un'istanza di una classe in termini OOP. Comunque lo si chiami, ma è un elemento di OOP. Ma purtroppo questo elemento è autocostruito e inferiore in potenza concettuale a quello che è già stato inventato e lucidato da migliaia di menti inesperte.
Cosa, voi gente, tutti a convincere Peter dei benefici dell'OOP?
Non lo convincerai! Se aveste una memoria come la sua, vi chiedereste perché tutta questa roba OOP è così complicata quando si può fare tutto in modo molto più semplice? Rendiamo tutte le variabili globali, accesso diretto da ogni luogo, niente divieti e restrizioni - bello!
È per coloro che nella loro debole mente possono dimenticare ciò che hanno scritto dieci anni fa - è necessario che il compilatore e il linguaggio lo limitino in ogni modo. E quando ti ricordi esattamente perché e perché hai scritto questo o quel costrutto nel tuo codice, che ha molti anni - OOP è solo la quinta ruota del carro.
Il problema di Peter non è nella scelta "OOP o approccio procedurale", il problema di Peter è nel pubblico di destinazione. La mancanza di persone che, da un lato, sono brave a programmare e, dall'altro, preferiscono scambiarsi le mani. Io non osservo tali persone.
1. Esattamente. Un numero limitato di elementi può essere prescritto nel costruttore. Quindi, una tabella dinamica deve consistere in un numero limitato di righe, ma allo stesso tempo, essere illimitata. La soluzione sta solo nel creare array speciali per i parametri aggiunti e scorrere i loro valori attraverso le celle della tabella.
2. Sì. Il costruttore crea il kernel per il motore in base al codice che hai citato. + stampa i file di connessione. Poi, ho messo il kernel nel motore (DRIVE). Dopo di che, il motore può riprodurre la GUI desiderata. I file di accoppiamento sono collegati all'EA e iniziano a interagire con esso.
Si scopre che ogni volta per una nuova gui si devono fare dei cambiamenti nel motore (fornire il kernel GUI appropriato). Penso che questa sia una soluzione fondamentalmente sbagliata. Immaginate che ci siano centinaia di utenti del vostro motore. Ma il motore ospitato nel Mercato o altrove è solo uno. Come farete in questo caso? Per ogni utente di mettere un motore specifico, che deve scaricare da solo? Come si prepara il nucleo della gui per il motore? Fornirà ad ogni utente un motore individuale? - Questo diventerà rapidamente un incubo. Quindi la vostra soluzione non è scalabile.
Peter, in OOP, gli oggetti classe sono creati in modo da poter lavorare con più oggetti che non dipendono l'uno dall'altro. Quando si lavora con CCanvas e si ha un solo grafico tutto va bene, non si ha davvero bisogno di OOP qui. Ma quando hai bisogno di visualizzare diversi grafici in aree diverse, è difficile da fare senza OOP e creare istanze multiple di CCanvas.
O un altro esempio. Recentemente mi è stato chiesto di modificare un Expert Advisor procedurale in modo che potesse fare trading su diversi simboli simultaneamente (in esecuzione su un grafico). Lo stile procedurale avrebbe richiesto sforzi lunghi e complessi per farlo commerciare indipendentemente su diversi simboli allo stesso tempo. Al contrario, ho semplicemente messo l'intero codice procedurale in una classe e creato tre esemplari. Ho specificato un set individuale di impostazioni per ciascuno di essi, compreso il simbolo di lavoro, ecc. Il codice ha funzionato correttamente al primo tentativo. Il codice ha funzionato come avrebbe dovuto al primo tentativo. L'utente era soddisfatto.
Anche voi state usando OOP nel vostro kernel. Anche se lo fai implicitamente:
Ogni vostro kernel è un'istanza di una classe in termini OOP. E comunque lo si chiami, è un elemento di OOP. Ma purtroppo questo elemento è autocostruito e cede nella sua potenza concettuale a ciò che è già stato inventato e lucidato da migliaia di menti inesperte.
Vasily, capisco perché le funzioni di disegno sono fatte in una classe. Perché ci sono altri insiemi di funzioni oltre a loro.
Ma la mia domanda era un po' diversa. Perché, esattamente, Nikolai avrebbe usato chiamare le funzioni di disegno attraverso una classe, se non ha usato altre classi. Lui disegna soltanto.
Il punto della domanda era esattamente questo.
Ho sottolineato l'inutilità di questa azione in termini di logica, e che lui non ne è consapevole.
Ho anche sottolineato che l'uso di OOP è spesso irragionevole per la dimensione dei compiti da risolvere. Dopo tutto, l'OOP richiede una classificazione ramificata, e se non c'è una tale classificazione, vale la pena crearla di proposito?
Il punto è che lo sviluppatore dovrebbe essere guidato dai requisiti dei meccanismi, non dagli strumenti.
Peter, in OOP, gli oggetti classe sono creati in modo da poter lavorare con più oggetti che non dipendono l'uno dall'altro. Quando si lavora con CCanvas e si ha un solo grafico tutto va bene, non si ha davvero bisogno di OOP qui. Ma quando hai bisogno di visualizzare diversi grafici in aree diverse, è difficile da fare senza OOP e creare istanze multiple di CCanvas.
O un altro esempio. Recentemente mi è stato chiesto di modificare un Expert Advisor procedurale in modo che potesse fare trading su diversi simboli simultaneamente (in esecuzione su un grafico). Lo stile procedurale avrebbe richiesto sforzi lunghi e complessi per farlo commerciare indipendentemente su diversi simboli allo stesso tempo. Al contrario, ho semplicemente messo l'intero codice procedurale in una classe e creato tre esemplari. Ho specificato un set individuale di impostazioni per ciascuno di essi, compreso il simbolo di lavoro, ecc. Il codice ha funzionato correttamente al primo tentativo. Il codice ha funzionato come avrebbe dovuto al primo tentativo. L'utente era soddisfatto.
Anche voi state usando OOP nel vostro kernel. Anche se lo fai implicitamente:
Ogni vostro kernel è un'istanza di una classe in termini OOP. E comunque lo si chiami, è un elemento di OOP. Ma purtroppo questo elemento è autocostruito e cede nella sua potenza concettuale a ciò che è già stato inventato e lucidato da migliaia di menti incompetenti.
State perdendo il vostro tempo. In primo luogo, il tuo esempio con il consigliere di Perth è un cataplasma - non sa scrivere gli esperti, non capisce cosa c'è e qual è il punto, e non può capire il tuo esempio molto chiaro - vedrai, lui, battendo gli occhi, ti dirà la stessa cosa che ha detto a Nikolay. In secondo luogo, gli darete una scusa per spingere il naso ancora più in alto, dicendo che ha fatto un codice super-unico nel suo secchio da solo, senza l'aiuto di migliaia di menti precedenti, con una soluzione eccezionale migliore di qualsiasi soluzione precedente. Vedrai - è esattamente così che posizionerà il suo unico secchio con i cursori...
ZS. Forse mi sono espresso duramente, ma ho pochissima tolleranza per la stupidità impenetrabile.
Ogni vostro kernel è un'istanza di una classe in termini OOP. E non importa come lo chiamate, è un elemento di OOP. Ma purtroppo questo elemento è autocostruito e cede nella sua potenza concettuale a ciò che è già stato inventato e lucidato da migliaia di menti incompetenti.
Così è. Ma c'è comunque una differenza significativa. Per quanto mi riguarda, da Peter - in questo esemplare di classe - quasi tutto è disponibile. E questo non rientra nel paradigma di incapsulamento dell'OOP. Inoltre, ci sono variabili globali.
Quindi qui - solo "elementi di OOP".
Ma ho paura che alla gente non piacerà il contrario - sono sicuro, Vasily, che quando lancerò il mio progetto OOP, al contrario, la gente urlerà che "non si può fare nulla con questa interfaccia, tranne ciò per cui è stata pensata" :)
Si scopre che ogni volta che si fa una nuova gui, bisogna fare delle modifiche al motore (dotarlo del kernel GUI appropriato). Penso che questa sia una soluzione fondamentalmente sbagliata. Immaginate che ci siano centinaia di utenti del vostro motore. Ma il motore ospitato nel Mercato o altrove è solo uno. Come farete in questo caso? Per ogni utente di mettere un motore specifico, che deve scaricare da solo? Come si prepara il nucleo della gui per il motore? Fornirà ad ogni utente un motore individuale? - Questo diventerà rapidamente un incubo. Quindi la vostra soluzione non è scalabile.
No, Vasily, tu tendi a drammatizzare tutto).
C'è un pulsante nel designer che, se cliccato, stampa tutti i file.
E il motore caricherà i kernel da un file di testo. Non è difficile da fare.
Peter, hai davvero frainteso qualcosa sull'applicazione dell'OOP.
È una forma speciale di coscienza, non impedirle di evolvere