OOP vs programmazione procedurale - pagina 35
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
Attenzione, non stiamo parlando di variabili interne di MT, stiamo parlando di variabili interne dell'oggetto che avete isolato, impedendo la possibilità di leggere i loro valori durante il debug e la scrittura del codice...
È quello che sto dicendo - quando fate il debug di un EA - non avete bisogno delle variabili interne di MT?
Allo stesso modo, in questo caso, con l'oggetto trade processor - se state debuggando, per esempio, la metodologia di immissione degli ordini nel vostro TS - perché dovreste avere accesso alle variabili interne del trade processor?
Andrei è ancora più clinico di Peter o Sansanych, stai perdendo il tuo tempo.
I giovani hanno bisogno di essere istruiti.
Inoltre, forse c'è una ragione razionale in quello che dicono i miei avversari. Se avessi, diciamo, una memoria come quella di Peter, potrei anche non preoccuparmi dell'OLP.
È lo stesso in altri posti - se alcuni dati sono richiesti - allora questo blocco deve fornire l'interfaccia appropriata.
Questo è quello che voglio dire... Invece di vedere semplicemente il valore della variabile richiesta, dovete pensare a come attaccare un'interfaccia adatta ad essa e poi sganciarla di nuovo. :)
Sembra un'attività per masochisti della programmazione :)
Sì... non c'è niente di meglio di un cazzo :) L'idea è di avere un linguaggio di programmazione adeguato, per facilitare il debug e la scrittura del codice con gesti minimi, ma qui abbiamo una situazione completamente opposta...
Questa non è una "situazione opposta". È vero che OOP richiede un po' di lavoro extra. Tuttavia, è più che compensato dalla comodità del supporto e dalla modifica del sistema.
Anche qui - tornando al processore commerciale - è scritto e usato in molti TS. È l'isolamento dei suoi interni dal TS, e lavorare solo attraverso un'interfaccia virtuale permette di non pensare a quali variabili sono in esso e a cosa sono uguali. Se vengono rilevati errori, saranno all'interno del processore e sarà necessario correggerli all'interno di una classe reale, senza influenzare le classi TS. Se l'errore è nel TS stesso, non influenzerà le variabili del processore commerciale.
L'incapsulamento è in realtà una tecnica molto utile.
Sì... non puoi fare a meno di chiederti cosa diavolo hai fatto :) L'idea è di avere un linguaggio di programmazione adeguato, per facilitare il debug e la scrittura del codice con gesti minimi, ma qui abbiamo una situazione completamente opposta...
Il debugging è facilitato proprio dalla divisione di responsabilità in ogni classe: ogni classe è responsabile del proprio insieme di variabili. Nessun'altra classe ha il diritto di cambiare i propri valori. Di conseguenza, la maggior parte dei problemi sono già eliminati nella fase di compilazione. E l'accesso alle variabili da qualsiasi punto del programma può essere paragonato a una dozzina di volanti su una nave.
I giovani hanno bisogno di essere istruiti.
Inoltre, forse c'è una base razionale in quello che dicono i miei avversari. Se avessi, per esempio, una memoria come quella di Peter, non mi preoccuperei nemmeno dell'OOP.
1. Quanto è aumentata la redditività dei vostri consulenti utilizzando le OOP?
2. Quanto è diminuita la redditività dei vostri consulenti a causa dell'uso dei PPA?
Questo è quello che voglio dire... Invece di vedere semplicemente il valore della variabile richiesta, dovete pensare a come attaccare un'interfaccia adatta ad essa e poi sganciarla di nuovo. :)
Sembra un'attività per masochisti della programmazione :)
Vedete, sopra sull'argomento, Peter vi ha mostrato una delle sue strutture, non la più grande.
Riesci a capirlo facilmente?
Questo stesso "masochismo" è proprio quello che vi permette, in primo luogo, di non entrare nel codice funzionante e di non rovinarlo. E in secondo luogo permette di progettare immediatamente la struttura del sistema in modo da poter fornire i dati necessari nei blocchi corrispondenti del programma.
Sì, infatti, ci sono situazioni in cui ci si rende conto improvvisamente che è quasi impossibile ottenere i dati necessari. Sono nascosti dietro diverse interfacce virtuali. Tuttavia, questa situazione mostra chiaramente che il sistema è stato originariamente progettato in modo errato, non prevedeva la trasmissione di questi dati. Questa situazione è davvero molto spiacevole. O dobbiamo costruire frettolosamente delle "stampelle" sotto forma di interfacce aggiuntive, o ristrutturare l'intero sistema. Beh... Questo motiva il programmatore a pensare più attentamente all'architettura del sistema.
Se tu avessi meno emozione e riflessività e più specificità nell'essenza della discussione - non ne varrebbe la pena. :)
Non c'è più sostanza in questa discussione. Lei è fondamentalmente fluido e finge di essere ottuso.
Se un moderatore chiude le ultime due pagine come irrilevanti per l'argomento del thread e la programmazione in generale - sarà un raro caso in cui sosterrò le sue azioni.
1. Quanto è aumentata la redditività dei vostri EA usando le OOP?
2. Di quanto è diminuito il tasso di fallimento dei vostri consulenti grazie all'uso di OOP?
1. Non di quanto. La redditività non dipende dall'OOP.
2. Secondo me, di un ordine di grandezza (dieci volte). Ma il guadagno principale di OOP è nel supporto del codice. Ora sono molto veloce a capire il codice che ho scritto un anno o più fa. Ricordo bene come ho capito i miei primi programmi ANSI C in stile puramente procedurale. Era molto più difficile.
Il debugging è facilitato proprio dalla divisione di responsabilità in ogni classe: ogni classe è responsabile del proprio insieme di variabili. Nessun'altra classe ha il diritto di cambiare i propri valori. Di conseguenza, la maggior parte dei problemi sono già eliminati nella fase di compilazione. E l'accesso alle variabili da qualsiasi punto del programma può essere paragonato a una dozzina di volanti su una nave.
Non riesco a capire perché non ho MAI incontrato niente del genere nel mio lavoro. Perché i problemi di delimitazione dell'accesso alle variabili da parte di UNO sviluppatore in un programma non molto grande? Ci sarebbero 100 sviluppatori, ognuno dei quali scriverebbe 100 funzioni. Teoricamente, potrebbe essere inventato. Ma praticamente la programmazione si è evoluta in OOP per quasi 40 anni, sono state scritte montagne di codice e non si è mai sentito nulla di simile.