Parlare dell'OLP nel salone - pagina 7
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
ZS: a proposito, non ho visto un solo desiderio di copertura di qualsiasi argomento in tutto il thread, come al solito, il solito battibecco.
A giudicare dalla scelta dell'esempio iniziale, ci sono ragionevoli dubbi sulla qualità della copertura
Possiamo essere più specifici su chi sono e cosa non hanno imparato? I moderatori non hanno imparato a pulire o qualcos'altro)
ZS: a proposito, in tutto il thread non ha visto un solo desiderio di coprire qualsiasi argomento, come sempre, il solito wrangling. Così ho deciso di registrare video su YouTube da zero su come funziona OOP, almeno sarà di qualche utilità. Comunque, tra un po' il ramo finirà nel branch_sucker.
Sarò più preciso: non hanno imparato ad usare l'OOP.
Alexey, penso che tu sia ben consapevole del fatto che non si può semplicemente imparare l'OOP. C'è una conoscenza formale di OOP: ereditarietà, incapsulamento, polimorfismo - tutti questi mantra sono spesso ripetuti, ma c'è più male che bene da qualcuno che li memorizza e li applica violentemente e inappropriatamente, come una classe Expert che eredita da un modulo MM (ciao agli sviluppatori SB:).
Per quanto riguarda MQL - è un linguaggio molto debole in termini di OOP: il controllo dei tipi è completamente assente (almeno hanno implementato il casting sicuro), la riflessione è nella sua infanzia e molto limitata, non ci sono interfacce. La domanda sorge spontanea: che tipo di OOP può essere insegnata in MQL? Che dire, se gli sviluppatori stessi stanno facendo un tale casino nella Standard Library che a volte è semplicemente spaventoso.
Per essere più precisi: non abbiamo imparato l'OOP.
Alexey, penso che tu sia ben consapevole del fatto che non si può semplicemente imparare l'OOP. C'è una conoscenza formale di OOP: ereditarietà, incapsulamento, polimorfismo - tutti questi mantra sono spesso ripetuti, ma c'è più male che bene da qualcuno che li memorizza e li applica in modo violento e inappropriato, come una classe Expert che eredita da un modulo MM (ciao agli sviluppatori SB:).
Per quanto riguarda MQL - è un linguaggio molto debole in termini di OOP: il controllo dei tipi è completamente assente (almeno hanno implementato il casting sicuro), la riflessione è nella sua infanzia e molto limitata, non ci sono interfacce. La domanda sorge spontanea: che tipo di OOP può essere insegnata in MQL? Che dire, se gli sviluppatori stessi modellano una tale gobba nella Standard Library che a volte fa solo paura.
Sì, è debole, ma i progetti di media gravità possono ancora essere fatti. SB è stato fatto da diverse persone con diversi livelli di formazione. E manca l'essenziale, io uso ancora il tuo CDictionary, ed è l'albero dovuto.
Allora, che si fa adesso, ci si sdraia e si muore? )) Potresti entrare in dll dopo tutto.
Si può imparare l'OOP, credo. L'ho imparato da solo. E lo stesso hanno fatto altri.
E si può ancora imparare l'OOP, credo. L'ho imparato da solo. E così altri.
Quindi bisogna imparare dagli esempi giusti. Ma non ce ne sono a SB. Prendete CObject per esempio - non fornisce il controllo del tipo, non fornisce lavoro a livello di interfaccia con gli oggetti, ma contiene metodi senza senso come Save() e Load() che non sono mai ridefiniti nella pratica. I puntatori m_prev e m_next sono usati in una singola classe CList, ma sono presenti come zavorra per tutte le sue classi discendenti. Il più utile è il metodo Comparer(). In realtà viene sovrascritto il più delle volte. Ma in senso buono Comparer() è un'interfaccia, non dovrebbe essere definita nel CObject, ma come una classe separata.
Apparentemente static e const (questo non è OOP) non sono necessari.
Per quanto riguarda l'OOP, è molto interessante come la prossima funzione, che ha un'ampia applicazione pratica (per niente astratta), apparirebbe in stile procedurale?
Ovviamente, qualsiasi OOP può essere riscritta in stile procedurale. Ma mi interessa la pratica. Così ho preso il codice minuscolo di cui sopra, dove anche l'OOP è usato al minimo.
Quindi quanto è più bello/meglio comodo/meglio leggibile/meglio corretto lo stile procedurale rispetto all'OOP in questo esempio? Beh, non per parlare per qualche pagina, ma solo per confrontare il codice sorgente breve procedurale vs OOP. Chiedo agli avversari di OOP di mostrare una masterclass. Questo non è il temuto MT5, ma il buon vecchio MT4.
Come si impara a programmare allo stesso modo? :) sembra molto bello.
O forse hai bisogno di cambiare la tua mentalità.
per esempio, non sapevo che le strutture possono essere usate quasi allo stesso modo delle classi, con un costruttore
per esempio, non sapevo che le strutture possono essere usate quasi allo stesso modo delle classi, con un costruttore
quali stampi si può imparare a programmare esattamente allo stesso modo? :) sembra molto bello
o forse devi cambiare anche la tua mentalità.
per esempio, non sapevo che le strutture possono essere usate quasi come classi, con un costruttore
E posso chiedere: quale genio vedi nel codice di fxsaber? Forse sono gli effetti collaterali di IsChange che vi hanno affascinato, o l'idea che lo stato del sistema debba essere duplicato a livello utente?
Posso chiedere: quale genio vedi nei codici di fxsaber? Forse sono gli effetti collaterali di IsChange che vi affascinano, o l'idea che lo stato del sistema debba essere duplicato a livello utente?
Probabilmente perché difficilmente capisco questo codice :)
Scusa, sono un programmatore dilettante... conosco solo l'OOP ad un livello base
In C++, classe e struttura sono le stesse, solo alcuni default sono diversi.
Che figata, non lo sapevo... Credo di dover imparare meglio i professionisti.
Quindi bisogna imparare dagli esempi giusti. E non ce ne sono a SB. Prendete CObject per esempio - non fornisce il controllo del tipo, non fornisce lavoro a livello di interfaccia con gli oggetti, ma contiene metodi senza senso come Save() e Load(), che non sono mai sovrascritti nella pratica. I puntatori m_prev e m_next sono usati in una singola classe CList, ma sono presenti come zavorra per tutte le sue classi discendenti. Il più utile è il metodo Comparer(). In realtà viene sovrascritto il più delle volte. Ma in senso buono Comparer() è un'interfaccia, non dovrebbe essere definita nel CObject, ma come una classe separata.