Il mio approccio. Il nucleo è il motore. - pagina 5
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
Comprereste un secchio di componenti radio invece di un televisore? Allo stesso modo, un kernel non ha bisogno di preoccuparsi dei dettagli. Ma dipende da voi, finché è conveniente - bene.
Il motore lavora con il Core usando una tecnica che chiamo"Focus Elements" (forse non è un buon nome).
L'idea è la seguente:
Spostando il cursore sul grafico, l'utente attraversa i confini degli oggetti. Ogni elemento ha il suo territorio nello spazio del grafico. Una funzione speciale controlla le coordinate del cursore e segna su quale finestra ed elemento si trova il cursore.
Il numero della finestra e dell'elemento nel kernel sono scritti nelle variabili globali. Poi il motore usa questi per accedere al kernel e recuperare tutti i valori correnti delle proprietà della finestra, dell'elemento e dell'oggetto dove si trova il cursore.
Quando si verifica un evento (click, push-down, doppio click, ecc...), il blocco che elabora questo evento sa immediatamente in quale finestra e con quale elemento è avvenuto questo evento.
Le proprietà principali della finestra, dell'elemento e dell'oggetto, sono già a fuoco (cioè già memorizzate nelle variabili globali), e utilizzate nel codice immediatamente.
Questo è molto efficace.
Questo è il motivo per cui il Kernel dovrebbe essere un semplice array globale....
Ecco perché il kernel dovrebbe essere un semplice array globale.Gli array di puntatori sono noti da tempo in natura.
Tanto sforzo per reinventare la ruota... È tutto lì e in una forma molto migliore.
La cosa divertente dell'OOP è che provoca un sacco di resistenza psicologica nelle persone. Anche quando non si devono scrivere le classi ma solo usarle.
Perché limitarsi a un solo kernel. In termini di questo approccio kernel, OOP è solo un generatore di kernel rabbioso.
Gli array di puntatori sono noti da tempo in natura.
Così tanta fatica da spendere per reinventare la ruota...
Vedete, tutto questo comporta l'uso di una sintassi extra, che non è praticamente necessaria. La soluzione non richiede questa sintassi e strumenti extra.
La soluzione può essere primitivamente semplice, ma è MOLTO efficace. Questo è esattamente quello che mi sto sforzando di fare.
Perché limitarsi a un solo kernel. In termini di questo approccio kernel, OOP è solo un generatore di kernel rabbioso.
Perché c'è l'OOP se la soluzione non lo richiede?
Finestre, elementi, oggetti sono rappresentati e ordinati nel Kernel. Vi si accede attraverso un indice di matrice o attraverso il focus di Elements.
Perché puntatori, riferimenti, classi, costruttori, distruttori e un milione di altre cose quando la Soluzione esiste già?
È semplice e autosufficiente.
Abbiamo bisogno di OOP per uno scopo molto diverso. Avrei bisogno di OOP se creassi questa tecnologia con un team di altri sviluppatori e ognuno di noi facesse solo una parte del lavoro.
OOP è per uno scopo completamente diverso. Avrei bisogno di OOP se creassi questa tecnologia con un team di altri sviluppatori, e ognuno di noi facesse solo una parte del lavoro.
Il Sig. Bene TC, diamo esempi dei tuoi pensieri in codice, discutiamo che OOP è "male" più tardi ... come si dice: Codici sul tavolo! )))
MA, OOP non è necessario quando c'è un solo programmatore e i suoi compiti non richiedono OOP.
Il Sig. Bene, diamo esempi dei tuoi pensieri in codice, discutiamo dopo del fatto che OOP è "male"... come si dice: Codici sul tavolo! )))
Sì, preparerò semplici esempi.
MA, OOP non è necessario quando lavora un solo programmatore e i suoi compiti non richiedono l'uso di OOP.
Entrambe le tesi sono false.