Parlare dell'OLP nel salone - pagina 11
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
La quantità di gesti in OOP non può essere inferiore in linea di principio, perché tutte queste interfacce sono un overhead aggiuntivo, che spesso supera il costo della scrittura della logica stessa. E questo nonostante il fatto che qualsiasi funzione ha già un'interfaccia, cioè si propone di costruire un altro giardino, che è essenzialmente senza senso.
Allo stesso tempo, qualsiasi cambiamento nel codice, sia nell'interfaccia che nella funzione, diventa molto più complicato, poiché uno è agganciato all'altro, il che significa che abbiamo un aumento almeno quadratico del possibile numero di bug e dell'intensità del lavoro... È abbastanza ovvio, no?
La quantità di gesti in OOP non può essere inferiore in linea di principio, perché tutte queste interfacce sono un overhead aggiuntivo, che spesso supera il costo della scrittura della logica stessa. E questo nonostante il fatto che qualsiasi funzione abbia già un'interfaccia, cioè dobbiamo fare un'altra copertura che è essenzialmente inutile.
In questo caso qualsiasi cambiamento di codice sia nell'interfaccia che nella funzione diventa molto più complicato, poiché uno è agganciato all'altro, cioè abbiamo un aumento almeno quadratico dei possibili bug e dell'intensità del lavoro... È abbastanza ovvio, no?
Forum sul trading, sistemi di trading automatico e test di strategie di trading
Parlare di OOP nel cortile di casa
fxsaber, 2018.01.14 11:35
La programmazione stessa è un caso speciale di produzione. L'approccio OOP è un approccio di principio per produrre qualsiasi cosa. Quindi parlare di programmazione è molto limitato. OOP è stato applicato con successo PRIMA della sua comparsa nella programmazione.
La storia dell'industria è arrivata alla PRODUZIONE orientata agli oggetti come la fase successiva di convogliamento. Quindi parlare di programmazione OO è una visione ristretta. Come parlare di stivali da cucire OO. Stiamo parlando di approcci algoritmici all'organizzazione di qualsiasi produzione, compresa, come caso molto speciale, la creazione di software.
La produzione OOP si è dimostrata competitivamente superiore alle linee di assemblaggio convenzionali. C'è una pianificazione a breve termine della produzione, quando è necessario farla funzionare subito. E c'è il lungo termine - quando si posa un sacco di "extra" al momento, ma questa fondazione facilita la scalabilità della produzione. Di nuovo, non si tratta di programmazione, ma di approcci generali nella creazione della produzione.
Gli approcci OOP possono essere visti anche nelle moderne istituzioni di potere.
Il terminale è una classe in relazione al vostro codice. Quanto spesso avete bisogno di cambiare qualcosa nel codice del terminale?
Questo esempio non è corretto. Stiamo parlando di interfacce all'interno del vostro programma...
La storia dell'industria è arrivata alla PRODUZIONE orientata agli oggetti come il passo successivo della convogliazione.
La programmazione OO ha anche le sue pipeline di elaborazione e OOP introduce un altro livello di astrazione che aumenta solo l'overhead di ogni singolo trasportatore e dell'intera produzione.
Anche la programmazione OO ha i suoi trasportatori di elaborazione, e OOP introduce un altro livello di astrazione che aumenta solo l'overhead di ogni singolo trasportatore e dell'intera produzione.
Lei è stupido, purtroppo. Vi viene raccontata la storia dell'industria e di OOP come una delle tappe di quella storia, che ha giocato un ruolo enorme in tutte le cose materiali (e non solo) che vi circondano. E tu continui a parlare di un caso speciale di programmazione.
Ignoranza della storia dello sviluppo umano. Non lascerete una traccia nella memoria dei vostri discendenti diretti.
Vi viene raccontata la storia dell'industria e dell'OOP come una tappa di quella storia, che ha giocato un ruolo enorme in tutte le cose materiali (e non solo) che vi circondano.
Il tuo ingenuo tentativo di trascinare l'OLP nella storia dell'industria è divertente, ma tristemente analfabeta.
Questo esempio non è corretto. Stiamo parlando di interfacce all'interno del tuo programma...
Perché è "scorretto"?
In che modo un programma è diverso da TUTTO il software che gira su un computer?
Dopo tutto, si tratta della stessa serie di istruzioni e set di dati come in qualsiasi programma utente. Perché non è corretto - qui o là, una parte del software non ha accesso a un'altra parte del software se non attraverso protocolli di scambio stabiliti?
Va bene, se programmate seriamente - prima o poi arriverete alla necessità di differenziare i diritti di accesso.
Anch'io, ai tempi del passaggio dalla modalità reale a quella sicura, odiavo il fatto di non poter accedere a nessun indirizzo di memoria fisica. Ho anche fatto dei colpi di scena con un controller DMA che copiava i dati dall'area protetta del sistema alla mia (anche se era piuttosto difficile capire cosa veniva copiato lì, quindi non l'ho fatto). In gioventù ero indignato - come potevo non avere accesso diretto - era quasi una violazione dei miei diritti... E nel programma per permettermi di non avere accesso a qualcosa che non è stato ancora completato.
Beh, man mano che raccolgo esperienza, ho spesso trovato che la differenziazione dei diritti d'accesso è una manna per il programmatore stesso, perché spesso mi ha salvato dal fare errori nei moduli scritti. Prendete una classe, volete usarla, e non ha accesso ad alcuni dati... Siete indignati, come potrebbe essere, cominciate a indagare... e oops... Ci sono cose che devono essere prese in considerazione e non si può accedere ai dati direttamente, ci sono "modi indiretti", l'architettura del sistema è tale che posso ottenere dati non validi accedendovi direttamente. Ma posso anche ottenere dati validi - tutto dipende dal momento. E un tale errore è molto difficile da rilevare.
Qui, il problema più semplice è l'accesso ai dati in una cache. Se avete bisogno di dati nella cache e vi accedete direttamente, siete sicuri di ottenere i dati giusti? Nell'approccio procedurale senza differenziazione - bisogna capire quando si può usare, quando non si può, quando i dati sono validi, quando non lo sono... Nell'approccio OOP - tutto è molto semplice, non si ha accesso ai dati della cache, si può solo chiamare la funzione, che restituisce i dati richiesti, e se non è valida, recupera i dati validi. È "più complicato"? Ora immaginate di usare questa cache un anno dopo averla scritta. Quando avete completamente dimenticato i principi del refresh della cache e della definizione della validità. Nell'approccio OOP non ti interessa. La funzione di classe vi fornirà tutto. Ma nell'approccio funzionale - devi ricordare nei dettagli, quando e come la cache viene aggiornata, quando i dati in essa sono validi e quando no.
Questo esempio non è corretto. Stiamo parlando di interfacce all'interno del vostro programma...
Il terminale è una classe in relazione al vostro codice. Quante volte avete bisogno di cambiare qualcosa nel codice del terminale che è nascosto da voi e fornito solo con metodi pubblici - funzioni per implementare i vostri programmi.
+++ )))
Il terminale è una classe in relazione al vostro codice. Quante volte avete bisogno di cambiare qualcosa nel codice del terminaleche è nascosto da voi, e solo i metodi pubblici - funzioni per implementare i vostri programmi sono forniti.
Una tale necessità si presenta regolarmente. È solo auspicabile che gli sviluppatori lo facciano.
Un semplice esempio. Per qualche ragione, gli sviluppatori non hanno ritenuto necessario fornire una griglia di coordinate orizzontali per i grafici degli indicatori. E, naturalmente, non hanno fornito un metodo appropriato per questo).