Domande su OOP in MQL5 - pagina 54
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
https://www.mql5.com/ru/forum/85652/page52#comment_16423899 Perché questa sorpresa?
non sorpresa ma incredulità. il tuo livello di padronanza dell'argomento è perfettamente evidente dai post in questo thread.
Sei un esperto di livelli? ...comunicazioni urbane.
sì, continua, dimmi, i titoli letti non significano studiati, sei come STL con i modelli che è "stl è un vettore"
Sei venuto qui e hai spezzato il cuore di un uomo con la testa grossa.
Era dispiaciuto? Quell'uomo stava sognando e lei stava al gioco.
))))
Per cosa ti sei sentito dispiaciuto?
Dmitry Fedoseev,
Perché ti arrabbi tanto, mia cara?)
Beh, se non vi piacciono i modelli, beh, non usateli. O non ti piacciono i loro nomi, usali, ma non chiamarli "modelli". Fate come volete, finché vi va bene.
Ma negare il loro significato è vuoto. Così come per esagerare ;)
Lei confonde gli algoritmi per risolvere i problemi di programmazione con i cosiddetti, e ora di moda, "design patterns" legati esclusivamente all'OOP. E si confondono molte altre cose, e si legge con disattenzione. Un po' prima ho scritto: usate la struttura. Ma se avessi letto quel post e non avessi menzionato la funzione di copiare l'intera classe, saresti arrivato al punto che siamo adulti, quindi perché preoccuparsi di strutture inutili quando dovremmo fare tutto in modo maturo - basta fornire la possibilità di copiare l'intera classe.
1. Questo thread riguarda l'OOP, quindi non sono confuso.
2. La struttura cambia in qualche modo l'essenza del modello Snapshot?
3. non c'è lavoro extra da fare. È solo una questione di pesare cosa sarà più - lavoro "extra" ora, o più tardi quando si espanderà e svilupperà il progetto.
4. Non è necessario nell'istantanea.
1. Il thread riguarda l'OOP, quindi non sono confuso.
2. La struttura cambia in qualche modo l'essenza del modello Snapshot?
3. non c'è bisogno di fare lavoro extra. È solo una questione di pesare cosa sarà più - lavoro "extra" ora, o più tardi quando si espanderà e svilupperà il progetto.
4. Non è necessario in un'istantanea.
Sei bloccato nelle minuzie. Non è interessante. Il punto principale della discussione sul pattern "keeper" qui era che promette una sorta di conservazione dell'incapsulamento, ma è implementato creando un paio di metodi pubblici per ogni campo. Divertente come non hai ricevuto il messaggio più importante.
E posso chiedere, cos'è un modello nel senso locale della parola? Sono un po' perso, davvero. È un involucro per alcuni compiti o uno stato di un compito? Con le classi, le strutture, i puntatori e le dinamiche, penso di capirle meglio. È anche chiaro che i termini non hanno ancora preso piede e sono stati definiti. E ci sono condizioni che possono essere utilizzate per determinare quando dovrebbero essere applicate. Nel caso di photoshop e del rendering è chiaro, ma questi non sono compiti di serie temporali. O forse mi sfugge qualcosa e c'è qualcosa in comune nel rendering visivo e nella GA VR?
Qui tutto è chiaro, specifico e canonico. C'è un LIBRO! Questo LIBRO espone questi modelli, ed è di questo che stiamo parlando. Il libro si chiama Design Patterns o qualcosa del genere. Ma non solo il libro, ci sono un sacco di siti su di loro su Internet e anche in Wikipedia, la cosa principale è che l'argomento è canonizzato)) ...e chi non capisce i design pattern - plebeo, e chi li ha padroneggiati - ha padroneggiato la vita stessa! Amen!
Non sto rivendicando la mia opinione, potrei averla letta da qualche parte, ma imho, ci sono solo due problemi nella programmazione: la struttura corretta del programma e trovare rapidamente un buon nome per una variabile, e il resto si fa 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 swoop in)))
Esattamente - la struttura giusta. Ecco perché dovreste considerare tutte le possibili opzioni di questa struttura, analizzare i loro pro e contro in un dato compito (tenendo conto dei requisiti di scalabilità e manutenzione, ecc) e scegliere la migliore.
E i famigerati modelli stessi (qualunque cosa siano esattamente) non sono nemmeno una variante della struttura qui, ma solo un punto di riferimento per il cervello. È come "Se il problema corrisponde alla descrizione del compito del modello X, allora può essere risolto applicando il modello X", ma si può risolvere anche in un mucchio di altri modi.
E in generale, questi 27 pattern di base sono nati come una sorta di suggerimento per i programmatori su problemi tipici come risolverli seguendo i principi OOP. Se non c'è un compito di seguire i principi, come ha fatto Dmitry con le strutture, allora non c'è bisogno di modelli.