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
i modificatori dei diritti di accesso permettono di rilevare gli errori in fase di compilazione
In generale, tutto questo non complica il lavoro con le classi, non usarlo, scrivi tutto in pubblico: e allora sarà più facile lavorare con loro.
SZZY: Un sacco di belle frasi su OOP, incapsulamento ed ereditarietà... Questo è tutto buono, ma il vantaggio più importante di OOP rispetto ad altri stili di programmazione è la memorizzazione di tutti i dati (campi di classe) e le funzioni di lavoro con questi dati (metodi di classe) in un posto (classe) - in libro è incapsulamento. L'ulteriore uso di OOP dipende dai compiti, se il compito permette di scalare le classi, allora la gerarchia sarà necessaria e ci saranno classi base e i loro discendenti - se usarla, dipende da voi
Potete anche "incapsulare" tutte le proprietà di un oggetto in un array. È anche possibile specificare le relazioni tra gli oggetti tramite specifiche proprietà del puntatore. C'è un ordine, perché ogni proprietà è indicizzata e il suo valore è memorizzato in una cella specifica. Gli oggetti stessi sono incapsulati nel kernel. L'accesso è più semplice: per numero di oggetto e numero di proprietà. Le transizioni tra oggetti dello stesso controllo avvengono tramite puntatori di proprietà.
questo non è conveniente in primo luogo!
Inoltre, hai già scritto sopra sulla leggibilità del codice (così come sopra hai menzionato la velocità - la velocità di esecuzione, dipende da qualcos'altro, non dallo stile di programmazione)
in generale, come dappertutto - non lo saprai finché non provi, inizia a scrivere in stile OOP, otterrai azioni specifiche e domande specifiche, un esempio è già in questo thread
Se stiamo parlando di AI, bisogna anche separare i dati dal lavoro con essi, con OOP sarà più facile farlo
SZZ: Cosa è meglio in OOP? Per esempio, abbiamo diversi tipi di dati, lasciamo che siano le impostazioni di Expert Advisor in MQL, e queste impostazioni hanno ripetizioni in blocchi. Prendiamo un blocco di impostazioni e descriviamo campi di classe per trasferire queste impostazioni alla classe, è più facile creare un costruttore con parametri, e poi scrivere metodi che lavorano con queste impostazioni EA. Fatto tutto questo, creiamo o un array di istanze della classe, o anche solo alcune istanze della classe ("variabili di tipo classe") e questo è tutto - il problema è risolto scrivendo una sola classe, non creando diversi array, creando metodi per identificare ogni array, creando un gruppo di funzioni che, oltre a fare cambiamenti negli array, non sono sufficienti a rovinare dati che non dovrebbero essere trattati in questo call....
ZZZY: imho, OOP è solo conveniente, c'è una certa leggenda che non c'è bisogno di usare OOP se non c'è eredità... no comment, sarà una discussione spumeggiante senza di me
questo non è conveniente in primo luogo!
Inoltre, hai già scritto sopra sulla leggibilità del codice (così come sopra hai menzionato la velocità - la velocità di esecuzione, dipende da qualcos'altro, non dallo stile di programmazione)
in generale, come dappertutto - non lo saprai finché non provi, inizia a scrivere in stile OOP, otterrai azioni specifiche e domande specifiche, un esempio è già in questo thread
Se stiamo parlando di AI, bisogna anche separare i dati dal lavoro con essi, con OOP sarà più facile farlo
SZZ: Cosa è meglio in OOP? Per esempio, c'è un diverso tipo di dati, lasciate che siano le impostazioni di Expert Advisor in MQL, e queste impostazioni hanno ripetizioni in blocchi. Prendiamo un blocco di impostazioni e descriviamo campi di classe per passare queste impostazioni in una classe, è più facile creare un costruttore con parametri, e poi scrivere metodi che lavorano con queste impostazioni EA. Fatto tutto questo, creiamo o un array di istanze della classe, o anche solo alcune istanze della classe ("variabili di tipo classe") e questo è tutto - il problema è risolto scrivendo una sola classe, non creando diversi array, creando metodi per identificare ogni array, creando un gruppo di funzioni che, oltre a fare cambiamenti negli array, non sono sufficienti a rovinare dati che non dovrebbero essere trattati in questo call....
ZZZY: imho, OOP è solo conveniente, c'è una certa leggenda che non c'è bisogno di usare OOP se non c'è eredità... no comment, sarà una discussione spumeggiante senza di me
Comodo o no, questione soggettiva. Preferisco un layout tabellare dei dati. Altri lo preferiscono sotto forma di un grappolo d'uva o di un albero. Altri lo preferiscono come un grappolo d'uva o un albero. Ma, penserò seriamente alle tue parole e cercherò di afferrare i principi di base del lavoro con i dati in OOP.
In OOP, un "oggetto" è un riferimento a una classe in cui sono dichiarati i suoi campi (proprietà). Intendo un oggetto come un insieme numerato di proprietà, ognuna delle quali è una cella di un array. Questa è la differenza.
HH cioè se c'è una classe nel programma, ma nessuna istanza di essa, il compilatore ignorerà (non noterà) quella classe.
Una volta vi ho detto che un array di puntatori ad array di puntatori è una tabella bidimensionale. Una lista è la riga, le liste che si trovano nella prima sono le colonne. Possono avere le loro liste. E così via fino al tramonto. Questa è la gerarchia che state cercando. Ed è eseguita da una sola classe.
In teoria, sì. Ma è necessario organizzarsi in modo tale che le transizioni tra i collegamenti gerarchici (condizionalmente - induzione e deduzione, cioè dal particolare al generale e ritorno) siano eseguite come una catena. Cioè, l'ordine dei puntatori dovrebbe essere strutturato in modo speciale per permettere di muoversi in qualsiasi direzione (giusta), senza eccessivi "giri" e "salti" nel ciclo. Pertanto, una semplice disposizione tabellare dei puntatori probabilmente non funzionerà.
Aggiunto:
Ma potrebbe funzionare. Non lo so ancora.
Dobbiamo mettere in pratica queste domande, altrimenti non saremo in grado di vedere ciò che è conveniente e ciò che sembra sconveniente )))).
Ecco un esempio banale, che è usato in MQL centocinquanta volte - determinazione di una nuova barra:
Ok, questo è un codice che funziona, ma cosa succede se ho bisogno di definire una nuova barra per 2 TF? E se voglio usare tutti i TF del terminale?
sarebbe così in OOP:
e tutto quello che devo fare ora è dichiarare diverse istanze della classeCNewbar - come? anche ad un array, anche a diverse variabili, ma ho protetto i dati dal cambiamento accidentale con OOP
Ho già risolto questo problema pubblicamente. L'idea era quella di creare una tabella di tutti i simboli e di tutti i timeframe e di fare un loop attraverso di essa, fissando 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.
Peter, devi capire chiaramente che alla classe stessa non viene allocata memoria, anche se ci sono istanze di altre classi all'interno della classe come sue proprietà. Pertanto, non ci può essere alcun riferimento alla classe, ma solo all'oggetto classe. La memoria viene allocata quando un'istanza (oggetto) di una classe viene dichiarata (creata).
In teoria, sì. Ma è necessario organizzarsi in modo tale che le transizioni tra i collegamenti gerarchici (condizionalmente - induzione e deduzione, cioè dal particolare al generale e ritorno) siano eseguite come una catena. Cioè, l'ordine dei puntatori dovrebbe essere strutturato in modo speciale per permettere di muoversi in qualsiasi direzione (giusta), senza eccessivi "giri" e "salti" nel ciclo. Pertanto, una semplice tabella di layout di puntatori probabilmente non funzionerà.