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
Sì, queste unità hanno entrambi. Ma credetemi - sono compressi al massimo e versatili, perché risolvono una vasta gamma di problemi.
Se non ci sono molte opzioni, puoi cavartela con if e swipe.
Perché nessuno ha deciso di discutere di "programmazione procedurale con puntatori di funzione vs. programmazione procedurale senza puntatori di funzione"?
Se non ci sono molte opzioni, puoi cavartela con if e swipe.
Реter Konow:
1. Дело в работе которую нужно провести чтобы сжать в коде решения огромного количества задач.
2. Il punto è l'universalizzazione del codice, in cui qualsiasi tecnica di sintassi e shell aggiuntiva è semplicemente distruttiva. È un lavoro duro, ma si sbarazza di tutto il superfluo e ti permette di evolvere sempre raggiungendo nuove vette.
1. Perché fare il lavoro quando puoi renderlo facile e semplice? Perché renderlo difficile quando si può renderlo facile?
2. Se si usa OOP, l'universalizzazione non è distruttiva, ma diventa una possibilità naturale che non grava su nulla.
1. Perché fare il lavoro quando può essere fatto facilmente e senza problemi? Perché fare qualcosa che può essere fatto facilmente quando è difficile?
2. Se si usa OOP, allora l'universalizzazione non è rovinosa, ma diventa una possibilità naturale che non grava su nulla.
Possiamo continuare a lungo con questo argomento. Utilizzando l'esempio di un compito di 100 tracce, ho mostrato il mio atteggiamento verso questo metodo di soluzione. Credo che i compiti stupidi non debbano essere risolti ma aggiustati. Se l'OOP aiuta coloro che sono più deboli nel sollevare e risolvere correttamente i compiti, che li aiuti. Ma per le persone che ottimizzano i compiti prima di iniziare a risolverli, OOP può semplicemente non essere necessaria.
Potremmo continuare all'infinito con questo argomento. Utilizzando l'esempio di un compito di 100 tracce, ho mostrato il mio atteggiamento verso questo metodo di soluzione. Credo che i compiti stupidi non debbano essere risolti ma aggiustati. Se l'OOP aiuta coloro che sono più deboli nel sollevare e risolvere correttamente i compiti, che li aiuti. Ma per le persone che ottimizzano i compiti prima di iniziare a risolverli, OOP può semplicemente non essere necessaria.
Non hai codificato molto (probabilmente), OOP è come una boccata d'aria.
La maggior parte delle persone codifica non per interesse o autosviluppo, è il loro lavoro, ed è il risultato che conta.
Non è così conveniente, ma in termini di capacità di velocità, si può andare avanti solo con i puntatori.
E la convenienza è un concetto relativo.
Dmitry, ovviamente usare OOP riduce un po' le prestazioni. Ma sono frazioni di percentuale.
Ma come OOP aumenta le prestazioni di un programmatore!
Ecco un piccolo esempio da uno dei miei progetti, è tagliato per la percezione, ma in realtà ci sono molte altre cose prese in considerazione.
Per esempio, prendiamo .NET, poiché tutte le API sono costituite da classi.
Mi piace molto il paradigma .NET. A proposito, c'è un grande terminale cAlgo, si può scrivere direttamente in Visual Studio in C#
Dimitri, ovviamente usare OOP riduce un po' le prestazioni. Ma sono frazioni di percentuale.
Se il numero di varianti è piccolo, lo rallenterà, ma se ci sono troppe varianti, sarà un vantaggio.
La cosa più importante è che il numero di varianti in OOP non influisce sulle prestazioni. E nella programmazione procedurale, c'è un tetto sopra la tua testa.
Beh, hai fatto un casino...
È chiaro che qualsiasi compito può essere risolto sia in stile OOP, con l'assegnazione di interfacce, la costruzione della gerarchia di ereditarietà, la dichiarazione di funzioni virtuali, sia in puro stile procedurale - si può anche infilare tutto in una funzione enorme.
La questione è nella convenienza e nell'efficienza del supporto.
In MT - il posto più adatto all'OOP è il sistema degli ordini. Personalmente, ho interfacce virtuali per "posizione" e "componenti di posizione". "Posizione" è un insieme di ordini in MT4 o un insieme di posizioni in MT5. "Componente della posizione" è un ordine individuale o una posizione MT5 individuale (hedge o netting).
Ecco il file di interfaccia attuale(Retag Konow, si può apprezzare il numero di commenti rispetto alla quantità di codice, e li aggiungo periodicamente quando incontro che non ricordo alcune sottigliezze. Per esempio, dimentico regolarmente quali oggetti reali costituiscono un "componente di posizione". Non ho bisogno di ricordarlo - l'Expert Advisor lavora con i componenti secondo l'interfaccia, e quello che c'è dietro quell'interfaccia in realtà non ha importanza. Ma, devo ritornarci durante la modifica - ecco perché ho bisogno molto spesso del primo commento in questo file):
Il file per l'interfaccia del componente commerciale è il seguente (l'ho già dato sopra, ma lo ripeto:
In base a queste interfacce - ho implementato sia il sistema di ordini MT4 che MT5 per ordini reali e storici.
L'Expert Advisor che richiede una posizione riceve questa interfaccia e non deve tenere conto della differenza tra gli ordini MT4 e MT5. E se viene aggiunto un nuovo tipo di ordine o viene cambiato l'ordine di lavorare con essi - non cambierà nulla per l'Expert Advisor, solo la nuova classe del tipo di ordine verrà aggiunta, e supporterà anche questa interfaccia.
Il sistema ha avuto molto senso quando sono stati introdotti i conti coperti. Gli esperti non sono cambiati affatto.
Reg Konow, come ti occupi della differenza dei tipi di ordine in MT4 e MT5?
Se viene introdotto un nuovo tipo di conto (oltre alla copertura e al netting) - quali cambiamenti dovranno essere fatti, e nello stesso posto?
La mia opinione è che se ti ricordi tutto il tuo codice alla lettera, e puoi facilmente dire perché questa o quella linea nel tuo codice è stata scritta un anno fa - allora è vero, tutti questi miglioramenti OOP sono solo gesti inutili.
L'OOP è necessaria proprio quando non si ricorda tutto quando si modifica il codice - l'OOP permette di isolare i blocchi l'uno dall'altro, limitare l'insieme delle entità disponibili in qualsiasi momento in un posto particolare del programma.
Beh, hai fatto un casino...
1. È chiaro che qualsiasi compito può essere risolto sia in stile OOP, con l'assegnazione di interfacce, la costruzione della gerarchia di ereditarietà, la dichiarazione di funzioni virtuali, sia in puro stile procedurale - possiamo anche mettere tutto in una funzione enorme.
La questione è nella convenienza e nell'efficienza del supporto.
2. In MT - il posto più adatto all'OOP è il sistema degli ordini. Personalmente, ho interfacce virtuali "posizioni" e "componenti di posizione". "Posizione" è un insieme di ordini in MT4 o un insieme di posizioni in MT5. "Componente della posizione" è un ordine individuale o una posizione MT5 individuale (con copertura o netting).
3. Ecco il file di interfaccia attuale(Retag Konow, si può apprezzare il numero di commenti rispetto alla quantità di codice, e li aggiungo periodicamente quando incontro che non ricordo alcune sottigliezze. Per esempio, dimentico regolarmente quali oggetti reali costituiscono un "componente di posizione". Non ho bisogno di ricordarlo - l'Expert Advisor lavora con i componenti secondo l'interfaccia, e quello che c'è dietro quell'interfaccia in realtà non ha importanza. Ma, devo ritornarci durante la modifica - ecco perché ho bisogno molto spesso del primo commento in questo file):
Il file per l'interfaccia del componente commerciale è il seguente (l'ho già dato sopra, ma lo ripeto:
In base a queste interfacce - ho implementato sia il sistema di ordini MT4 che MT5 per ordini reali e storici.
L'Expert Advisor che richiede una posizione riceve questa interfaccia e non deve tenere conto della differenza tra gli ordini MT4 e MT5. E se viene aggiunto un nuovo tipo di ordine o viene cambiato l'ordine di lavoro con essi - non cambierà nulla per l'Expert Advisor, solo un nuovo tipo di ordine verrà aggiunto, e supporterà anche questa interfaccia.
Il sistema si è dimostrato molto ragionevole, quando sono stati introdotti i conti di copertura. Gli esperti non sono cambiati affatto da allora.
4. Reg Konow, come ti occupi della differenza dei tipi di ordine in MT4 e MT5?
Se viene introdotto un nuovo tipo di conto (oltre alla copertura e al netting) - quali cambiamenti dovranno essere fatti, e nello stesso posto?
Penso che se ti ricordi tutto il tuo codice alla lettera, e puoi facilmente dire perché questa o quella linea è stata scritta un anno fa - allora tutti questi miglioratori OOP sono solo gesti inutili.
L'OOP è necessaria proprio quando non si ricorda tutto quando si modifica il codice - l'OOP permette di isolare i blocchi l'uno dall'altro per limitare l'insieme delle entità disponibili in un dato momento in un posto particolare del programma.
1. 1. Sono assolutamente d'accordo. L'unica differenza è nell'efficacia di risolvere i compiti in un modo o nell'altro.
2. Non ho lavorato molto con il sistema degli ordini e non vedo alcun problema tecnico nella sua costruzione. Forse ci sono, ma abbiamo bisogno di un compito concreto e allora sarà chiaro quanto efficacemente posso risolverlo senza l'OOP.
3. Dal mio punto di vista, l'esempio di codice dato è semplicemente terribile dal punto di vista della leggibilità. Non c'è da stupirsi che siano necessari così tanti commenti e che si dimentichi il suo contenuto. Scusa, ma questa è la mia prima impressione soggettiva. È semplicemente inquietante.
Ecco un esempio di leggibilità del mio codice - la funzione che definisce il colore dell'elemento di un controllo:
Come potete vedere, i commenti sono quasi inutili qui. Tutto il mio codice è scritto in questo stile. Quindi la conosco perfettamente e la ricordo a prescindere dalle dimensioni.
Secondo me, c'è qualche difetto nel vostro sistema di risoluzione dei problemi. Il problema stesso dovrebbe essere chiaro e preciso, e quindi anche la sua soluzione. Se la soluzione è nebulosa e definita dalle parole "Il sistema si è dimostrato molto ragionevole" (come può essere ragionevole in 270 Kb di codice?!), significa che l'autore ha una comprensione approssimativa di come funziona il suo sistema. E sono terribili gli artifizi di sintassi e le entità inutili nella soluzione che gli impediscono di capirla fino in fondo.
Affinché una soluzione sia efficace, le entità inutili devono essere tagliate e il problema deve essere visto perfettamente.