Domande su OOP in MQL5 - pagina 55
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
Sei bloccato nelle minuzie. Poco 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 colto il messaggio più importante.
Non sono bloccato, sto cercando, per rispetto nei tuoi confronti come interlocutore, di dare un senso alle tue parole e svelare le tue autocontraddizioni. Apparentemente invano.
Non credo che nessuno qui sia interessato alla tua schiuma di "schemi sacri".
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!
Sei come un pagliaccio, ahimè. Basta lasciare il thread OOP, se ti disgusta così tanto)
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 web su di loro in Internet e anche in wikipedia, la cosa principale è che il soggetto è canonizzato)).
Tutto ovviamente, se ci sono fino a 100 variabili globali allora possiamo fare a meno delle funzioni, se ci sono più di 50 EA allora le classi sono appropriate, e ho capito bene, se ci sono più di 20 sviluppatori e più di 20 metodi e il numero di variabili è sconosciuto, allora il modello è necessario. Se c'è un solo sviluppatore, allora non così tanto?
Non sono bloccato, sto cercando, per rispetto nei tuoi confronti come interlocutore, di dare un senso alle tue parole e svelare le tue autocontraddizioni. Apparentemente per niente.
Non credo che nessuno qui sia interessato alla tua schiuma di "schemi sacri".
Non ho contraddizioni, la contraddizione è nei tuoi pattern, ne ho già scritto due volte, lascia che ti ricordi: un pattern "keeper" promette la conservazione dell'incapsulamento ma è implementato creando due metodi pubblici per ogni campo privato.
E mi dica, dove ha visto una contraddizione nel mio schema?
Naturalmente, se ci sono fino a 100 variabili globali allora possiamo fare a meno delle funzioni, se ci sono più di 50 EA allora le classi sono appropriate, e ho capito bene, se ci sono più di 20 sviluppatori, più di 20 metodi e il numero di variabili è sconosciuto, allora il pattern è necessario. Se c'è un solo sviluppatore, allora, se è così, non tanto?
Gli sviluppatori hanno bisogno di cervelli, in primo luogo.
Sei come un pagliaccio, ahimè. Lasciate il thread OOP se ne siete così disgustati)
Quale "cosa"? Mi piace l'OOP. Ma questi famigerati modelli hanno una relazione piuttosto lontana con la vera OOP.
Non ho una contraddizione, la contraddizione è nei tuoi pattern, ne ho già scritto due volte, ricordo: il pattern "keeper" promette di preservare l'incapsulamento, ma è implementato creando due metodi pubblici per campo privato.
Ora ho capito. Hai appena riversato l'emozione contro tutti gli schemi, che il significato delle tue parole si è perso.
Ma in Snapshot questo problema è risolto utilizzando classi annidate per Snapshot.
Se non è supportato dalla lingua, sono d'accordo, c'è questo inconveniente, ma può essere aggirato da alcuni trucchi che ricordo.
Ora ho capito. Hai appena annacquato l'emozione contro tutti i modelli, che il significato delle tue parole si è perso.
Ma in Snapshot questo problema è risolto utilizzando classi annidate per l'istantanea.
Se non è supportato dalla lingua, sono d'accordo, questo inconveniente è presente, ma può essere aggirato con alcuni trucchi, ricordo.
Hai sbagliato tutto.
Non importa se è possibile scrivere una classe annidata o meno, non è una grande differenza. C'è un esempio di codice in questo thread con una classe annidata e due metodi pubblici per campo privato.
Quale 'cosa'? Mi piace l'OOP. Ma questi famigerati modelli hanno una relazione piuttosto lontana con la vera OOP.
Lo dirò di nuovo - nessuno prega sugli schemi. Questi sono solo modelli che possono essere usati come riferimento.
Ma affermare che non hanno nulla a che fare con OOP, beh, non è vero.
Nella mia modesta esperienza, in forma di libro puro, sono raramente usati, con rare eccezioni. Di solito se c'è un compito adatto a un pattern, va insieme ad almeno un paio di altri compiti per altri pattern, ed è così che incrociare 2-3-10+ pattern, è un lavoro per il cervello del programmatore/architetto.
Tu non capisci niente.
Il fatto di poter scrivere una classe annidata o meno è irrilevante, non è una grande differenza. In questo thread c'è un esempio di codice con classe annidata e due metodi pubblici per campo privato.
Mi hai già detto tante volte che sono uno stupido e che non capisco niente, sono fiero della mia compostezza per non averti mandato un meritato vaffanculo molto tempo fa)
Fondamentalmente - una classe annidata rende opzionali i metodi pubblici per i campi privati, questa è la violazione dell'incapsulamento di cui stai scrivendo. Altri argomenti?