Spese generali per l'OLP - pagina 2

 
Andrei:

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).

 
Alexey Volchanskiy:

Che mucchio di stronzate.

Ha qualche argomento significativo sulla sostanza di ciò che ha detto?
 
Alexey Volchanskiy:

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...

 
Andrei:
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.


 
Andrei:

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...

I compilatori moderni ottimizzano molte volte meglio di un programmatore medio o anche buono. È come se tu apparissi dal secolo precedente. Che cazzo intendi per inserti nel codice ordinario? I driver sì, usano assebler, ma non per le prestazioni, è solo più facile lavorare con l'hardware..,
 
George Merts:


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.

 
Alexey Volchanskiy:
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.

 
Alexey Volchanskiy:
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?

 
Troll, vattene, non ti piace, non usarlo.
 
Andrei:

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.