Una domanda per gli esperti di OOP. - pagina 3
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
Creatura.
Flora/Fauna
Sottospecie
Specie
Famiglia
ecc.
È questo che vuoi?
Beh, è una semplice eredità dall'entità base "Entity".
Ma si può andare più in profondità di così - ci sono monocellulari/multicellulari, e questo è tutto per gli esseri viventi. Ma ci sono anche quelli non viventi. Tutto dipende dai compiti, per i quali è necessario trovare le proprietà di un oggetto base, ed ereditare da esse.
Se sei davvero pazzo, puoi arrivare agli atomi e iniziare a dividerli in parti alla ricerca di un oggetto padre fondamentale (fai attenzione - una reazione di fissione può diventare una reazione a catena, e distruggerai mezzo mondo :))
Giusto. A prima vista, il concetto di OOP è ideale per costruire una gerarchia. Ma come si lavora con una gerarchia costruita tramite OOP? È un mare di sintassi e complessità di transizioni tra i collegamenti a causa dei diritti di accesso alle classi e ai loro contenuti. È qui che inizia il sovraccarico, come conseguenza della divisione in classi. OOP da un lato permette di costruire una gerarchia, dall'altro rende estremamente difficile lavorare con essa.
Beh, no. OOP dà un accesso molto facile a qualsiasi membro della gerarchia in qualsiasi posizione.
Iniziate trovando il vostro oggetto base con le proprietà minime richieste.
Il resto degli oggetti eredita da esso. Per evitare di reinventare la ruota, il vostro oggetto base dovrebbe ereditare la classe CObject della libreria standard. Questo permette di creare la propria gerarchia di oggetti senza bisogno di reinventare le liste
CObject --> CBaseObject --> la vostra gerarchia.
In CBaseObject dovete avere un metodo virtuale che restituisca questo oggetto. Poi ogni vostro discendente avrà questo metodo di conseguenza, e restituirà esattamente l'oggetto discendente. La classe base di CObject ha già un metodo -Type(). Se avete lo stesso metodo virtuale di CBaseObject, e restituisce il tipo di oggetto, saprete a quale oggetto avete avuto accesso.
È come un fondamento di base per tutti i tuoi oggetti. E dovrebbero essere tutti memorizzati nelle loro proprie liste - ogni lista conterrà solo oggetti di un tipo - pesci, animali, umani, divinità, ecc.
Cioè, dovrete avere una lista per ogni sottotipo. E ci deve essere una lista, che conterrà le seguenti liste nella gerarchia. Ognuno di questi elenchi deve anche avere elenchi - di nuovo - che sono successivi nella gerarchia. E così via.
Cioè, avete bisogno anche di un oggetto lista di base, in cui metterete le liste richieste. E questa lista base deve avere un metodo Type(), e ci deve essere un metodo che permette di restituire qualsiasi oggetto memorizzato in essa per il suo indice. Poi, se questo viene fatto, avrete automaticamente un metodo in una qualsiasi delle liste che restituisce l'oggetto richiesto.
In generale, dovete pensare prima al vostro oggetto fondazione e poi al vostro oggetto lista. Non c'è nemmeno bisogno di creare liste di oggetti, esistono già.
E poi è una questione di tecnica. Ed è sufficiente conoscere il tipo di oggetto che si sta cercando. Ci saranno molti tipi nella sua gerarchia, e ognuno di essi è conosciuto da voi e potete richiederlo e riceverlo.
Come mi è sembrato, non ha niente a che fare con OOP in questo caso.
Nel caso di Peter, tutti gli oggetti nell'array sono cercati da qualche chiave. E non c'è differenza se si usano classi, se si usano array, se si usa un mucchio di oggetti dichiarati in assoluto.
OOP permette di avere una lista di oggetti, ognuno dei quali, diciamo, ha il metodo GetColor() - e l'utente passa attraverso tutti gli oggetti alla ricerca del colore giusto. Ma, se senza OOP - abbiamo un array di strutture identiche, che l'utente deve conoscere, per ottenere il colore da dove è necessario, con l'OOP - l'utente non ha bisogno di sapere esattamente come e dove il colore è memorizzato - il metodo GetColor() dell'oggetto sa, dove ottenere il colore.
Così, per OOP - l'utente non ha bisogno di sapere come e dove il colore dell'oggetto è memorizzato. Così, se abbiamo improvvisamente bisogno di aggiungere un "oggetto per non vedenti", in cui il colore è codificato da punti Braille, possiamo facilmente aggiungere questo oggetto alla nostra lista e cambiare solo il suo metodo GetColor(), che riceverebbe il codice colore dai punti in Braille e lo restituirebbe in forma regolare. Per l'utente della nostra lista, non cambierà nulla.
Se abbiamo solo un array - non possiamo metterci "punti braille". Non abbiamo un campo del genere.
Il beneficio di OOP è davvero ben visto quando ereditiamo da CObject, poi creiamo un array di oggetti CArrayObj, e poi, scrivendo solo la funzione di confronto - otteniamo immediatamente la capacità di ordinare rapidamente e cercare binari.
Grosso modo, per il mio esempio sopra, con il colore - per OOP - scriviamo una funzione di confronto, ottenendo il colore attraverso GetColor(), e possiamo ordinare i nostri oggetti per colore, anche senza sapere che abbiamo metà degli oggetti con colore reale e metà con "punti braille".E se vogliamo aggiungere un oggetto con una nuova codifica di colore - ancora una volta abbiamo solo bisogno di scrivere la funzione GetColor(), che porterebbe la sua rappresentazione dei colori allo standard - e poi glialgoritmi di ordinamento e ricerca già scritti accetteranno questo nuovo oggetto senza problemi.
Cioè, in effetti, OOP ci ha permesso di avere un algoritmo di ordinamento e di recupero per oggetti non ancora scritti, prima ancora di aver deciso esattamente come saranno rappresentati e come saranno memorizzati.
I benefici di OOP sono davvero chiari, quando ereditiamo da CObject, poi creiamo un array di oggetti CArrayObj, e poi, scrivendo solo la funzione di confronto, otteniamo un ordinamento veloce e una ricerca binaria.
È un mare di sintassi e difficoltà con le transizioni tra i collegamenti a causa dei diritti di accesso alle classi e ai loro contenuti. È qui che inizia il sovraccarico, come conseguenza della divisione in classi. OOP da un lato permette di costruire una gerarchia, dall'altro la rende estremamente difficile da lavorare.
i modificatori dei diritti di accesso permettono di rilevare gli errori in fase di compilazione
In generale, tutto questo non complica il lavoro con le classi, non usarlo, scrivi tutto in pubblico: e allora sarà più facile lavorare con loro.
SZZY: Un sacco di belle frasi su OOP, incapsulamento ed ereditarietà... Questo è tutto buono, ma il vantaggio più importante di OOP rispetto ad altri stili di programmazione è la memorizzazione di tutti i dati (campi di classe) e le funzioni di lavoro con questi dati (metodi di classe) in un posto (classe) - in libro è incapsulamento. Inoltre l'uso di OOP dipende dal compito, se il compito permette di scalare le classi, allora la gerarchia sarà necessaria e ci saranno classi base e i loro discendenti - se usarla, dipende da voi
Devo ammettere che nel concetto di OOP, "Object" è presentato in un contesto più ampio che nel mio "Kernel". Ma questo non è sorprendente, dato che finora mi sono occupato solo di grafica, e l'OOP è usato per una vasta gamma di compiti. Il mio "menu" di oggetti è piuttosto scarno e a parte "etichetta", "elemento", "finestra" non c'è probabilmente molto altro... Tuttavia, per le interfacce grafiche non c'è altro di cui ho bisogno.
Tuttavia, la questione di estendere il concetto di "Oggetto" e di costruire una gerarchia è sorta ora. Un semplice kernel bidimensionale non può accettare l'intera varietà di oggetti della base di conoscenza e quindi o si crea un kernel diverso per i diversi oggetti o si segue il concetto di OOP.
In sostanza, si tratta di una questione puramente tecnica. Quale è più efficiente, quale è più veloce, quale è più leggibile, ecc.
In effetti, potete semplicemente mantenere tutti gli oggetti in un array come una lista di proprietà, tra le quali ci saranno puntatori ad altri array, con altri oggetti e così via. Oppurepotete usare esplicitamenteOOP. L'orientamento agli oggetti è invariabilmente presente in entrambi gli approcci, solo i metodi di implementazione sono diversi. La stessa memoria, gli stessi puntatori, gli stessi oggetti, la stessa classificazione. Solo la forma del codice è diversa...
Volevo parlarne a Peter quando capirà il concetto di archiviazione dei dati che gli è stato proposto.
Cercherò di capire questo concetto di memorizzazione e gestione dei dati.
Ok. Possiamo chiacchierare di persona sull'argomento. O su Skype, come preferite. È solo che le specifiche non sono sul tema di questo thread - qui, come ho capito, sono solo domande generali.