Domande su OOP in MQL5 - pagina 27

 
Alexey Navoykov:

Quali affermazioni in particolare sono infondate?

c'è abbastanza.

L'articolo è un articolo usa e getta, progettato per ottenere una tempesta di fuoco dalle persone OOP e non ha nulla a che fare con mql perché semplicemente non ci sono strumenti di linguaggio per FP in mql.

quindi non ha senso discuterne qui.

 
TheXpert:

c'è abbastanza.

L'articolo è un lancio, progettato per essere bruciato da persone OOP e non ha nulla a che fare con mql, perché semplicemente non ci sono strumenti di linguaggio per FP in mql.

quindi non ha senso discuterne qui.

Sì, ma almeno sottolinea i problemi dell'uso scorretto (sconsiderato) di OOP. Penso che sia molto utile qui, in modo che i principianti non abbiano l'impressione che il fatto stesso di usare OOP sia una panacea e una garanzia di qualità del codice.
 
TheXpert:

c'è abbastanza.

L'articolo è un lancio, progettato per ottenere una tempesta di fuoco dalle persone OOP e non ha nulla a che fare con mql, perché semplicemente non ci sono strumenti di linguaggio per FP in mql.

quindi non ha senso discuterne qui.

I commenti non sono necessari.

 
Vasiliy Sokolov:
I sostenitori del FP dimenticano consapevolmente che il loro lambda calculus è eseguito da una macchina di Turing, con un numero finito di stati e transizioni tra di essi, cioè si usano gli stessi contatori, istruzioni di ramificazione e goto. Quindi affermare che FP fornisce qualcosa di più di un linguaggio classico come C, C#, Java è per lo meno scorretto.

Vasily, questo articolo ti sarebbe molto utile - in modo che tu non ti torturi spremendo OOP per amore di OOP.

 
Dmitry Fedoseev:

Vasily, questo articolo ti sarebbe molto utile - in modo che tu non ti torturi spremendo OOP per amore di OOP.

Perché così poco lusinghiero? Mi piace molto lo stile dei suoi articoli,

Mi piace lo stile e la pulizia dei suoi articoli, vorrei che fosse pulito e leggibile.

 
Igor Makanu:

Perché non è lusinghiero? Mi piace molto il suo stile di scrittura,

il codice è pulito e leggibile - lo augurerei sicuramente a me stesso - il livello è molto alto.

Purtroppo non posso sostenere questa conversazione - non ho letto alcun articolo o visto alcun codice. Si trattava di qualcos'altro.

 
Dmitry Fedoseev:

Purtroppo non posso sostenere questa conversazione - non ho letto l'articolo o visto il codice. Si trattava di qualcos'altro.

Posso solo dare la mia opinione su OOP per chiarezza di scopo di OOP in MQL. Ho finito il codice - era interessante vedere quale sarebbe stato il risultato.

Ora ho avvolto tutte le funzioni per lavorare con gli ordini in una classe, e poi ho pulito il codice e rimosso i parametri nelle funzioni poiché i campi della classe sono privati - nessun senso.... ho ottenuto un codice totalmente inutilizzabile per un ulteriore utilizzo

Sì, è conveniente che si possano aggiungere piccoli metodi ed estendere le funzionalità della classe, ma per un uso futuro... o aggiungere nuovi metodi sapendo che il compilatore non includerà il codice inutilizzato nell'eseguibile o... ... o ... scriverli di nuovo - così, tutto sommato, abbiamo un certo mostro di classe per lavorare con gli ordini

cioè la tassa di universalità è un codice gonfiato che non sarete in grado di leggere dopo un paio di mesi e voi erediterete il codice così non dovrete scoprire cosa è superfluo in una classe - peccato per il vostro tempo

puoi leggere in linea di principio, i nomi dei metodi secondo i compiti che stai per eseguire... in generale, non sono soddisfatto del risultato - tutto è macchinoso

 
Igor Makanu:

Posso solo dare la mia opinione su OOP per chiarezza di capire la ragionevolezza di OOP in MQL. Ho finito il codice - è stato interessante vedere cosa sarebbe venuto fuori alla fine, all'inizio era il modo in cui scrivevo - debug delle funzioni di servizio di lavoro con gli ordini e inserendo OOP dove tenevo i dati e piccoli metodi che avevo previsto di usare solo in un certo compito, ho chiamato le funzioni di lavoro con gli ordini da classi (stile procedurale)

Ora ho avvolto tutte le funzioni per lavorare con gli ordini in una classe, e poi ho pulito il codice e rimosso i parametri nelle funzioni poiché i campi della classe sono privati - nessun senso.... ho ottenuto un codice totalmente inutilizzabile per un ulteriore utilizzo

Sì, è conveniente che si possano aggiungere piccoli metodi ed estendere le funzionalità della classe, ma per un uso futuro... o aggiungere nuovi metodi sapendo che il compilatore non includerà il codice inutilizzato nell'eseguibile o... ... o ... scriverli di nuovo - così, tutto sommato, abbiamo un certo mostro di classe per lavorare con gli ordini

cioè la tassa di universalità è un codice gonfiato che non sarete in grado di leggere dopo un paio di mesi e voi erediterete il codice così non dovrete scoprire cosa è superfluo in una classe - peccato per il vostro tempo

puoi leggere in linea di principio, i nomi dei metodi secondo i compiti che stai per eseguire... in generale, non sono soddisfatto del risultato - tutto è troppo macchinoso

In breve, ho fatto la cacca e mi sono perso.

 
Алексей Тарабанов:

In breve - cacare e uscire.

Hmm, chi è uscito? Di cosa stai parlando? Ok... Tutti i vostri commenti nel cuore della notte, è difficile sapere cosa è cosa.

 
Igor Makanu:

...

E se non usate le classi, vi stancherete di scrivere costantemente qualcosa come SymbolInfoDouble(_Symbol,SYMBOL_BID). Questo balla ogni volta - sia parentesi che underscore, e non sai se premere il capslock (e poi da qualche altra parte senza guardare, digitare un'intera stringa in maiuscolo e riscriverla) o tenere premuto lo shifter. Almeno è qui che l'OOP è utile. Se almeno fanno delle classi per tutte queste funzioni, allora sì - sono enormi. Se lo scrivi per te stesso, non è un problema. Per quanto riguarda il lavoro con gli ordini, non ci sono molte funzioni di uso frequente, possiamo semplicemente mettere alcune funzioni in una libreria. Ma in generale, non esiste ancora un approccio ideale.

Motivazione: