Una domanda per gli esperti di OOP. - pagina 10
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
E lo sono anch'io - a poco a poco... e la piena comprensione arriva solo dopo 4-5 anni (e questo è normale per una persona normale)
Secondo me, la "piena comprensione" non è necessaria. La cosa principale è "afferrare l'essenza". Io, quando ho conosciuto la meodologia OOP, era il 1995.
Avevo già un po' di esperienza con il "C regolare" nello spirito di K&R (gli oldfags devono ricordare), inoltre usavo abbastanza spesso le funzioni assembler. All'inizio ero piuttosto scettico sulle idee OOP, non tanto perché il programmatore doveva eseguire alcune azioni extra, ma per il puro "overhead" della CPU. Ma mi sono presto convinto dell'utilità di questa tecnologia e laclasse CString è stata il principale "interruttore" nella mia mente.
Non solo, ma lavorare con le stringhe era molto più semplice: all'epoca stavamo scrivendo un impacchettatore di dati e la mia parte era l'analizzatore di testo in ingresso. Di conseguenza, sembrava essere molto conveniente creare una gerarchia di varie stringhe sulla base della classe CString, che aveva importanti differenze per il nostro imballatore.
Mi è piaciuto soprattutto il fatto che dopo aver scritto il data packer, si è presentato il compito di usarlo per le stringhe, che avevano molte informazioni digitali, per le quali il packer non era stato originariamente progettato. Ha certamente impacchettato tali dati, tuttavia, l'ha fatto considerando l'alfabeto di input solo come caratteri, ma sapendo che la stringa consiste di alcune parole e cifre - ha migliorato significativamente il packer senza perdita di velocità. Quindi, è stata scritta una classe che rappresenta tali stringhe con cifre (e anche un compressore specifico per le cifre), tutto è stato aggiunto alle classi esistenti e il packer ha iniziato a lavorare con nuovi dati, anche se questa funzionalità non era prevista inizialmente.
È stato allora che ho davvero apprezzato il potenziale dell'OOP per modificare e mantenere il codice. Naturalmente, c'è un po' di overhead della CPU, ma è più che compensato dal lavoro ridotto dei programmatori.
Ecco perché raccomando a tutti coloro che iniziano a imparare l'OOP di iniziare con questi compiti, dove il vantaggio dell'OOP sarebbe ben e chiaramente visibile. Cioè, con i compiti di elaborare diversi oggetti in liste, che rappresenterebbero istanze di classi con un antenato comune.Guarda, ho questo canale nelle mie sottoscrizioni, in generale ho un'opinione positiva dell'autore, e c'è anche una ripetizione dell'argomento del tuo video per il quale è iniziata la discussione:
Sono quasi completamente d'accordo con tutti i pensieri nel video. Ci sono un paio di obiezioni minori, non anche obiezioni ma chiarimenti (per esempio, considero NULL un puntatore molto utile che indica un errore, dobbiamo solo tenere presente che la funzione può restituire questo puntatore nullo, e, chiaramente, il video dice correttamente - non può essere gestito come un oggetto).
E tutto il resto su imprecisioni, ordine di sviluppo, getter-setter e lo stesso NULLA è corretto.
Complimenti all'autore.
È strano che essendo una persona filosofica e ben astratta, sono così disperato nel rifiutare l'approccio alla programmazione amato dai professionisti. Sebbene sia stata progettata per essere pratica, la OOP è diventata sovraccarica di entità e ridondante rispetto ai suoi compiti. La "ridondanza" degli strumenti ostacola la soluzione, così come la scarsità. E questa ridondanza è senza dubbio una conseguenza del marketing. A pensarci bene, una OOP minima è sufficiente per risolvere tutto nel campo dei problemi informatici. Così come tutto può essere creato con semplici funzioni e una corretta gestione della memoria. A livello iniziale, ho adottato subito l'OOP. Poi ho notato che alcune entità non potevano giustificare la necessità della loro esistenza e vivevano la loro vita, astratta dai compiti, all'interno del concetto di crescita. Sì, sono incorporati nelle soluzioni, ma sono parassiti dell'intelligenza degli sviluppatori. Rallentano il processo di lavoro, riducendone l'efficienza. Ostacolano il flusso di lavoro con l'offuscamento, la sintassi, le regole... È questo che non mi piace di questa opzionalità all'interno della soluzione.
Quindi, userò l'OOP più minimale. Quello che è stato creato prima di commercializzarlo.
È strano che essendo una persona filosofica e ben astratta, sono così disperato nel rifiutare l'approccio alla programmazione amato dai professionisti. Sebbene sia stata progettata per essere pratica, la OOP è diventata sovraccarica di entità e ridondante rispetto ai suoi compiti. La "ridondanza" degli strumenti ostacola la soluzione, così come la scarsità. E questa ridondanza è senza dubbio una conseguenza del marketing. A pensarci bene, una OOP minima è sufficiente per risolvere tutto nel campo dei problemi informatici. Così come tutto può essere creato con semplici funzioni e una corretta gestione della memoria. A livello iniziale, ho adottato subito l'OOP. Poi ho notato che alcune entità non potevano giustificare la necessità della loro esistenza e vivevano la loro vita, astratta dai compiti, all'interno del concetto di crescita. Sì, sono incorporati nelle soluzioni, ma sono parassiti dell'intelligenza degli sviluppatori. Rallentano il processo di lavoro, riducendone l'efficienza. Ostacolano il flusso di lavoro con l'offuscamento, la sintassi, le regole... È questo che non mi piace di questa opzionalità all'interno della soluzione.
Quindi, userò l'OOP più minimale. Quello che è stato creato prima di commercializzarlo.
Sì. Si crea una classe, per esempio, per lavorare con un file. Cominci ad usarlo e ti vengono i bug. Si chiude una parte del codice e si cerca di fare qualcosa nell'altra parte. Ci sono due approcci. Il primo è quello di cercare di ricordare sempre dove è fatto qualcosa e anche con un solo sviluppatore questo può non essere molto buono. Il secondo - prima dell'azione di controllo delle operazioni da fare. Ok, il prossimo bug: nelle operazioni di verifica, che sono sparse in tutto il codice, qua e là ci sono errori di battitura, segno sbagliato, corretto in un posto, dimenticato in un altro, ecc. Come risultato, siete passati da una così amata efficienza del codice a una cosa banale e semplice: ogni metodo Read/Write e così via ha una chiamata a un metodo di controllo con un'opzione per annullare questa chiamata, che non userete quasi mai. E poi ci si rende conto che questa è una buona cosa, perché l'hardware moderno permette di non contare i cicli di clock e il consumo di memoria nel 98% dei compiti risolti.
Sì. Si crea una classe, per esempio, per lavorare con un file. Cominci ad usarlo e ti vengono i bug. Si chiude una parte del codice e si cerca di fare qualcosa nell'altra parte. Ci sono due approcci. Il primo è quello di cercare di ricordare sempre dove è fatto qualcosa e anche con un solo sviluppatore si può non riuscirci.
Peter è bravo.
Questo è il problema - Peter si trova a suo agio usando un'enorme tabella di tutte le variabili, che è sempre disponibile da tutto il programma, e dalla quale prende quello che gli serve in qualsiasi momento. Per il titano della memorizzazione, questo è abbastanza utile.
In OOP l'incapsulamento è una caratteristica archivistica, che serve solo a garantire che l'utente in qualsiasi punto del codice abbia accesso solo alle variabili di cui ha bisogno e nessun'altra variabile. Ma per Peter è un minus, lui ricorda già dove, cosa e come ha usato. Vuole essere in grado di accedere a qualsiasi variabile in qualsiasi parte del programma in qualsiasi momento. Non gli piace il mio approccio, quando per accedere a una variabile si deve prima ottenere un puntatore all'interfaccia, e dall'interfaccia si deve ottenere la funzione, e solo allora questa restituisce il valore di cui si ha bisogno. E in uno qualsiasi di questi passi, si può incontrare una restrizione di accesso. Penso che questa sia una buona cosa, perché se c'è una restrizione - è messa per una ragione, significa che non ho considerato alcuni dettagli importanti. E per Peter è un ostacolo, perché tiene sempre conto di tutto.
Sì, avete creato una classe per gestire, diciamo, un file. Cominci ad usarlo e ottieni degli errori. Si chiude una parte del codice e si cerca di fare qualcosa nell'altra parte. Ci sono due approcci. Il primo è quello di cercare di ricordare sempre dove è fatto qualcosa e anche con un solo sviluppatore questo può non essere molto buono. Il secondo - prima dell'azione di controllo delle operazioni da fare. Ok, il prossimo bug: nelle operazioni di verifica, che sono sparse in tutto il codice, qua e là ci sono errori di battitura, segno sbagliato, corretto in un posto, dimenticato in un altro, ecc. Come risultato, siete passati da una così amata efficienza del codice a una cosa banale e semplice: ogni metodo Read/Write e così via ha una chiamata a un metodo di controllo con un'opzione per annullare questa chiamata, che non userete quasi mai. E poi ci si rende conto che questa è una buona cosa, perché l'hardware moderno permette di non contare i cicli di clock e il consumo di memoria nel 98% dei compiti risolti.
Immaginiamo la situazione inversa. Beh, tu non hai insetti. Per niente e quasi mai, perché si ricorda TUTTO e si tiene conto di TUTTO!Userebbe OOP solo per il suo "dovere professionale"? Non credo. Di cosa si preoccuperebbe allora? - Solo l'efficienza dei vostri codici. Si cercherà di rimuovere tutto l'overhead, in modo che il codice funzioni il più velocemente possibile. Cercherete anche di creare il vostro codice in modo tale che si sviluppi rapidamente.
Quando la gente mi parla di bug che si verificano qua e là li capisco, ma quando sono associati all'uso o al non uso di OOP non sono d'accordo. Il numero di bug dipende dalla conoscenza e dalla comprensione del proprio codice. Uno che scrive il codice lo conosce meglio di una persona che lo inserisce. Uno che lo scrive ha sempre meno bug. Come capite, OOP promuove la portabilità del codice, il cui rovescio è la scarsa comprensione da parte di altri programmatori. Questa è la fonte dei bug.
Scrivo tutto da solo, e trovo bug in blocchi di 2000 linee senza funzioni di profiler e checker. Semplicemente, conosco il mio codice. La migliore cura per gli insetti))
Funziona per Peter.
Questo è il problema - Peter si trova a suo agio usando un'enorme tabella di tutte le variabili, che è sempre disponibile da tutto il programma, e dalla quale prende quello che gli serve in qualsiasi momento. Per il titano della memorizzazione, è abbastanza utile.
L'incapsulamento in OOP è una caratteristica archivistica, che serve precisamente per assicurare che l'utente abbia accesso solo a quelle variabili di cui ha bisogno in qualsiasi punto del codice, e non di più. Ma per Peter è un minus, lui ricorda già dove, cosa e come ha usato. Vuole essere in grado di accedere a qualsiasi variabile in qualsiasi parte del programma in qualsiasi momento. Non gli piace il mio approccio, quando per accedere a una variabile si deve prima ottenere un puntatore all'interfaccia, e dall'interfaccia si deve ottenere la funzione, e solo allora questa restituisce il valore di cui si ha bisogno. E in uno qualsiasi di questi passi, si può incontrare una restrizione di accesso. Penso che questa sia una buona cosa, perché se c'è una restrizione - è messa per una ragione, significa che non ho considerato alcuni dettagli importanti. E per Peter è un ostacolo, perché tiene sempre conto di tutto.
George, non si tratta solo di memoria. Ho creato un ambiente di sviluppo conveniente per me, usando la mia lingua madre e anche l'inglese. Il codice bilingue è MOLTO meglio da ricordare di quello monolingue. Soprattutto quando non sei bloccato su parole standard e chiami le variabili con qualsiasi nome tu voglia. Provata. Ho semplicemente ignorato la professionalità nella programmazione e ho iniziato a scrivere a mio piacimento. Di conseguenza, ho iniziato a navigare rapidamente nel mio codice e a leggerlo, ricordarlo e svilupparlo facilmente. Più avanti si sa...
ZS. Non lasciare che pensino che ti sto esortando a fregartene della professionalità. Assolutamente no. Ci ho sputato sopra a causa del mio ego troppo gonfiato. Si scopre che può essere non solo cattivo, ma anche buono. :)
Peter, il tuo pensiero suggerisce che non hai mai lavorato in una squadra. Non avete visto come ognuno fa il proprio pezzo di un compito enorme, e come tutto si riunisce alla fine.
Per esempio, senza OOP, era impossibile creare e sviluppare Windows.
Se non fosse necessario, anch'io cercherei di non applicare classi. Ma quando ho deciso di trasformare il mio robot in un robot multivaluta, ho subito applicato le classi, perché era già chiaro cosa sarebbe successo senza OOP.
Applicando le classi, è ovvio che le coppie di oggetti utilizzati sono della stessa classe e lavorare con loro simultaneamente è già molto facile.
Peter, il tuo pensiero suggerisce che non hai mai lavorato in una squadra. Non avete visto come ognuno fa il proprio pezzo di un compito enorme e come tutto si riunisce alla fine.
Per esempio, senza OOP, era impossibile creare e sviluppare Windows.
Se non fosse necessario, anch'io cercherei di non applicare classi. Ma quando ho deciso di trasformare il mio robot in un robot multivaluta, ho subito applicato le classi, perché era già chiaro cosa sarebbe successo senza OOP.
Applicando le classi, è ovvio che le coppie di oggetti utilizzati sono della stessa classe e lavorare con loro simultaneamente è già molto facile.
Sì, non facevo parte della squadra. Il mio approccio dovrebbe essere considerato come un esperimento di uno sviluppatore. Non sto convincendo a seguirlo. C'è troppa impertinenza nel mio approccio).
Se un programmatore entra nel mondo del forex, non è necessario essere un professionista e conoscere OOP.
È meglio imparare le complessità del mercato e sviluppare una strategia di trading redditizia. E non importa se si usa OOP o no. La redditività dell'Expert Advisor non ne soffrirà.
Non devi sprecare la tua energia.