OOP vs programmazione procedurale - pagina 27
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
Nella programmazione funzionale-procedurale, i problemi di accesso che descrivi non esistono. Senza funzioni di overloading, senza campi e oggetti, senza puntatori e cose del genere, quando si ha solo una memoria per tutte le variabili globali a cui si può accedere da qualsiasi luogo, come può essere chiamata la funzione sbagliata? Che tipo di errori di accesso possono verificarsi? Ed è molto più facile ricordare tutto.
Si tratta di un semplice errore: fare riferimento alla variabile sbagliata che contiene un valore vicino.
Un tale errore può rimanere inosservato per molto tempo, ma, per la legge della meschinità, "salta fuori" proprio nel momento in cui il lavoro senza errori in questo luogo sarebbe molto necessario!
E sarà oh così difficile da capire... Stai cercando di capire perché l'Expert Advisor ha chiuso un trade in un buon trend quando TS non avrebbe dovuto chiuderlo - e non ci riesci. Tutto sembra funzionare correttamente.
Questo è esattamente uno degli errori più sgradevoli - la non inizializzazione delle variabili, o l'indirizzamento di quella sbagliata, ma vicina per valore. E più variabili sono disponibili in questa o quella parte del programma - maggiore è la probabilità di questo errore.
Sì, certo, se avete un nucleo grafico globalmente accessibile, e lavorate con gli ordini, è davvero difficile accedere alla variabile sbagliata. Ma in un blocco precedente dove si rileva la necessità di aprire un ordine e di indirizzare gli indicatori per questo scopo e probabilmente secondo le azioni dell'utente - è abbastanza reale confondere le variabili.
Se ci sono più strutture, e dettagli importanti scompaiono periodicamente dalla memoria - si arriva alla conclusione che l'accesso globale - è una fonte di problemi, e si dovrebbe evitare di usarlo a tutti i costi. E che il codice dovrebbe essere scritto in modo tale da ricordare il meno possibile. Idealmente, non tenere nulla in memoria - ogni blocco ha un nome, che indica la sua funzione, all'ingresso riceve i dati necessari e sufficienti per questa funzione, tutto ciò che rimane è implementare la funzione senza coinvolgere altre conoscenze "dall'esterno".
Si tratta di un semplice errore: fare riferimento alla variabile sbagliata che contiene un valore vicino.
Un tale errore può rimanere inosservato per molto tempo, ma, per la legge della meschinità, "salta fuori" proprio nel momento in cui il lavoro senza errori in questo luogo sarebbe molto necessario!
E sarà oh così difficile da capire... Stai cercando di capire perché l'Expert Advisor ha chiuso un trade in un buon trend quando TS non avrebbe dovuto chiuderlo - e non ci riesci. Tutto sembra funzionare correttamente.
Questo è esattamente uno degli errori più sgradevoli - la non inizializzazione delle variabili, o l'indirizzamento di quella sbagliata, ma vicina per valore. E più variabili sono disponibili in questa o quella parte del programma - maggiore è la probabilità di questo errore.
Sì, certo, se avete un nucleo grafico globalmente accessibile, e lavorate con gli ordini, è davvero difficile accedere alla variabile sbagliata. Ma in un blocco precedente dove si rileva la necessità di aprire un ordine e di indirizzare gli indicatori per questo scopo e probabilmente secondo le azioni dell'utente - è abbastanza reale confondere le variabili.
Se ci sono più strutture, e dettagli importanti scompaiono periodicamente dalla memoria - si arriva alla conclusione che l'accesso globale - è una fonte di problemi, e si dovrebbe evitare di usarlo a tutti i costi. E che il codice dovrebbe essere scritto in modo tale da ricordare il meno possibile. Idealmente - non immagazzinare assolutamente nulla in memoria - ogni blocco ha un nome, che indica la sua funzione, in ingresso riceve i dati necessari e sufficienti per questa funzione, rimane solo da implementare la funzione, non coinvolgendo qualsiasi altra conoscenza "dall'esterno".
Beh, come puoi chiamare la variabile sbagliata, se hanno tutti nomi diversi? Come può essere chiamata una funzione sbagliata se ha un nome unico e nessun sovraccarico? All'interno della matrice del kernel tutti gli indici delle celle sono nominati con parole umane. Cosa si può confondere qui? Capite, i problemi di cui parlate non esistono affatto.
Tengo solo la struttura del kernel in memoria, che è molto semplice. Conosco anche l'elenco delle proprietà degli oggetti. Tutti gli oggetti hanno le stesse proprietà, solo i valori sono diversi. Ho un totale di 140 proprietà, ma tengo in memoria solo le più importanti, circa 30. Il resto me lo ricordo quando ne ho bisogno. Per fare questo, apro un file con le definizioni e guardo l'elenco completo delle proprietà. Niente di complicato. Le variabili globali a fuoco, come per esempio "OBJECT" o "WINDOW" non hanno bisogno di essere ricordate. Ed è impossibile confonderlo con qualcos'altro.
Le mie variabili hanno nomi significativi in russo. Si possono confondere le cose solo dopo una festa selvaggia).Le mie variabili globali sono le variabili usate nel focus, che sono 'mirate' al kernel e spostate in giro quando il cursore si muove.
Per esempio: la variabile "WINDOW" porta costantemente il numero della finestra in cui si trova il cursore. La variabile "OBJECT" è il numero di quell'oggetto dove si trova il cursore.
Mi rivolgo a una particolare finestra, oggetto e proprietà nel kernel attraverso di loro - G_CORE[WINDOW][OBJECT][_NAME] o G_CORE[WINDOW][OBJECT][_OBJECT_GROUP]. In qualsiasi funzione, se voglio la coordinata X di un oggetto, la ottengo da G_CORE[WINDOW][OBJECT][_X], se voglio l'altezza di un oggetto - da G_CORE[WINDOW][OBJECT][_Y_SIZE] ecc.
In tutto, ho un centinaio di variabili globali dichiarate separatamente, ma ce ne sono migliaia nell'array globale del kernel, perché ogni cella dell'array è una variabile. Tuttavia, è molto facile gestire questo numero di variabili, perché sono ordinate. Ogni finestra nel kernel è un campo array; ogni riga è un oggetto, che consiste di 140 proprietà. Gli elementi, in questo caso, sono insiemi di oggetti. Ogni elemento ha un oggetto master, che contiene le proprietà principali dell'intero elemento. Gli oggetti che appartengono ad ogni elemento sono collegati da indici speciali in modo che qualsiasi oggetto venga messo a fuoco, anche l'elemento a cui appartiene viene messo a fuoco. Così come la tela su cui è disegnata. Grazie all'archetipo esplicito del kernel e all'accesso diretto da qualsiasi funzione, posso gestire migliaia di variabili che sono rappresentate da celle di array del kernel senza dimenticare nulla e senza doverci navigare intorno.
Una conversazione completamente inutile: non esiste un criterio per classificare il codice come "buono" o "cattivo". Questo è il motivo per cui non è chiaro su OOP.
Per me, tale criterio è la FATTIBILITÀ del codice, che si manifesta nel fatto che l'autore o una terza parte può leggere il codice e usarlo per la modifica, cercando i bug dopo un periodo di tempo abbastanza lungo.....
Qui sopra Fedoseyev ha sostituito l'interruttore OOP. Questo particolare esempio, forse sfortunato, per me è una prova della cattiveria dell'OOP: un codice chiaro con un interruttore di 100 posizioni è sostituito da una sola linea. Per capire questa linea bisogna andare da qualche parte. Non è ammissibile per me.
Il secondo esempio qui sopradi George Merts
Quando il codice chiaro è stato sostituito da un codice NON chiaro dopo il debug. Secondo il mio criterio il codice di qualità (facile da leggere) è stato sostituito dal codice che non è accettabile per me.
Ecco perché ho una domanda per tutti i sostenitori di OOP: un programma diventa più vivido quando si applica OOP e l'esempio dato da Fedoseyev sullo switch è un fallimento o al contrario, l'esempio di Fedoseyev caratterizza molto accuratamente OOP e OOP porta quasi sempre a una perdita di vividezza?
Bene, tutto è chiaro con CC. Tutto ciò che è al di sopra del livello della sua comprensione è sgradevole. Ma conosce la lettera R ))))))))))))))
Bene, il CC è chiaro. Qualsiasi cosa al di sopra del suo livello di comprensione è poco attraente. Ma conosce la lettera R ))))))))))))))
Aggiungerò il cinese, forse il giapponese...
Perché l'OLP? PERCHE' sarebbe meglio?
La visibilità serve a semplificare il debug, la modifica. La visibilità viene da un'attenta progettazione del programma, dalla strutturazione in FUNZIONI e non in OGGETTI, perché tutto il mondo è basato su azioni su oggetti, ma non viceversa.
Quando la ripartizione in funzioni è derivata dalla sequenza di conversione degli input in output. Per esempio, convertire un input BUY|SELL in un output è possibile solo specificando un ACTION.
È così che funziona il pensiero umano.
PS.
Per quanto riguarda il suo commento su R.
Vuoi fare del sarcasmo?
Rispondo molto raramente, ma posso.
Come diavolo si può chiamare la variabile sbagliata se hanno tutti nomi diversi? Come può essere chiamata la funzione sbagliata se ha un nome unico e nessun sovraccarico? All'interno della matrice del kernel tutti gli indici delle celle sono nominati con parole umane. Cosa si può confondere qui? Capite, i problemi di cui parlate non esistono affatto.
Beh, ho avuto un paio di casi simili.
Il più delle volte questi errori si verificano quando si copia un pezzo di codice da un altro posto e lo si "aggiusta" secondo il blocco attuale. Se avete l'accesso globale - potreste non riuscire a cambiare una delle variabili. Se in questo caso avete accesso solo a ciò con cui dovete lavorare - allora dopo aver copiato - il compilatore stesso vi dà una lista di tutte le variabili e posizioni che devono essere cambiate.
Tag Konow:
Ho solo la struttura del kernel nella mia memoria, che è molto semplice. Conosco anche l'elenco delle proprietà degli oggetti. Le proprietà di tutti gli oggetti sono le stesse, solo i valori sono diversi. Ho un totale di 140 proprietà, ma tengo in memoria solo le più importanti, circa 30. Il resto me lo ricordo quando ne ho bisogno. Per fare questo, apro un file con le definizioni e guardo l'elenco completo delle proprietà. Niente di complicato.
30 proprietà sono inaccettabili per me. Non che non li ricordi, ma non voglio fare affidamento sulla mia memoria. Molto meglio, quando in ogni blocco - hai sempre esattamente quelle variabili, che in questo blocco devono essere elaborate, e non c'è accesso ad altre.
Ma mi stressa dover ricordare... E dato che non è difficile per te - è comprensibile che non abbia senso fare un inutile armeggiare OOP.
Beh, ho avuto un paio di questi casi.
L'errore più comune di questo tipo si verifica quando si copia un pezzo di codice da un altro posto e lo si "aggiusta" per farlo corrispondere al blocco attuale. Se avete un accesso globale, potreste non riuscire a cambiare una delle variabili. Se in questo caso hai accesso solo a ciò con cui devi lavorare - allora dopo la copia - il compilatore stesso ti dà una lista di tutte le variabili e posizioni che devono essere cambiate.
30 proprietà? Beh, questo non è accettabile per me. Non è che non li ricordi, ma non voglio fare affidamento sulla mia memoria. Molto meglio, quando in ogni blocco - avete sempre esattamente quelle variabili, che in questo blocco devono essere elaborate, e non c'è accesso ad altre.
Ma mi stressa dover ricordare... E dato che non è difficile per te - è comprensibile che non ci sia bisogno di fare inutili transazioni OOP.
Beh, francamente parlando, mi ricordo un sacco di cose. Basta guardare le abbreviazioni degli oggetti snapping _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C ecc... ognuno definisce la posizione di un oggetto rispetto all'altro. Questi si trovano nei parametri A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... Ricordo anche un paio di dozzine di nomi di categorie e sottocategorie di oggetti, un paio di dozzine di proprietà di finestre (più di 100). Ci sono decine di funzioni nel blocco di costruzione, per esempio, e occupano più di 4000 linee di codice. Bisogna navigare e ricordarne molti. Ma ricordare viene da una lunga pratica, non subito, ma gradualmente. La mia testa diventava pesante per la quantità di entità e le dimensioni del codice, ma poi tutto si è impantanato ed è diventato semplice.
Beh, francamente parlando, mi ricordo un sacco di cose. Le abbreviazioni dei riferimenti degli oggetti _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C, ecc. Ognuno definisce una certa posizione di un oggetto rispetto a un altro, sono nei parametri A1,B1,C1,A2,B2,C2,A3,B3,C3,A4,B4,C4,A5... Ricordo anche un paio di dozzine di nomi di categorie e sottocategorie di oggetti, un paio di dozzine di proprietà di finestre (più di 100). Ci sono decine di funzioni nel blocco di costruzione, per esempio, e occupano più di 4000 linee di codice. Bisogna navigare e ricordarne molti. Ma ricordare viene da una lunga pratica, non subito, ma gradualmente. La mia testa si gonfiava con il numero di entità e la dimensione del codice, ma poi tutto si è impantanato ed è diventato semplice.
Per distrarmi, dimenticando tutto, andare in vacanza per un mese senza pensare al codice. Poi tornate, vedete tutti questi a1, b1, ecc. e diventate isterici :)
distrarsi, dimenticare tutto, andare in vacanza per un mese, senza pensare al codice. Dopo essere venuto, vedi tutti questi a1, b1, ecc. e diventa isterico :)
Ad esempio, ecco come appare l'elemento "checkbox" nel proto-core: