Domande su OOP in MQL5 - pagina 51

 
Sergey Dzyublik:

1. Si scopre che la struttura di dati ad albero è tutta del male.
2. Povero C++ dove class == struct privata, cosa fare, probabilmente dovremmo rinunciare a strutture e classi.
3. E questo è giusto: nessun modello, nessun ordinamento per puntatori, nessun risparmio di memoria, specialmente per oggetti grandi...
4. Non dobbiamo dimenticare di proibire l'uso di interfacce e funzioni template, altrimenti non capirete con quale oggetto state lavorando - che orrore...

1. No, perché no? Se stai parlando di nodi dell'albero (o della lista collegata) che cambiano il loro stato, è semplicemente una questione di organizzare l'accesso a questo stato. In termini difunzionalità del codice, l'utente non dovrebbe avere accesso allo stato di un nodo.Tutte le iterazioni tra i nodi dovrebbero essere fatte accedendo all'albero stesso: tree.NextNode(myNode) o tree.Parent(myNode), non myNode.NextNode() o myNode.Parent().

Cioè lo stato che viene cambiato non dovrebbe essere disponibile pubblicamente.

2. Guarda, ho preso la struttura di Sharpe perché è impossibile prendere un riferimento/un puntatore ad essa. Cioè tutto è sotto il controllo del compilatore. Se non c'è questo controllo, si deve provvedere al controllo personale, per esempio, attraverso un'appropriata denominazione delle classi. Mettiamola così:

classe MyClass_mut; // mutabile

classe MyClass_immut; // immutabile

3, 4. Ti sbagli. Tutto può essere implementato ) Solo non dovresti pensare che tutti i dati dell'oggetto siano necessariamente copiati attraverso lo stack. Nel caso generale un oggetto contiene un puntatore interno ai dati. È come i puntatori intelligenti. Solo nel caso di oggetti modificabili, questo puntatore deve essere ancora più intelligente)

 
Aleksey Mavrin:

Dmitry, ti assicuro che sarei felice di ridere di te anche io, beh amo questo mestiere) ma in questo caso hai esagerato, anche particolarmente ben sorriso.

Sei solo molto confuso - uno SHOT non equivale a una COPIA DELL'OGGETTO, te l'ho fatto notare.

Se non è chiaro, lasciate che vi spieghi con un esempio - avete 1000 byte di oggetto, avete bisogno di 200 per lo snapshot, quindi perché copiare 800, specialmente se avete molti milioni di snapshot salvati.

p/s// E in generale. La gente non si rende conto che i modelli sono solo un esempio elementare di risoluzione di un problema TIPICO elementare. E infatti i compiti non sono elementari, ma più complicati. E per risolvere i problemi reali gli schemi sono necessari, ma spesso non nella forma pura del libro, ma adattati a un compito particolare, eventualmente combinati tra loro, eventualmente con l'aggiunta di qualche improvvisazione, espressa a volte in una semplificazione, se il compito lo permette, o viceversa "ponderazione" della realizzazione.

Di nuovo, perché avete bisogno di incapsulamento e interfacce - questo probabilmente non può essere capito se il vostro QI è inferiore a Wasserman, o se non avete partecipato a progetti reali, quando diverse parti del progetto sono cambiate da diverse persone simultaneamente, e non seguire i principi di base di OOPD comporta costi enormi nel catturare i bug. Davvero, perché tutto questo per la timbratura di Expert Advisors per il mercato))

Lei confonde gli algoritmi per risolvere i compiti di programmazione con i cosiddetti, e oggi di moda, "design patterns" legati esclusivamente alla OOP. E si confondono molte altre cose, e si legge con disattenzione. Un po' prima ho scritto: usate la struttura. Ma se avete letto quel post e non ho scritto sulla funzione di copia dell'intera classe, sareste arrivati al punto che siamo adulti e non c'è bisogno di fare lavoro extra con strutture inutili quando dovremmo fare tutto in modo maturo - basta fornire la possibilità di copiare l'intera classe.

 
Aleksey Mavrin:

...

Di nuovo, perché avete bisogno di incapsulamento e interfacce - questo è probabilmente impossibile da capire se il vostro QI è più basso di quello di Wasserman, o se non avete partecipato a progetti reali, quando diverse parti del progetto sono cambiate da diverse persone simultaneamente, e il non rispetto dei principi elementari di OOPD comporta costi enormi nel catturare i bug. Davvero, perché tutto questo per la timbratura di Expert Advisors per il mercato))

.

Sergey Dzyublik:

...
4. Non devo dimenticare di proibire l'uso di interfacce e funzioni template, altrimenti non si capisce con quale oggetto si sta lavorando - che orrore...

Qualche volta, da qualche parte, leggete cosa sono le interfacce e perché sono necessarie.

-

Oh, e questo... State seriamente confondendo la capacità di salvare tutti o alcuni campi di un oggetto con la funzione undo/redo? Parliamo di Photoshop, sai come si fa.

-

E chi di voi è tutto cioccolatoso e mi manda una mail?

-

Qual è il problema, comunque? Ho forse scosso le fondamenta della vostra fede negli Schemi Santi?

 
Un dilettante autodidatta che non ha mai visto altro che mql, che insegna agli uomini come scrivere programmi, è divertente entrare e leggere)
 

stava rovistando nella libreria qui.

Grande scoperta: "Introduzione all'intelligenza artificiale e ai sistemi esperti con illustrazioni in BASIC" 1987. Uno dei capitoli "Il concetto di programmazione orientata agli oggetti".

Credetemi - Nulla è cambiato...

 
Maxim Kuznetsov:

stava rovistando nella libreria qui.

Grande scoperta: "Introduzione all'intelligenza artificiale e ai sistemi esperti con illustrazioni in BASIC" 1987. Uno dei capitoli "Il concetto di programmazione orientata agli oggetti".

Credetemi - Nulla è cambiato...

Molte cose sono cambiate, non c'era una chiesa di devoti dei Sacri Design Patterns allora. E anche il club delle vittime di c++ non si era ancora formato a quel tempo.

 
Dmitry Fedoseev:

Molte cose sono cambiate, allora non c'era una chiesa di devoti ai modelli di Holy Design.

non c'era una chiesa di adoratori di saint design allora. questo non esiste nemmeno ora, puoi cercare su runet, se il numero di domande sui modelli in runet è molto piccolo, significa che non esiste come massa, le domande "libro" degli studenti non contano.

non hanno niente da leggere, ma è comodo quando si vuole scalare un progetto, in generale, la struttura del programma è inizialmente corretta

 
Dmitry Fedoseev:

Molte cose sono cambiate, non c'era la Chiesa dei Santi Patters of Design.

"Design patterns" è solo un accordo per chiamare le stesse cose frequenti con gli stessi nomi. E a proposito, il termine viene dall'architettura (dove si tratta di sculture/ponti/portali/portali).

A volte cose simili si risolvono con tecniche simili, non sempre... Ma è utile mettersi d'accordo sulla somiglianza delle cose e dei metodi per capirsi.

Ma naturalmente, c'è chi dice "dai a un pazzo un fallo di vetro e lui lo romperà e si taglierà".

 
Igor Makanu:

Questo non esiste nemmeno ora, si può cercare in runet, se il numero di domande sui modelli in runet è molto piccolo, allora non esiste come massa, le domande "libro" degli studenti non contano

Non c'è niente da leggere, ma è utile quando si vuole scalare un progetto.

Non contengono nulla. Quanti modelli avete studiato?

 
Dmitry Fedoseev:

Niente è incorporato in essi. Quanti modelli avete studiato?

Cosa si intende per "studiato"?

se ho letto le descrizioni su diversi forum, allora ne ho a dozzine

Se applicato in MQL, allora uno - la strategia funziona, scala, il refactoring è facile - posso buttare via tutte le cose inutili per il tester per renderlo più veloce, o andare direttamente a una demo - è generalmente conveniente e pratico