Domande su OOP in MQL5 - pagina 50
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
Dimitri, in questo caso probabilmente stai confondendo un po' gli obiettivi dei modelli Keeper e Prototype, e tutte le loro possibili combinazioni e manifestazioni. Primo: l'istantanea non deve necessariamente copiare l'intero oggetto, a differenza di Prototype.
E sì, la necessità dell'incapsulamento si manifesta soprattutto nei grandi progetti con molte persone. Per giocattoli come la maggior parte di questi, è un po' ridondante.
A cosa si riduce - sedersi e discutere in tutta serietà sul fatto che un valore può essere assegnato a una variabile e poi può essere usato. Oh sì - quando si programma qualsiasi cosa su qualsiasi cosa, molte volte si assegnano valori diversi a variabili diverse e poi si usano. Ma ora si chiama in modo diverso, e ora quando se ne parla, bisogna aggrottare le sopracciglia e mettere uno sguardo serio.
Ed è importante non fare un errore, se tutti i campi sono salvati, è Prototipo, e se non tutti, è Keeper, o i ragazzi rideranno.
Non sei un membro della setta "stanno installando internet, non ci serve, non abbiamo bisogno del tuo internet...", vero? ???
1. il custode, per progettazione, è simile al modello che usano per memorizzare lo stato durante la digitazione con contenuto mutevole per eseguire il rollback delle modifiche quando queste modifiche non sono una ma diverse centinaia. Per esempio, editor di foto, editor di testo...
L'ho trovato dopo aver scritto -https://refactoring.guru/ru/design-patterns/memento
2. Fondamentalmente è una cattiva pratica non conoscere e non capire il soggetto per criticare qualcosa lì...
3. Come può qualcosa che già non si capisce diventare più confuso e difficile da capire?
4. Il resto sta a voi...
Cosa c'entra il GOP?
Per caso, non sei un membro della setta "loro installano intinet, noi non ne abbiamo bisogno, tu intinet"? ???
1. il custode, per progettazione, è simile al modello che usano per memorizzare lo stato durante la digitazione con contenuto mutevole per eseguire il rollback delle modifiche quando queste modifiche non sono una ma diverse centinaia. Per esempio, editor di foto, editor di testo...
L'ho trovato dopo aver scritto -https://refactoring.guru/ru/design-patterns/memento
2. Fondamentalmente è una cattiva pratica non conoscere e non capire il soggetto per criticare qualcosa lì...
3. Come può qualcosa che già non si capisce diventare più confuso e difficile da capire?
4. Il resto sta a voi...
Sono con voi fino in fondo! Grazie per aver argomentato il mio punto... Ero pigro))
Aggiungerei solo al punto 1 che lo snapshot non memorizza necessariamente tutti i dati dell'oggetto, e ci possono essere diversi rami con centinaia di snapshot dello stesso oggetto "snapshot da lati diversi". In questo caso, immagazzinare centinaia di copie di dati inutilizzati è veramente la pratica peggiore.
Si è arrivati a questo - sedersi lì e parlare in tutta serietà di come ad una variabile può essere assegnato un valore e poi essere usata. Oh sì - quando si programma qualcosa in qualsiasi cosa, molte volte si assegnano valori diversi a variabili diverse, e poi si usano. Ma ora si chiama in modo diverso, e ora quando se ne parla, bisogna aggrottare le sopracciglia e mettere uno sguardo serio.
Ed è importante non fare un errore, se tutti i campi sono salvati, allora è il Prototipo, e se non tutti, allora il Guardiano, o i ragazzi rideranno.
Dmitry, ti assicuro, sarei felice di ridere di te, beh, mi piace) 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 i modelli sono necessari, ma spesso non in forma pura di libro, ma adattati a un compito particolare, possibilmente combinati tra loro, possibilmente 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 è al di sotto di 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 timbrare EAs per il mercato))
Sergey Dzyublik:
1. Un custode, simile nel design al modello utilizzato per memorizzare lo stato quando si scrive con contenuto mutevole per eseguire il rollback dei cambiamenti quando questi cambiamenti non sono uno ma diverse centinaia. Per esempio un editor di foto, un editor di testo...
2. Infatti, è cattiva pratica non conoscere e non capire il soggetto per criticare qualcosa lì...
Il punto chiave è stato evidenziato: è il contenuto modificabile che è la radice di molti problemi di uso improprio di OOP. Anche io sono stato a lungo in questo, ma con l'esperienza arriva gradualmente la comprensione.Il codice dove ci sono molte interrelazioni tra gli oggetti (puntatori) e allo stesso tempo questi oggetti sono modificabili - è un terribile spaghetto che non cambierà. Quindi, dovremmo sforzarci di rendere immutabili gli oggetti di riferimento. Solo gli oggetti di valore devono essere modificabili, cioè strutture e tipi semplici, e anche i puntatori.
In questo caso, è auspicabile dichiarare l'oggetto iniziale come una struttura, non come una classe. Poi si può cambiare il suo contenuto. In questo caso, naturalmente, nessun puntatore ad esso sarà preso e salvato come nel modello discusso, e questo è corretto. Per cambiare gli oggetti è necessario fare esplicitamente riferimento ai loro metodi, o passarli come argomento a una funzione, cioè
o
Non così:
sembra che stiamo cambiando un oggetto memento, ma in realtà stiamo cambiando qualche altro oggetto, che probabilmente si trova altrove nel programma. Questo crea un effetto collaterale: è lo stesso che cambiare una variabile globale in un posto e usare il suo valore in un altro posto.
Cioè un memento non dovrebbe memorizzare un riferimento all'oggetto originale. Dovrebbe memorizzare solo il contenuto. Questa è la mia opinione, ma penso di non essere lontano dalla verità )
Non sto rivendicando la mia opinione, probabilmente letta da qualche parte, ma imho, ci sono solo due problemi nella programmazione: struttura corretta del programma e trovare rapidamente un buon nome per una variabile, e tutto il resto è fatto abbastanza facilmente
Anch'io sono serio.
Grazie, leggerò i tuoi schemi
Aspetterò, nel caso in cui appaia qualcun altro, ma solo a livello di domande di principianti e formatori akademvelopers che piombano su ))))
1) Il codice, che ha molte interrelazioni tra gli oggetti (puntatori), e allo stesso tempo gli oggetti sono modificabili, è uno spaghetto assurdo, in cui il diavolo non può capire dopo. Quindi, è necessario sforzarsi affinchégli oggetti di riferimento siano immutabili.
2)Solo gli oggetti di valore, cioè strutture e tipi semplici, e i puntatori dovrebbero essere modificabili.
3) In questocaso, è auspicabile dichiarare l'oggetto iniziale come una struttura, non come una classe. Poi si può cambiare il suo contenuto. Naturalmente, non si può prendere un puntatore ad esso e salvarlo come nel modello discusso, e questo è corretto.
4) Glioggetti devono essere cambiati chiamando esplicitamente i loro metodi o passandoli come argomento in una funzione.
Sembra chestiamo cambiando l'oggetto memento ma in realtà è qualche altro oggetto che probabilmente si trova altrove nel programma. Questo crea un effetto collaterale.
1. Si scopre che la struttura dei dati Tree è tutto dal male...
2. Povero C++ dove class == struct privata, cosa fare, probabilmente dovremmo abbandonare 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...