Il mio approccio. Il nucleo è il motore. - pagina 18
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
No, mentre stiamo discutendo di programmazione casuale, sto trascinando la coperta a OOP, il topic-starter sta ancora tenendo duro! Scrive che tutto può essere tenuto nella sua testa - bene, programmazione casuale)))
Core-engine
Programmazione casuale )))
Programmazione casuale :)
Programmazione casuale :)
Forse hai ragione, ricordo il termine - un paio di mesi fa su un altro forum un tizio si è definito un programmatore casuale, ho anche cercato di chiarire cosa potesse significare, la mia conoscenza della parola casuale è associata solo al gioco Android - "Zuma", si è scoperto che è un programmatore che programma a caso - di occasione in occasione ))))
OOP è una metodologia molto flessibile, quindi non ha idee a priori come il concetto di "kernel". Tuttavia, il modello di kernel in questione può benissimo essere costruito usando OOP. Pertanto, l'affermazione non è del tutto corretta.
No, l'OOP non c'entra affatto. Il kernel è Unix, assembliamo tutto intorno al kernel; la shell è tutto ciò che è come Windows, togliamo il superfluo e lavoriamo con il resto. In generale, si tratta di un sistema operativo.
Programmazione cajun :)
Cajual, non preoccuparti.
Ciò che mi ripugna dell'OOP è il formato rigido della scrittura del codice. Come avete visto, tendo a fare grandi tabelle di dati e lo trovo molto pratico. In OOP devo aderire a un mucchio di regole, che personalmente trovo molto vincolanti.
In breve, programmo con una OOP diversa. Il mio. Ci sono poche regole e molta libertà. La funzionalità stessa è impilata in grandi blocchi, e i dati sono organizzati in kernel. Non penso nemmeno appositamente alla loro struttura. Tutto si sviluppa da solo. A livello intuitivo.Peter, queste regole sono quelle di cui tu stesso hai bisogno. Ecco perché ti stanno "irrigidendo". In modo da non incasinarsi accidentalmente ed entrare in qualcosa che non si dovrebbe fare. In effetti, lo stile OOP è "regole della strada" - ovviamente, limitano il conducente. E in un villaggio con tre cantieri - nessuno li guarda, è più facile e veloce (più efficiente). Tuttavia, in una grande città, è il contrario - sono le regole del traffico che permettono i collegamenti più efficienti. È lo stesso con l'AOP. Sono le regole che permettono di costruire grandi sistemi complessi nel modo più efficiente.
Nel tuo sistema - semplicemente non c'è stato ancora nessun cambiamento, è molto limitato nell'uso e non ha bisogno di modifiche. Ecco perché puoi tenerlo nella tua testa. Va bene se il sistema riceve utenti e ha bisogno di modifiche - la mancanza di controllo e incapsulamento sarà abbastanza stressante.
Tutto il resto - nessuna differenza, OOP e il tuo stile (come detto, hai anche lo stile procedurale - soffre anche degli stessi difetti - variabili globali, mancanza di controllo dei tipi, e così via) sono altrimenti vicini.
In difesa del tuo stile hai bisogno di dimostrare l'unica cosa - che mantenere l'intero sistema in un enorme array globale con accesso arbitrario è meglio che rompere il programma in un mucchio di piccole parti annidate in catene di eredità con accesso polimorfico, e nascoste dall'incapsulamento.
A proposito, ci sono persone sul forum a cui non piace l'eredità - penso che potrebbero sostenerti.
Un altro vantaggio dell'uso di OOP, rispetto al metodo di Peter. In OOP, il programmatore non ha bisogno del codice sorgente della classe base e non ha bisogno di capire come funziona. Per estendere o cambiare la funzionalità della classe base, è sufficiente creare un erede di questa classe.
Se usate il metodo di Peter, il programmatore deve capire tutto il lungo codice, e se non c'è un codice sorgente, dovrete scriverlo da zero.
Tutto il resto - nessuna differenza, OOP e il tuo stile (come già detto, hai uno stile procedurale - soffre anche degli stessi inconvenienti - variabili globali, mancanza di controllo dei tipi, e così via) sono altrimenti vicini.
Potrei sbagliarmi, e cercare su Google è troppo pigro, ma lo stile procedurale implica una completezza logica di una procedura (funzione) - "svitarla" dal sorgente e usarla in altro codice, cioè le funzioni MQL integrate prendono dati come parametri e restituiscono il risultato.... e qui, Piotr è caduto su entrambi i piedi )))) - Lo scambio attraverso variabili dichiarate globalmente riduce la portabilità del codice e permette bug difficili da tracciare ;)
Tutto a posto. Diciamo che sono convinto.
In linea di principio, ho capito tutto questo da molto tempo. E sono d'accordo. Tuttavia, allo stesso tempo, preferisco il mio approccio. Perché?
C'è una ragione particolare:
SVILUPPO DEL PROGRAMMA.
//---------------------------------------
Quanto velocemente si svilupperà il programma con OOP e con il mio approccio? Quale approccio è più favorevole alla crescita e alla complicazione dei meccanismi?
Ho concluso che il mio approccio + la lingua madre nel codice (60% russo e 40% di inglese), danno una crescita rapida massima del programma.
Proprio questa rapida crescita è ciò di cui ho bisogno. Non scavando nei dettagli. Non solo passando sopra ogni linea di codice. Non è un approccio professionale.
Volevo che il programma si sviluppasse rapidamente e diventasse più complesso. Che i meccanismi sarebbero stati creati per svolgere le funzioni loro assegnate. Facile e veloce.
In modo da poter aggiungere nuove funzionalità con poche righe di codice.
Il mio approccio è superiore all'OOP nel risolvere questo particolare compito.