Spese generali per l'OLP - pagina 2
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
Naturalmente, la bella OOP deve essere pagata con risorse e molto tempo di debugging. L'OOP ha senso solo come un comodo involucro di testo o con un uso minimo nell'inizializzazione runtime... In realtà, OOP era solo una cosa di marketing di Microsoft per aumentare i costi delle ore di lavoro dei programmatori e per stimolare l'acquisto di attrezzature più avanzate. E loro stessi non sono stupidi e scrivono tutto il software in C e assembler.
Che mucchio di stronzate.
tutti sanno che i programmatori MS scrivono direttamente in codice macchina
ogni programmatore ha un libro con i codici della macchina del processore sulla sua scrivania e si limita a bruciare i codici sulle schede perforate
Bill Gates può compilare un sistema operativo nella sua testa).
Che mucchio di stronzate.
Tutti sanno che i programmatori MS scrivono direttamente in codice macchina
La tua pagliacciata non è molto chiara, si sa che gli inserti in linguaggio assembly sono usati per migliorare le prestazioni del codice...
Posso supporre che l'OOP sia usato nel terminale al minimo o per niente perché è difficile ottenere file così compatti senza grandi librerie esterne come in dotnet...
Ha qualche argomento significativo sull'essenza di ciò che è stato detto?
Controllare. Alexei sta infatti solo reagendo emotivamente. E in sostanza, le obiezioni sono le seguenti.
OOP è molto utile quando si ha bisogno di supportare del codice complesso.
Certamente, non ha senso applicare tutti i trucchi OOP a un indicatore-MA. Anche se quando le classi di base sono scritte - anche per MA - ancora l'approccio OOP è almeno buono come un solito approccio procedurale.
Il vantaggio principale di OOP si rivela con il supporto di strutture di oggetti sviluppati. Quando è incapsulato, non c'è bisogno di capire tutte le sfumature delle funzioni sovraccaricate ogni volta. Quando è basato sul polimorfismo, ilriutilizzo del codice diventa molto più alto.
L'essenza di OOP è più vicina al mondo reale, dove ogni oggetto è sempre legato alle sue proprietà e ha certe regole di interazione con l'ambiente.
Riguardo al "costo aumentato delle ore di lavoro" - questo non è vero. Certamente, quando si progetta un sistema in stile OOP si richiede un po' più di lavoro che nell'approccio procedurale. Tuttavia, questi costi extra sono più che compensati dalla comodità di mantenere e modificare il codice scritto.
Personalmente, scrivo indicatori molto piccoli "scritti in ginocchio" senza alcun oggetto. Tuttavia, quando è richiesto qualcosa di più (almeno cross-platform) - uso sempre lo stile OOP e le pratiche esistenti nelle librerie di oggetti.
La tua pagliacciata non è molto chiara, sappiamo che gli inserti in linguaggio assembly sono usati per migliorare le prestazioni del codice...
Posso supporre che il terminale usi una OOP minima o nulla, perché senza enormi librerie esterne come in dotnet è difficile ottenere file così compatti...
1. OOP - aiuta molto quando è necessario supportare qualche tipo di codice complesso.
2. naturalmente, non ha senso applicare tutti i trucchi OOP per l'indicatore-MA. Anche se, quando le classi di base sono scritte - anche per MA - è ancora un approccio OOP, almeno, non peggiore del solito approccio procedurale.
3. Il vantaggio principale di OOP è rivelato dal supporto di strutture di oggetti sviluppati.
1. ad esempio? Gli slogan accattivanti sono buoni, ma non è chiaro cosa significhino esattamente...
2. Si è già detto che come involucro di testo OOP è buono, ma questo perché non è stato perfezionato nella programmazione procedurale.
3. Perché abbiamo bisogno di moltiplicare queste "strutture sviluppate"? Sarà distruttivo per le prestazioni del codice e non è sicuro che sarà più facile e veloce catturare i bug in esso.
I compilatori moderni ottimizzano molte volte meglio di un programmatore medio o anche buono.
Forse alcune cose semplici e banali possono, ma solo perché la gente si è seduta e ha scritto manualmente l'algoritmo, ma se qualcosa di non standard, è tutt'altro che certo, soprattutto se vi si trovano caratteristiche OOPesheh.
Nei driver, sì, usano assebler, ma non per la velocità, è solo più facile lavorare con l'hardware..,
Beh, le persone non sono stupide - perché dovrebbero volere qualcosa di complicato e confuso che è anche lento?
E per esempio? Gli slogan accattivanti sono belli, ma è difficile capire di cosa stiamo parlando esattamente... 3.
2. Si è già detto che come involucro di testo OOP è buono, ma questo perché non è stato portato a capo della programmazione procedurale.
3) Perché dovremmo moltiplicare queste "strutture sviluppate"? Sarebbe terribile per le prestazioni del codice e non è il fatto che sarà più facile e veloce catturare i bug in esso.
1. Per esempio, avete bisogno di un array di oggetti. Questo potrebbe essere fatto proceduralmente o basato su CArrayObj e CObjest. I problemi inizieranno quando avrete bisogno di cambiare il comportamento, per esempio, aggiungendo o cancellando oggetti o ordinandoli. In OOP, il supporto per un array di puntatori vero e proprio e il lavoro con esso è racchiuso negli oggetti di base. Modificare gli oggetti discendenti che sono effettivamente contenuti nell'array non ha alcun effetto. In stile procedurale - modificando oggetti reali che sono effettivamente contenuti in un array - di solito colpisce molti più posti, almeno perché dobbiamo considerare i cambiamenti nella dimensione degli oggetti. Il che porterà più facilmente a degli errori.
Cross-platform - anche molto più comodo da organizzare in stile OOP. Quando sulla richiesta, diciamo, di una posizione commerciale - otteniamo un'interfaccia, e non importa su quale piattaforma lavoriamo - l'interfaccia offre funzioni virtuali, su cui possiamo ottenere tutti i dati su tutti gli ordini (per MT4) o posizioni (MT5), e, dal punto di vista degli esperti - non c'è differenza. L'Expert Advisor non ha bisogno di sapere su quale piattaforma lavora.
2. Bene, "finire nella programmazione procedurale" significa "scrivere oggetti-procedure", cioè creare alcuni collegamenti tra dati e procedure, che rappresentano oggetti in OOP.
3. E poi abbiamo, diciamo, un certo numero di tipi di ordini, che hanno molto in comune. Sarebbe ragionevole fare un oggetto COrderInfo - che sarebbe l'oggetto base, e i suoi discendenti rappresenterebbero diversi tipi di ordini. In questo caso, il processore commerciale (ho la classe CTradeProcessor) supporterà automaticamente esattamente quell'ordine, che gli è stato passato, da quelle procedure che sono necessarie per elaborare questo ordine.
È più facile catturare i bug dove ci sono meno collegamenti incrociati. Che è esattamente fornito dall'incapsulamento e dal polimorfismo. Richiediamo l'interfaccia della posizione commerciale (CTradePositionI) e tutte le connessioni con le classi reali che rappresentano questa posizione (CMT4PositionInfo,CMT5PositionInfo) sono eseguite solo attraverso questa interfaccia, e questo contribuisce precisamente a una più facile correzione degli errori che se lavorassimo direttamente con funzioni reali che restituiscono i dati della posizione commerciale.