Una domanda per gli esperti di OOP. - pagina 15
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
fa sul serio!
Sto per brevettare il mio concetto. Ci sono investitori. Quindi è una cosa seria.
ieri sera ho letto il thread sul sonnambulismo.... per qualche ragione ho immaginato una lunga lista di sviluppatori di Windows - come nei crediti di Star Wars!
e alla fine della lista - a grandi lettere ReTeg Konow!
@Peter Konow puoi fare uno sprite di testo come questo)?Ricorda tutto nel progetto a cui sta lavorando in quel momento. E i codici passati? Ricorda altrettanto bene quello che ha scritto un anno fa? Dove le cose sono cambiate, ecc. Ora il compito è quello di ritoccare o correggere il vostro vecchio codice.
Tutto si basa sulla memoria fenomenale di Peter.
E sono d'accordo, se si ricordano tutte le variabili che vengono utilizzate in tutto il progetto, quando e dove vengono modificate, trovare facilmente i luoghi di modifica errata - allora questa stessa OOP diventa davvero senza senso. Peter, infatti, lavora a "livello di assemblatore". Qualunque OOP-hack e design pattern vi venga in mente, alla fine tutti gli accessi ai dati sono indirizzi di memoria ordinari, e all'interno dello spazio di indirizzi assegnato al processo, tutti gli indirizzi di memoria sono completamente accessibili. Il processore stesso non sa nulla dell'incapsulamento.
Ecco, ed è così che Peter opera. C'è stato un tempo in cui anch'io ero appassionato di assemblaggio.
L'unica domanda è come riesce a competere con il processore in termini di capacità di memoria.
È tutto merito della memoria fenomenale di Peter
...
L'unica domanda è come riesce a competere con il processore in termini di capacità di memoria.
Quindi cos'è il fenomeno se stiamo parlando dello stesso progetto a cui sta lavorando tutto il tempo. Naturalmente, qualsiasi programmatore avrà sempre tutto nella sua testa.
Beh, allora non sono uno qualunque. Anch'io lavoro per lo più allo stesso progetto, ma ricordo solo il succo di base. Tali dettagli come cosa e da quale procedura è modificato - vedo solo al momento dello sviluppo diretto. E poi, se torno su questo sito, passo molto tempo a cercare di capire perché è così e non altrimenti. Di conseguenza, sono un sostenitore del taglio di tutti i diritti, in modo che idealmente in qualsiasi luogo del programma si abbia accesso solo a ciò che si deve fare in quel luogo.
Ricorda tutto nel progetto a cui sta lavorando in quel momento. E i codici passati? Ricorda altrettanto bene quello che ha scritto un anno fa? Dove le cose sono cambiate, ecc. Ora il compito è quello di ritoccare o correggere il vostro vecchio codice.
Alexey Navoykov:
...
No, il kung fu qui è esattamente OOP. Un sacco di mosse e tecniche, tra cui in una lotta il 10% dell'utile. Ma che bellissimi stili! E drago, e scimmia, e fenicottero e rospo... Ho un sambo specifico. Si taglia e si ottiene il risultato.
No, è OOP che è kung fu qui. Un sacco di mosse e trucchi, tra i quali il 10% tornerà utile in un combattimento. Ma che bellissimi stili! Drago, scimmia, fenicottero e rospo... Ho un sambo specifico. Si taglia e si ottiene il risultato.
Non lo è.
L'ho già detto cento volte sull'utilità dell'incapsulamento e dei vincoli dei diritti.
L'utilità dell'ereditarietà e del polimorfismo può essere vista chiaramente quando si ha a che fare con liste di elementi dove c'è un'interfaccia virtuale comune, ma l'implementazione è significativamente diversa.
Ecco la situazione più semplice che ho incontrato proprio questa settimana: c'è una lista di strutture, uno dei cui campi è un doppio valore. È nata l'idea di approssimare questi valori usando OOP.
Senza OOP, o devo scrivere interamente procedure che creino gli SLAE corrispondenti e li risolvano. Oppure, se ho già un tale programma per lavorare con un array di valori - scrivere procedure che creino tale array, e passarlo alla funzione di libreria.
Con OOP - eredito dalla classe CLSMCore, e sovraccarico le funzioni virtuali che restituiscono valori puntuali. Immediatamente posso ottenere i coefficienti del polinomio di approssimazione.
Cioè, a parità di condizioni (quando abbiamo una funzione o una classe di libreria), perderei senza OOP introducendo un array intermedio extra. Per non parlare della necessità di capire esattamente come popolarla. (Le funzioni di recupero dei valori - con o senza OOP - devono essere scritte). Il vantaggio principale, secondo me, è la semplicità di supporto e di modifica. Con OOP c'è meno da capire. E all'inizio ho speso assolutamente tanto sforzo per scrivere la classe CLSMCore quanto ne avrei speso per la funzione di approssimazione della libreria senza OOP.
Non lo è.
L'ho già detto cento volte sull'utilità dell'incapsulamento e dei vincoli dei diritti.
L'utilità dell'ereditarietà e del polimorfismo si vede chiaramente quando si lavora con liste di elementi che condividono un'interfaccia virtuale comune, ma l'implementazione è significativamente diversa.
Ecco la situazione più semplice che ho incontrato proprio questa settimana: c'è una lista di strutture, uno dei cui campi è un doppio valore. È nata l'idea di approssimare questi valori usando OOP.
Senza OOP, o devo scrivere interamente procedure che creino gli SLAE corrispondenti e li risolvano. Oppure, se ho già un tale programma per lavorare con un array di valori - scrivere procedure che creino tale array, e passarlo alla funzione di libreria.
Con OOP - eredito dalla classe CLSMCore, e sovraccarico le funzioni virtuali che restituiscono valori puntuali. Immediatamente posso ottenere i coefficienti del polinomio di approssimazione.
Cioè, a parità di condizioni (quando abbiamo una funzione o una classe di libreria), perderei senza OOP introducendo un array intermedio extra. Per non parlare della necessità di capire esattamente come riempirlo. (Le funzioni di recupero dei valori - con o senza OOP - devono essere scritte). Il vantaggio principale, secondo me, è proprio la semplicità di supporto e di modifica. Con OOP c'è meno da capire. E all'inizio ho speso tanto sforzo per scrivere la classe CLSMCore quanto ne avrei speso per la funzione di approssimazione della libreria senza OOP.
Per esempio, non ho mai capito a cosa serva il sovraccarico di funzioni. È assurdo, vero? Facciamo una funzione senza parametri, al suo interno scriviamo tutti i calcoli delle funzioni sovraccaricate, rendiamo le variabili globali e abbiamo accesso ai risultati di qualsiasi altra funzione. Beh, non è bello!
Ma no! Divideremo tutti i calcoli in funzioni con lo stesso nome, ma con parametri diversi. E faremo un mucchio di parametri di input per ogni funzione. No, non è sufficiente. Rendiamo illeggibili i nomi dei parametri. E faremo tutti i tipi di array da passare in miscela con loro. E faremo una dozzina di tali funzioni in modo da dover riflettere su ciascuna di esse. E ci assicureremo che l'accesso ad essi sia criptato. Perché la sintassi sia più sofisticata. Questa è professionalità!
Scusa, George. Ne ho avuto abbastanza.
ZS. Solo un array globale per i risultati di 10 funzioni sovraccaricate e una funzione senza parametri che fa il loro lavoro. Come può essere peggio di così? 10 volte meno sintassi.
Io, per esempio, non ho mai capito perché le funzioni debbano essere sovraccaricate. È ridicolo, vero? Fai una funzione senza parametri, scrivi tutti i calcoli delle funzioni sovraccaricate all'interno, rendi le variabili globali e hai accesso ai risultati di qualsiasi altra funzione. Beh, non è bello!
Ma no! Divideremo tutti i calcoli in funzioni con lo stesso nome, ma con parametri diversi. E faremo un mucchio di parametri di input per ogni funzione. No, non è sufficiente. Rendiamo illeggibili i nomi dei parametri. E faremo tutti i tipi di array da passare in miscela con loro. E faremo una dozzina di tali funzioni in modo da dover riflettere su ciascuna di esse. E ci assicureremo che l'accesso ad essi sia criptato. Perché la sintassi sia più sofisticata. Questa è professionalità!
Scusa, George. Mi dispiace, George.
ZS. Solo un array globale per i risultati di 10 funzioni sovraccaricate e una funzione senza parametri che fa il loro lavoro. Come può essere peggio di così? 10 volte meno sintassi.
Esatto, dimmi di più su questa funzione. Ne hai uno con un interruttore di dimensioni mostruose che seleziona una delle decine di funzioni. In un tale switch, è molto facile fare un errore scrivendo accidentalmente del codice appartenente a uno dei rami che non c'è.
Le cose sono molto più semplici con un sovraccarico. Abbiamo dieci discendenti diversi, e in qualsiasi momento lavoriamo con UNA classe, e questa ha UNA funzione sovraccaricabile. Non possiamo scriverlo accidentalmente in un'altra classe, perché dobbiamo aprire un file completamente diverso per questo.
Inoltre - il parsing stesso in questo enorme switch è, secondo me, molto più stressante che aprire l'unica classe di cui abbiamo bisogno, e poi analizzare solo una funzione.
In effetti, nel codice assembler tutta la gestione di questo interruttore si riduce comunque allo stesso swich, in funzione di questo puntatore. Ma nel caso di OOP tutto questo è nascosto al programmatore e non interferisce con il suo lavoro. Senza OOP - devi occupartene.
In parole povere, quando si cammina - si finisce per inviare segnali ai muscoli in una certa sequenza che li muovono. Tuttavia, a livello di coscienza - si ricorda solo quale movimento fare. Ecco, l'OOP è esattamente quel tipo di "memoria di quale movimento fare". Lei "non capisce perché abbiamo bisogno di ricordare il movimento quando abbiamo un mucchio di muscoli, e nervi collegati ad essi". bene... L'ho già detto molte volte, per i titani della memorizzazione, è davvero sufficiente ricordare quali muscoli devono essere tesi in quale sequenza per andare. Non ha senso ricordare tutto il movimento. Per gli altri, che non possono ricordare così tanto, è molto più ragionevole ricordare l'intero movimento, e cosa succede ai muscoli, in quale sequenza sono tesi e in che misura - è più ragionevole nasconderlo alla mente.
Реter Konow:
Io, per esempio, non ho mai capito perché le funzioni debbano essere sovraccaricate. È ridicolo, vero? Fai una funzione senza parametri, scrivi tutti i calcoli delle funzioni sovraccaricate all'interno, rendi le variabili globali e hai accesso ai risultati di qualsiasi altra funzione. Beh, non è bello!
Tremendo, stai facendo una specie di costruzione di biciclette senza uno studio adeguato dell'approccio comune. Peter, trova qualche buon libro, forse Stroustrup, in qualche libro ha scritto un editor di testo, su un problema reale imparerai qualcosa, non ricordo il contenuto, ma è improbabile che ti insegni cose brutte.