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
Classificazione chiara. Se vediamo che più oggetti hanno le stesse proprietà, è logico descrivere queste proprietà in un oggetto padre.
Cosa succede se l'oggetto eredita proprietà e metodi da classi diverse?
Se abbiamo a che fare con una struttura di dati in crescita e in ricostruzione dinamica (Knowledge Base), abbiamo bisogno di usare "materiale ereditato" di oggetti già preparati per crearne di nuovi. In questo caso, gli oggetti saranno sintetizzati per eredità multipla, raccogliendo materiale extra ereditato. E quindi non funzionerà correttamente. Cioè, arriveremo a oggetti degenerati non appena inizierà l'ereditarietà multipla. Questo è il problema...
Cosa succede se un oggetto eredita proprietà e metodi da classi diverse?
Se abbiamo a che fare con una struttura di dati che cresce e si ricostruisce dinamicamente (Knowledge Base), dobbiamo usare "materiale ereditato" di oggetti già preparati per crearne di nuovi. In questo caso, gli oggetti saranno sintetizzati per eredità multipla, raccogliendo materiale extra ereditato. E quindi non funzionerà correttamente. Cioè, arriveremo a oggetti degenerati non appena inizierà l'ereditarietà multipla. Questo è il problema...
Il toolkit pertinente è esposto. Nessuno ne ha bisogno tranne l'autore.
E ce n' è anche bisogno. Ma nessuno ne avrà bisogno.
Stessa situazione con KB, articoli, ecc.
Gli sviluppatori hanno introdotto caratteri personalizzati, servizi, tick, cache, pip, .... Sono sorpreso che l'abbiano fatto, visto che sono pochi, se non nessuno, ad averne bisogno.
Prendiamo la nuova modalità pips del tester. Chi ne ha bisogno? -Nessuno infatti! È nato come visione di una significativa ottimizzazione algoritmica del tester da parte dei suoi sviluppatori. Chi ha capito la sua utilità? -Nessuno! E così in tutto.
Ora il Tester è stato significativamente modificato. Ma queste modifiche non servono a nessuno. Beh, ci sono geek che lo apprezzeranno. Nella sua forma attuale, MT5-Tester è più fresco di tutti i suoi concorrenti. Ma per qualche motivo vogliono renderlo ancora più figo. Nessuno è in grado di valutare le sue caratteristiche attuali, per non parlare di quelle future. Gli sviluppatori sono diverse teste sopra i loro utenti. E chiaramente la motivazione dei cambiamenti nel Tester non è la monetizzazione (semplicemente non può essere, se nessuno lo capisce), ma un desiderio interno di fare qualcosa di inedito.
Nel nuovo oggetto, non usate le proprietà dei genitori "rimasti". Vedo però qualche malinteso con te. Perché "far nascere" un oggetto da uno le cui proprietà non sono necessarie?
Necessario, ma non completamente. Il nuovo oggetto usa 3 proprietà della classe A, 5 proprietà della classe B e 3 metodi di altre tre classi.
Cosa dovrebbe fare con il resto delle proprietà di queste classi? Come limitarlo da loro?
Necessario, ma non completamente. Il nuovo oggetto usa 3 proprietà della classe A, 5 proprietà della classe B e 3 metodi di altre tre classi.
Cosa dovrebbe fare con il resto delle proprietà di queste classi? Come limitarlo da loro?
Se un nuovo oggetto ha bisogno di un cuore, non ha bisogno di ereditare da un cuore. Il cuore dovrebbe essere reso parte del nuovo oggetto, come membro.
Eredita se il nuovo oggetto è un oggetto antenato. E usare l'inclusione se il nuovo oggetto è CON l'altro.
Impacchetta 3 proprietà della classe A in un oggetto. Ereditare da esso. Oppure si può non ereditare, ma rendere un oggetto con tre proprietà una proprietà dell'oggetto richiesto.
Tre proprietà da combinare in un oggetto e farne una proprietà di un nuovo oggetto? È qualcosa a cui pensare...
Ma l'ereditarietà attraverso molte lunghe catene genera problemi simili ad ogni passo. Più lunghe e diverse sono le catene di eredità, più "mescolanza" di proprietà e metodi avranno le ultime generazioni di oggetti e più difficile sarà derivare la loro catena individuale all'oggetto base.
Se non ereditato - non ci sarà accesso all'oggetto base. Se ereditato, la "parentela" multipla degli oggetti impedisce la tracciabilità della loro catena diretta all'oggetto base.
Diventa sempre più difficile isolare le proprie proprietà e metodi dalle altre classi.
Tre proprietà da combinare in un oggetto e farne una proprietà di un nuovo oggetto? È qualcosa a cui pensare...
Ma l'ereditarietà attraverso molte lunghe catene genera problemi simili ad ogni passo. Più lunghe e diverse sono le catene di eredità, più "mescolanza" di proprietà e metodi avranno le ultime generazioni di oggetti e più difficile sarà derivare la loro catena individuale all'oggetto base.
Se non ereditato - non ci sarà accesso all'oggetto base. Se ereditato, la "parentela" multipla degli oggetti impedisce la tracciabilità della loro catena diretta all'oggetto base.
Diventa sempre più difficile estrarre le loro proprietà e metodi da altre classi.
Peter, ti consiglio vivamente
https://en.wikipedia.org/wiki/Code_Complete
Se il cuore è necessario nel nuovo oggetto, non è necessario ereditare dal cuore. Il cuore dovrebbe essere reso parte del nuovo oggetto, come un membro.
Eredita se il nuovo oggetto è l'oggetto antenato. E usa l'inclusione se il nuovo oggetto CONTIENE un altro.
Tre proprietà da combinare in un oggetto e farne una proprietà di un nuovo oggetto? È qualcosa a cui pensare...
Ma l'ereditarietà attraverso molte lunghe catene genera problemi simili ad ogni passo. Più lunghe e diverse sono le catene di eredità, più "mescolanza" di proprietà e metodi avranno le ultime generazioni di oggetti e più difficile sarà derivare la loro catena individuale all'oggetto base.
Se non ereditato - non ci sarà accesso all'oggetto base. Se ereditato, la "parentela" multipla degli oggetti impedisce la tracciabilità della loro catena diretta all'oggetto base.
Diventa sempre più difficile isolare le proprie proprietà e metodi dalle altre classi.