Mt4 Fine del supporto. - pagina 28
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
Non so se qualcuno lo ha suggerito, ma perché non spostare tutto in MT4 a MT5, allora tutti andrebbero avanti.
George Merts:
Scrivono prima le parti e poi le combinano in un tutto, spesso scoprendo che le parti non sono compatibili tra loro - che, per inciso, è ciò che spiega il desiderio di "avere accesso a tutte le variabili disponibili".
No, non lo è. Non si tratta di avere accesso a tutte le variabili possibili, solo a quelle di cui avete bisogno. Queste sono di solito variabili di ingresso e di uscita di diverse funzioni.
Aggiungere ulteriori confini qui renderà la leggibilità del codice molto più difficile e aumenterà i possibili errori quando qualcosa non è arrivato a destinazione perché si è perso per strada a causa di questi confini.
Certamente è comprensibile il desiderio almeno in qualche modo di tirare indietro OOP per qualcosa di utile, ma tali casi di solito non si trovano nel campo della programmazione, ma nella sfera commerciale, per esempio per ore extra di programmazione, creazione di discussioni infinite sull'architettura delle interfacce e simili piacevoli passatempi nel tempo di lavoro.
C'è, in linea di principio, un esempio di questo? Anche se non il tuo? Ho profondi dubbi. All'inizio degli anni duemila ho smesso di contare il numero di linee di codice di programma debuggate e funzionanti scritte da me perché superava il milione - è diventato poco interessante. E non ho mai incontrato la necessità di creare la mia classe, anche se la varietà e la portata dei miei compiti erano molto diverse. Ho dovuto usare variabili di tipo procedura quando era necessario parallelizzare il lavoro per diverse persone, ma non più. Perché è così?
Il punto è che OOP può essere applicato solo al confezionamento del codice pronto e lo impedisce solo nella fase di scrittura del codice. Ma se non c'è questa necessità, non c'è nemmeno bisogno di OOP.
Vladimir:
Si scopre che l'OOP impedisce il parallelismo automatico dei calcoli. Oggi dovrebbe essere considerato come un inconveniente molto grave, la prospettiva non è per OOP.
La prospettiva è in linguaggi come Systemverilog.
Va bene, tranne per il fatto che la funzione isNewBar() non dovrebbe esistere affatto. È divertente che si balli così tanto intorno a una cosa così banale.
È solo una variabile, e viene semplicemente confrontata con il tempo della barra; se tutti i casi hanno successo, allora alla variabile viene assegnato il tempo della nuova barra alla fine. Altrimenti viene assegnato un solo tentativo a tutti i casi.
Aggiungere ulteriori confini qui renderà immediatamente la leggibilità del codice molto più difficile e aumenterà i possibili errori quando qualcosa non arriva da qualche parte perché si è perso per strada a causa di questi confini.
È proprio il contrario - i confini ti permettono di non pensare a "perché questa variabile, che ruolo gioca in questo caso, dovrebbe essere presa in considerazione?
L'utente ha accesso solo a ciò che deve considerare, e solo a ciò che può cambiare. Questi sono proprio gli errori "quando qualcosa si perde lungo la strada" - e sorgono proprio perché c'è troppo a disposizione, e qualcosa viene "dimenticato lungo la strada". Con gli interessi virtuali "troncati", questo è molto più difficile da fare.
Ecco l'esempio più semplice: guadagnare una posizione. Una posizione è sia ordini aperti in MT4 che posizioni aperte in MT5.
Se avete accesso completo, allora quando selezionate una posizione - l'utente deve ricordare quali variabili possono essere lette ora, quali variabili non sono valide al momento, quali variabili può cambiare e quali no.
Con l'interfaccia, le cose sono molto più semplici. Ce l'hai, e ha solo due funzioni: ottenere il numero di componenti e ottenere un puntatore a un componente costante. QUESTO È QUANTO. Con queste due funzioni - non si può fisicamente avere accesso a nessuna "variabile extra".
Andrei:
Naturalmente, capisco il desiderio di trascinare almeno in qualche modo l'OOP per qualcosa di utile, ma tali casi di solito non si trovano nel campo della programmazione, ma nella sfera commerciale, come ore di programmazione extra, discussioni infinite sull'architettura delle interfacce e simili piacevoli passatempi nelle ore di ufficio.
E ci arriverete prima o poi. Inoltre, l'incapsulamento può essere fatto con un approccio "puramente procedurale". Ma è più conveniente nell'approccio OOP, perché si ottiene ancora l'ereditarietà e il polimorfismo "automaticamente".
Non so se qualcuno lo ha suggerito, ma perché non spostare tutto in MT4 a MT5, allora tutti andrebbero avanti.
Il problema non è solo che c'è qualcosa in 4 che non è in 5. E non è nemmeno l'OOP.
5 non ha dato praticamente nulla ai commercianti (non programmatori, non commercianti di software - solo commercianti).
Formato proprio della storia, divieto di personalizzazione - ma questi due punti hanno spaventato tutti quelli che commerciano in geometria. E nessun "molti TF" (senza anno, lol), scale in pip per barra li attirerà.
Una semplice domanda. Cosa mostra la "griglia"? Cercare di scoprirlo vi condurrà alla raccomandazione di andare a fare il freelance e ordinare quello che volete.
Gli MT sono terminali per i programmatori. Questa è la risposta completa.
La questione è che OOP può essere applicabile solo al confezionamento del codice pronto, in una fase di scrittura del codice interferisce solo. Ma se non c'è questa necessità, non c'è bisogno di OOP.
No, non lo è. È solo il contrario.
Le interfacce sono definite inizialmente, anche "prima della fase di scrittura del codice". Le interfacce sono, infatti, tutti gli stessi ToR per il programmatore. Tutte le interazioni in Freelance sono eseguite usando ToR espliciti. Quindi, le interfacce virtuali sono una specie di TOR, che è dove inizia la programmazione.
Semplicemente, per come la vedo io, ti stai avvicinando all'essenza stessa dell'OOP in modo scorretto. Prima scrivi un mucchio di funzioni e poi le devi "spremere" nel design OOP. Ma questo è un modo sbagliato. Il modo corretto è l'opposto - prima si definiscono le definizioni OOP, quegli insiemi di interfacce di base tra i componenti del sistema. E poi uno per uno ogni componente viene scritto seguendo queste interfacce molto predefinite.
Sì, a volte succede che scopriamo quando scriviamo il codice che l'interfaccia non ha previsto qualcosa. E poi si inizia... "Ohhhh... Nell'approccio procedurale - avrei accesso a tutto questo, non avrei problemi a fare ciò di cui ho bisogno, ma ora - come faccio ad avere accesso a queste variabili?". Questo succede quando nella fase di progettazione delle interfacce - qualcosa non è stato preso in considerazione. Questa è una situazione molto spiacevole - dovete aggiungere delle interfacce aggiuntive o cambiare quelle esistenti - il che è pieno di errori. Questa situazione dovrebbe ovviamente essere evitata.
Ecco l'esempio più semplice: ottenere una posizione. Una posizione è sia ordini aperti in MT4 che posizioni aperte in MT5.
Se avete accesso completo, quando selezionate una posizione - l'utente deve ricordare quali variabili possono essere lette ora, quali variabili non sono attualmente valide, quali variabili può cambiare, quali no.
Con l'interfaccia, le cose sono molto più semplici. Ce l'hai, e ha solo due funzioni: ottenere il numero di componenti e ottenere un puntatore a un componente costante. QUESTO È QUANTO. Con queste due funzioni - non si può fisicamente accedere a nessuna "variabile extra".
È vero proprio il contrario. Gli utenti hanno spesso bisogno di conoscere le variabili interne per i test di qualità dei moduli, per esempio, e questo non è il caso. E si inventano modi speciali e intelligenti per ottenere questo accesso in seguito. Quindi non ci sono informazioni ridondanti in linea di principio, e coloro che non ne hanno bisogno possono semplicemente non usarle.
Questo è esattamente il contrario. Gli utenti hanno spesso bisogno di conoscere le variabili interne per testare i moduli di qualità, per esempio, e questo non è il caso. E poi escogitano modi speciali e intelligenti per ottenere questo accesso. Così, non ci sono informazioni inutili, e quelli che non ne hanno bisogno semplicemente non le usano.
Se avete bisogno di un "accesso astuto per ottenerlo" - indica una progettazione errata del sistema.
Per esempio, se scriviamo un generatore di segnali di ingresso - non dovremmo avere accesso alle informazioni riguardanti, diciamo, la gestione del denaro.
Naturalmente, durante il debugging ci può essere una situazione, per esempio, quando non c'era nessuna entrata - dovremmo eliminare immediatamente la situazione, quando è successo perché il money management ha proibito l'operazione (per esempio, non c'è abbastanza margine). E come fate a saperlo dal generatore di voci? Non hai - non hai accesso. Ma in questo caso - è sufficiente assicurarsi che il generatore ha impostato un segnale per l'ingresso, e ha funzionato correttamente. Non c'era nessun input - per qualche altra ragione, che si trova al di fuori del generatore di input. Trovare la ragione in questo caso è davvero più difficile che se avessimo accesso a tutte le variabili della gestione del denaro direttamente. Ma, è molto più pericoloso che nel funzionamento normale, di routine - noi, avendo accesso a loro - sarà "ottenere nel posto sbagliato".
Se è richiesto un "accesso difficile da ottenere", indica una cattiva progettazione del sistema.
Lo sviluppo è prima di tutto un processo naturale della mente.
In questo processo, le idee si formano liberamente e persino spontaneamente.
Seguire una OOP rende difficile trasformare liberamente il codice.
Nel processo naturale di sviluppo, il codice stesso si restringe gradualmente e si universalizza.
Nel processo naturale, le funzioni non si rompono ma al contrario crescono e si uniscono in grandi blocchi.
I grandi blocchi risolvono una vasta gamma di compiti.
La OOP impedisce la formazione di questi blocchi, lasciando il codice frammentato.
OOP crea un accesso complicato, che aumenta costantemente il numero di riferimenti alle variabili.
I vantaggi della granularità sono superati dalla difficoltà di realizzare un meccanismo coerente.
Lo svantaggio principale: OOP ci costringe a seguire il modo di dividere il codice in un certo numero di funzioni.
È più facile per un umano accettare il codice frammentato, ma la frammentazione è controindicata a qualsiasi meccanismo.