Una domanda per gli esperti di OOP. - pagina 25
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
il concetto stesso di OOP implica semplicemente non scrivere - non si deve conoscere l'implementazione del metodo (nel tuo esempio return(SymbolSelect(m_name,select))
Immaginate che invece di questa linea:
devi fare un sacco di ricerche, controlli vari, ecc. - Questo ti porterà via del tempo per scrivere la tua libreria e studiare il materiale
Supponiamo che il vostro compito sia solo quello di usare un solo metodo di una soluzione pronta sotto forma di una classe - create un'istanza della classe (oggetto) e usate il metodo pronto Select(const bool select)
Se non avete intenzione di eseguire tali operazioni, liberate la memoria = cancellate l'oggetto
Supponiamo che il vostro compito sia quello di visualizzare un pulsante, premendolo, attivate/disattivate il simbolo nell'orologio del mercato ---> create la vostra classe e incapsulate la classe button già pronta e la classe CSymbolInfo già pronta - il compito è fatto
Il paradigma OOP dà solo informazioni generali su cosa si può fare con una classe - non volete incapsulare CSymbolInfo - bene, ereditate la vostra classe da esso
Credo, non capisco e non lo accetto. Quando hai un compito specifico che non può fare a meno di tutti questi caveat, allora l'"illuminazione mentale" e la comprensione arriveranno. Ma per ora, dal mio punto di vista, solo i gadget di fantasianon sonosempre giustificati. Non sempre non significa mai. Sono felice di usare la classe Ctrade, ma non la accetto come ho detto sopra. Se la descrizione della funzione SymbolSelect nella documentazione non è difficile da trovare, in SB è già difficile trovare la descrizione.
HH: "sulle dita", l'essenza di OOP è una soluzione rapida a un dato problema senza la conoscenza dell'implementazione.
In questo caso, invece di conoscere l'implementazione, bisogna sapere come chiamare il metodo desiderato, dove trovarlo e così via. È un tipo di linguaggio in un linguaggio di programmazione?
Posso capire se un progetto ha bisogno di avere diverse istanze di un oggetto. Ma finora non ho visto nessuna implementazione del genere, tranne la dimostrazione di Artem menzionata sopra. In questo caso è chiaro che è meglio, più facile, più semplice, ma non sono arrivato a una piena comprensione proprio a causa dell'inutilità, della mancanza di compito. Non ha senso cambiare l'oggetto per il bene di un singolo uso delle funzioni mql5. Questo è il mio ragionamento.
In questo caso, invece di conoscere l'implementazione, bisogna sapere come chiamare il metodo giusto, dove trovarlo e così via. È un tipo di linguaggio in un linguaggio di programmazione?
guardare nella documentazione, tutto ciò che viene pubblicato pubblicamente è accompagnato da manuali, per così dire, etici
non è uno stile, è un paradigma! - un concetto, regole di galateo, nessuno è costretto a scrivere così, ma per qualche motivo è lo stile più comune
l'essenza dell'OOP è di risolvere rapidamente un dato compito senza conoscere l'implementazione
Si può chiamare una funzione, passando una struttura con dati in essa, e ottenere una soluzione altrettanto veloce senza conoscere l'implementazione della funzione.
Sì, ma il tuo metodo sarà limitato su questo, in OOP puoi anche ereditare - anche senza conoscere l'implementazione e aggiungere al tuo compito, la prima cosa che mi viene in mente - Button con bordi arrotondati, ci sono tonnellate di esempi sul web
SZZ: e la logica dello svolgimento di un oggetto attraverso i costruttori è piuttosto comoda.
Una classe è una descrizione di un oggetto. Bene. Contiene le proprietà e le funzionalità dell'oggetto. Ok. Tutto questo è ordinato, aperto o protetto.
Allora l'OGGETTO stesso è fuori gioco. È nel contesto della classe. Nel contesto del suo nome e della sua descrizione. Cioè, in OOP, l'Oggetto, è esattamente un insieme di attributi (non solo proprietà, ma anche elementi funzionali - metodi), ma più ordinato e incapsulato di quello che ho. (Ha più senso per me).
Bisogna leggere dei libri per dare un senso a tutto questo. Almeno VC++ in 21 giorni.
Vi consiglio di usare MFC per la prima volta, creare un'applicazione windows basata su CDialog, creando tutti i tipi di oggetti e vedere come sono gestiti facilmente.
Dopo di che butterete via la vostra impresa. Purtroppo.
Beh, questo è improbabile. Il punto è che ho trovato pochissime differenze concettuali tra il mio approccio e OOP. Anche il mio approccio è orientato agli oggetti. Gli oggetti sono incapsulati nel kernel e hanno una rappresentazione molto specifica. Sono collegati da puntatori, formando complessi - elementi, finestre... Se si va oltre la grafica e si crea una forma diversa di kernel che include più diversità, sarà buono come in OOP.
La differenza negli approcci è nello stile di scrittura del codice, nella sintassi e nei metodi di distribuzione delle funzionalità. Nel mio approccio la funzionalità tende ad essere fusa, in OOP tende ad essere divisa. La fusione di funzionalità è garantita per aumentare l'efficienza del sistema e la piccola quantità di sintassi, mentre la divisione delle funzionalità facilita la portabilità del codice. Permette l'inserimento di moduli. In generale, queste sono le differenze.
Naturalmente, il mio approccio non ha ancora questa ampia "obiettività". Ma ho già dei pensieri su come risolvere questo problema. Un kernel è di un solo tipo e questo limita le proprietà memorizzate in esso, ma un kernel non deve essere necessariamente una matrice singola. Può essere un complesso di nuclei. Il vantaggio principale è la rappresentazione digitale degli oggetti, che non richiede una lunga descrizione, una sintassi aggiuntiva e la frammentazione delle funzionalità.
Ma OOP è molto interessante per me. Imparerò da questo).Peter, infine google classes, cosa sono nel contesto dell'allocazione della memoria, chiamate di metodo, cioè in cosa il compilatore converte il tutto. La maggior parte delle domande evaporeranno da sole dopo questo.
Si è pensato molto al concetto di OOP, e il fatto è questo:
Astraiamo dalla sintassi e dai termini tecnici, lasciando i concetti di "classe", "oggetto", "proprietà", "incapsulamento", "polimorfismo", "ereditarietà". Descriverò la "radice" filosofica del concetto.
La realtà è percepita dalla coscienza attraverso i prismi di "Spazio", "Tempo" e "Materia" (così funzionano gli organi di senso), e "Oggetto" è un risultato discreto della loro continua interazione.
La molteplicità delle forme di interazione genera una varietà di oggetti che sono "piantati" dall'inconscio del soggetto su una certa "cornice". Questa cornice ha una struttura ramificata e a cascata ed è "costruita" nell'inconscio, essendo uno dei suoi "archetipi". Il framework assume nuovi e nuovi oggetti (informazioni su di essi) che sono distribuiti nella sua struttura. È da qui che viene il concetto di OOP.Si tratta di una distribuzione e legatura cosciente di oggetti che imita l'"algoritmo" dell'inconscio. Avendo padronanza dei metodi del proprio pensiero il soggetto è in grado di simulare il suo lavoro nel meccanismo di "tracciamento" del cervello - il computer. Anche se un computer è solo una patetica parodia di un cervello, ma l'uomo stesso percepisce solo ombre del mondo oggettivo. La cascata, archetipo ramificato, è un "modello" di distribuzione di oggetti, proprietà, processi e tutte le informazioni all'interno della nostra memoria in generale. È uno strumento biologico per semplificare la percezione della realtà, strutturando un modello del mondo che ci circonda. Ci è dato dalla Natura. La consapevolezza del nostro meccanismo "naturale" (cioè inconscio) di elaborazione delle informazioni è un livello di autoconsapevolezza necessario perusare l'OOP.
Considerate questo archetipo implicito, biologico, "ad albero" che facilita la memorizzazione, l'apprendimento e la percezione, nel contesto della sua applicazione "artificiale".In OOP, "produciamo" oggetti incapsulando le loro descrizioni in classi, dove stabiliamo le loro proprietà e valori. Le relazioni degli oggetti si riflettono nella loro classificazione, e sono implementate attraverso l'ereditarietà di proprietà e metodi da globali a privati. In pratica, è così: ogni oggetto privato è solo un oggetto e quindi ha tutte le proprietà di un semplice oggetto + le sue proprietà private. Gli oggetti derivati avranno le sue proprietà private come le loro proprietà comuni, ma avranno le loro proprietà private. Inoltre, la catena può ramificarsi indefinitamente. È lo stesso con i metodi degli oggetti. Un metodo riflette un'azione, un'interazione, un processo, un cambiamento di stati. I metodi degli oggetti sono distribuiti da generali a privati come le proprietà. Se c'è un processo generale, ogni forma discreta avrà le sue proprietà. E questo è il polimorfismo. Cioè, a differenza dell'overloading, il polimorfismo fornisce una diversa implementazione privata di una funzione sottostante pur mantenendo il suo meccanismo sottostante. Questa è l'eredità "funzionale".
Come possiamo vedere, "ad albero" in OOP è ovunque; qualunque schema vi venga in mente, otterrete comunque un "albero"). Ma questo è corretto in quanto stiamo solo copiando i nostri schemi inconsci di lavoro con le informazioni.
Ho pensato molto al concetto di OOP e questo è quanto:
...Duro.
Peter, devi entrare in politica. Tali talenti non sono richiesti qui: dire molto, in modo intelligente e incomprensibile, e su niente.
...
Con una migliore comprensione di come funzionano le nostre menti consce e inconsce, saremo in grado di replicare il loro meccanismo nel computer. Ho semplicemente fatto un passo indietro rispetto ai dettagli tecnici e ho guardato alla radice del concetto.