Domande su OOP in MQL5 - pagina 49
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
E lo scopo di questi giochi mentali selvaggi? Lo "scopo" (tra virgolette, perché... gladiolo) del pattern è quello di"senza rompere l' incapsulamento, fissare e preservare lo stato interno dell'oggetto" (tra virgolette, perché citare). Ma non si può fare a meno del metodo setState(). Allora, dov'è il risparmio dell'incapsulamento qui? Scrivere altri due metodi per ogni campo privato... Sì... bene, l'incapsulamento è conservato.
E siate onesti, userete questo approccio nella pratica? Ne dubito. In pratica, lo renderai esplicito e trasparente - per esempio, una struttura con lo stesso set di campi e un paio di metodi per salvare e ripristinare. E poi l'incapsulamento sarà veramente conservato, ci saranno solo due nuovi metodi: per salvare lo stato e per ripristinare.
OK, lo salverò, avevo bisogno di testare il principio di lavoro, forse questo è quello che stavo cercando - un codice per il tester e per l'EA funzionante, che può salvare il suo stato, e nel tester al contrario non sprecare risorse su "gesti extra" - parte di tale modello può essere coperto da #ifdef -ami ;)
Sto cercando di capire il significato di questo crammer con il guardiano, ma non vedo nessun uso particolare. In effetti, è una cattiva pratica di programmazione attraverso la creazione di effetti collaterali. Quando si cambia un oggetto se ne cambia un altro. Di conseguenza, il codice diventa ingarbugliato e difficile da capire. È meglio lottare per la purezza del codice, imho.
Cosa vi impedisce di copiare semplicemente un oggetto in un altro oggetto e poi copiarlo di nuovo? È essenzialmente la stessa cosa, solo più corretta e più chiara.
Se questo singleton ha sia setter che getter allo stesso tempo (cioè permette di cambiare il suo stato e di leggerlo), è equivalente a lavorare con variabili globali. E ogni programmatore sa che lavorare cambiando lo stato globale è male. Ma il singleton in qualche modo non conta )
Sto cercando di capire il significato di questa cosa del custode, ma non vedo nessun beneficio particolare. In effetti, è una cattiva pratica di programmazione creando effetti collaterali. Quando cambi un oggetto, ne cambi un altro. Il risultato è che il codice diventa ingarbugliato e difficile da capire. È meglio lottare per la purezza del codice, imho.
È più semplice, sto imparando le cose tecniche
Sono abituato a valutare la condizione di un sistema automatizzato dal punto di vista di una macchina a stati finiti, e voglio sempre mantenere un'"istantanea" dello stato del sistema come riserva ))))
Sono più abituato a valutare lo stato di un sistema automatizzato dal punto di vista di una macchina a stati finiti, e questo mi fa sempre desiderare di poter tenere un "calco" dello stato del sistema come backup )))
È solo che una tale implementazione è eccessivamente complicata e confusa, secondo me.
L'obiettivo è chiaro, è solo troppo complicato e confuso, secondo me.
Ahimè, la gente è così - finché non avrò i miei calci e i miei colpi di culo, è improbabile che li ottenga)))
Ahimè, le persone sono così - finché non avrò i miei colpi e urti, è improbabile che lo capisca)))
Non c'è niente di male se qualcuno studia questi schemi, è fantastico - è ginnastica per il cervello, ecc. ecc. E poi, ad un esame più attento, si scopre che questo è un falso infernale, un meme per allontanare i fessi dalla realtà, proprio come imparare il BASIC visivo scrivendo applicazioni per console.
Studiare questi modelli è interessante, se non altro dal punto di vista dell'apprendimento degli scarafaggi di qualcuno - cosa sono in natura.
E se ci stiamo davvero avvicinando al compito di preservare lo stato di un oggetto, il modo è quello di rendere possibile la copia di un oggetto in un altro, che sia un semplice metodo o un sovraccarico = overloading. E dopo questo, potreste non voler incapsulare questa funzione.
E se ci avviciniamo davvero al compito di preservare lo stato di un oggetto, il modo per farlo è rendere possibile la copia di un oggetto in un altro, come si vuole, sia attraverso un metodo che attraverso un overload =. E dopo questo, potreste non voler incapsulare questa funzione.
In realtà, qualsiasi sistema tecnico può essere progettato sulla base di 3 principi fondamentali:
- è conforme all'ultimo standard
- i nostri nonni hanno costruito così, non c'è bisogno di reinventare la ruota
- Non dovreste costruirlo con merda e bastoni e poi modificarlo
)))
Scherzo, ho tempo per leggere e giocare con le opzioni nella mia testa, ne approfitto, così come l'opportunità di ottenere spiegazioni veloci per i punti poco chiari sul forum ;)
Sto cercando di capire il significato di questa cosa del custode, ma non vedo nessun beneficio particolare. In effetti, è una cattiva pratica di programmazione creando effetti collaterali. Quando cambi un oggetto, ne cambi un altro. Di conseguenza, il codice diventa ingarbugliato e difficile da capire. È meglio lottare per la purezza del codice, imho.
Cosa vi impedisce di copiare semplicemente un oggetto in un altro oggetto e poi copiarlo di nuovo? È praticamente la stessa cosa ma più corretta e più chiara.
Se questo singleton ha sia setter che getter allo stesso tempo (cioè permette di cambiare il suo stato e di leggerlo), è equivalente a gestire variabili globali. E ogni programmatore sa che lavorare cambiando lo stato globale è un male. Ma il singleton in qualche modo non conta )
Suppongo che questo sia un tipico punto di vista di un programmatore che non ha mai avuto niente a che fare con progetti seri su larga scala? Perdonami per essere schietto, ma non vedo altre spiegazioni per chiamare le basi cattive pratiche )
Non c'è niente di male se qualcuno studia questi modelli, è fantastico - esercizi per il cervello, ecc. ecc. E poi, ad un esame più attento, si scopre che è una specie di falso infernale, una specie di meme per attirare i babbei lontano dalla realtà, proprio come imparare il BASIC visivo scrivendo applicazioni per console.
Studiare questi modelli è interessante, se non altro dal punto di vista dell'apprendimento degli scarafaggi di qualcuno - cosa sono in natura.
E se ci stiamo davvero avvicinando al compito di preservare lo stato di un oggetto, il modo è quello di rendere possibile la copia di un oggetto in un altro, che sia un semplice metodo o un sovraccarico = overloading. E al di là di questo, forse il desiderio di incapsulare questa caratteristica cadrà.
Dmitry, probabilmente in questo caso confondi un po' i compiti dei modelli Keeper e Prototype, e tutte le loro possibili combinazioni e manifestazioni. La prima 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 compiti qui, è eccessivo, ovviamente)
1) Sto cercando di capire il senso di questa cosa del custode, ma non ne vedo il beneficio.
2) È essenzialmente una cattiva pratica di programmazione creare effetti collaterali.
3) Quando si cambia un oggetto, se ne cambia un altro. Di conseguenza, il codice diventa ingarbugliato e difficile da capire. È ancora meglio lottare per la purezza del codice, imho.
4) Cosa vi impedisce di copiare semplicemente un oggetto in un altro oggetto e poi copiarlo di nuovo? In sostanza è lo stesso ma più corretto e chiaro.
Se questo singleton ha sia setter che getter allo stesso tempo (cioè permette di cambiare il suo stato e di leggerlo), è equivalente a lavorare con variabili globali. Ogni programmatore sa che lavorare cambiando lo stato globale è un male. Ma il singleton in qualche modo non conta )
Non fai parte della setta "loro lo installano, a noi non serve, è tuo..."? ???
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...