Una domanda per gli esperti di OOP. - pagina 5

 
Artyom Trishkin:
Tutte le liste sono già dotate di una ricerca binaria. Questo non significa passare attraverso le liste una per una, ma piuttosto filtrare per la proprietà ricercata. Come risultato, otteniamo l'indice dell'elemento che stiamo cercando.
Queste liste sono collegate a qualcosa all'interno dell'OOP? Cioè, quale "carico" portano con sé? Classi, costruttori, interfacce...? Sono integrati nell'ambiente della classe, vero?
 
Nikolai Semko:
Quando viene creato un oggetto di classe, oltre ad allocare la memoria per tutte le proprietà (variabili) della classe, viene avviato uno dei costruttori (ce ne può essere più di uno). I costruttori possono essere non parametrici (default), parametrici (quando alcuni parametri sono specificati quando si crea un'istanza di una classe, o un costruttore di copia, quando un'altra istanza della classe è specificata come parametro di un'istanza della classe.
Capisco, grazie, Nikolay. Ne sarò consapevole.
 
Реter Konow:

Ho già risolto questo compito pubblicamente. L'idea era di creare una tabella di tutti i simboli e di tutti i timeframe e di passarci attraverso, fissare gli eventi di una nuova barra. Dopo la prima chiamata di qualsiasi funzione di questo evento, il suo flag viene cancellato dalla tabella. Non posso giudicare quanto sia più complicato che in OOP. Ma, in realtà, una soluzione piuttosto semplice e conveniente.

come hai scritto sopra, tutto è relativo.... usando l'ultimo colpo del clip...

Hai guardatola libreria standard dalla consegna di MT? è tutto in stile OOP, ci sono 2 opzioni qui o i programmatori di Metakvot sono professionisti e usano stili comprensibili o... La tua versione ;)

 
Igor Makanu:

come hai scritto sopra, tutto è relativo.... usando l'ultimo colpo del clip...

Hai guardatola libreria standard dalla consegna di MT? è tutto in stile OOP, ci sono 2 opzioni qui o i programmatori di Metakvot sono professionisti e usano stili comprensibili o... La tua versione ;)

Non sono ancora molto esperto di OOP. Mi parlano di liste ma non so con cosa "mangiano". Come vengono annunciati, come vi si accede, come vengono cambiati e così via... Per me, una lista è solo un array dinamico senza alcuna sintassi aggiuntiva. Un oggetto è un insieme di proprietà in un array. E in OOP - Object è un'intera classe. Ereditarietà - collegamento di oggetti. Accesso alle proprietà dell'oggetto attraverso i riferimenti nominativi. Quindi, tutto nel mio caso è molto più semplice e quindi trovo difficile confrontare le caratteristiche e l'efficienza. Ho bisogno di andare più a fondo.

Ma una cosa ho imparato. Non si può capire e usare una qualsiasi entità del concetto di OOP senza capire l'intera OOP e passare ad essa completamente. È OOP o quello che vuoi. Usare semplicemente uno dei suoi comodi meccanismi probabilmente non funzionerà.

 
Реter Konow:

Usare semplicemente uno dei suoi comodi meccanismi probabilmente non funzionerà.

L'OOP può coesistere con lo stile procedurale senza problemi, ma le funzioni devono essere blocchi di codice completamente separati e indipendenti, cioè tutto ciò che la funzione usa deve essere in essa o essere passato come parametro ad essa

in generale, come scrivono su Wiki, che OOP è un'estensione dello stile procedurale

Retag Konow:

Ma una cosa l'ho capita. Non si può capire e usare una qualsiasi entità del concetto di OOP senza capire tutto l'OOP e senza andarci completamente.

si può, ho fatto un esempio, e sul forum il 90% dei sorgenti in stile OOP sono wrapper intorno allo stile procedurale - nessuna ereditarietà, nessuna astrazione, niente ..... niente, solo incapsulamento, ma comunque è almeno conveniente - è conveniente avere un pezzo di codice completamente trasferibile ad un altro compito - dopo tutto tutto tutto dentro una classe? ;)

 
Igor Makanu:

con lo stile procedurale OOP senza problemi, ma le funzioni devono essere blocchi di codice completamente separati e indipendenti, cioè tutto ciò che una funzione usa deve essere in essa o essere passato come parametro ad essa

in generale, come scrivono in Wiki, OOP è un'estensione dello stile procedurale

Si può, ho fatto un esempio, e sul forum il 90% del codice sorgente in stile OOP è un involucro intorno allo stile procedurale - niente ereditarietà, niente astrazioni, niente ..... niente, solo incapsulamento, ma comunque è almeno conveniente - è conveniente avere un pezzo di codice completamente trasferibile ad un altro compito - tutto dentro una classe, giusto? ;)

Sì, la portabilità del codice è un grande vantaggio di OOP. Nel mio caso solo le singole funzioni sono portatili (e solo raramente), ma quando costruisco un grande meccanismo, niente è portatile. Proprio come gli organi umani non sono trasferibili (senza un intervento professionale). I miei meccanismi sono più simili a degli "organismi", nel senso che sono divisi in grandi blocchi, ognuno dei quali svolge una serie di compiti. Pertanto, la portabilità è quasi inesistente. Tuttavia, questi blocchi sono molto facili da estendere la loro funzionalità. Lo si "aggiunge" con poche righe, e voilà! - I blocchi eseguono un intero strato di lavoro nuovo per il quale bisogna scrivere molte funzioni separate. Tutto sommato, ha i suoi vantaggi. Beh, l'ambito globale è uno strumento incredibilmente potente. Il materiale con cui i blocchi lavorano è assolutamente disponibile per loro e non c'è bisogno di trasferire nulla. Tutto il necessario per il lavoro è già lì. Tutto sommato, gli approcci sono diversi e ognuno ha i suoi vantaggi.

 
Реter Konow:

Non so ancora molto di OOP. Mi parlano di liste e non so con cosa siano "mangiate". Come vengono dichiarati, come vi si accede, come vengono cambiati e così via... Per me, una lista è solo un array dinamico senza alcuna sintassi aggiuntiva. Un oggetto è un insieme di proprietà in un array. E in OOP - Object è un'intera classe. Ereditarietà - collegamento di oggetti. Accesso alle proprietà dell'oggetto attraverso i riferimenti nominativi. Quindi, tutto nel mio caso è molto più semplice e quindi trovo difficile confrontare le caratteristiche e l'efficienza. Devo approfondire la questione.

Ma una cosa ho imparato. Non si può capire e usare una qualsiasi entità del concetto di OOP senza capire l'intera OOP e senza passare ad essa completamente. È OOP o quello che vuoi. Usare semplicemente uno dei suoi comodi meccanismi probabilmente non funzionerà.

Peter, devi solo provare. E vi consiglio di provarlo proprio sulle strutture di liste, perché lì potete vedere tutti i vantaggi dell'OOP in tutte e tre le direzioni - ereditarietà, incapsulamento e polimorfismo.

Grazie all'ereditarietà, avete una singola interfaccia (un insieme di funzioni virtuali) per lavorare con gli oggetti all'interno di una lista. Gli oggetti possono essere semplici o complessi, ereditati dalla base.

Per polimorfismo - si può lavorare con oggetti fondamentalmente diversi con questa singola interfaccia.

A causa dell'incapsulamento - avete SOLO questa interfaccia, e non avete accesso a nessun dettaglio di implementazione - di conseguenza, non potete sbagliare qualcosa. Inoltre sapete esattamente, non solo come funzionano gli oggetti che sono ora, ma come gli oggetti che non sono ancora scritti interagiranno con il vostro codice.

 
Реter Konow:
Queste liste sono collegate a qualcosa all'interno dell'OOP? Voglio dire, che "carico" si portano dietro? Classi, costruttori, interfacce...? Sono integrati nell'ambiente della classe, vero?
Essenzialmente - una lista è molto vicina a un array. Potete dichiararla come una variabile di tipo elenco o crearne una nuova tramite l'operatore new. Ma nel caso del nuovo, la lista non è controllata dal sottosistema terminale e deve essere sempre cancellata quando il lavoro è finito - delete. Ma se una tale lista viene aggiunta ad un'altra lista come oggetto, non ha bisogno di essere monitorata.
 
Реter Konow:

Beh, l'ambito globale è uno strumento incredibilmente potente. Il materiale con cui i blocchi lavorano è assolutamente disponibile per loro e non c'è bisogno di trasferire nulla. Tutto ciò di cui avete bisogno per lavorare è già lì.

quando si tratta dell'ambito globale delle variabili da usare come parametri per funzioni o sezioni di codice, allora.... imho, questo è il modo migliore per ottenere un codice completamente non trasportabile con la possibilità di ottenere bug nascosti che sono impossibili da rilevare in seguito

SZZ: ho modificato tali codici per MT4 EAs per molte volte, all'inizio ho rinominato le variabili dichiarate globalmente - poi ho fatto delle modifiche quando ho visto errori del compilatore, ma l'ultima volta l'ho fatto correttamente - ho aggiunto nuovi parametri alle firme delle funzioni e poi ho rimosso le variabili dichiarate globalmente, perché se sei riuscito a modificare questo codice miserabile una volta, dovrai farlo di nuovo? - ahimè sono pigro, ma ragionevolmente pigro )))))

 
Igor Makanu:

quando si tratta dell'ambito globale delle variabili da usare come parametri per funzioni o sezioni di codice, allora.... imho, questo è il modo migliore per ottenere un codice completamente non trasportabile con la possibilità di ottenere bug nascosti che sono impossibili da rilevare in seguito

SZZ: ho modificato tali codici per MT4 EAs per molte volte, all'inizio ho rinominato le variabili dichiarate globalmente - poi ho fatto delle modifiche quando ho visto errori del compilatore, ma l'ultima volta l'ho fatto correttamente - ho aggiunto nuovi parametri alle firme delle funzioni e poi ho rimosso le variabili dichiarate globalmente, perché se sei riuscito a modificare questo codice miserabile una volta, dovrai farlo di nuovo? - ahimè sono pigro, ma ragionevolmente pigro )))))

Il codice non è portabile, ed è questo che lo rende speciale. Non è destinato ad essere portatile. Ha un altro scopo. Bene, l'ambito globale delle variabili è uno strumento potente per lavorare con meccanismi complessi. Bisogna solo sapere come usarlo. Quando la gente mi parla di errori e bug nascosti, mi confondo. Non ho mai avuto alcun bug legato alla visibilità delle variabili globali. In una parola, per niente.

Motivazione: