OOP vs programmazione procedurale - pagina 26
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
Non c'è molto da pensare.
OOP è un meccanismo che ci permette di passare un sacco di controlli e approvazioni al compilatore. Tuttavia, dobbiamo spendere qualche sforzo in più per usarlo.
Ma se non abbiamo bisogno di tutti questi controlli e adattamenti, non ha senso usare OOP.
Per esempio, sarei diffidente nel lavorare con un array multidimensionale di kernel grafico - perché ha troppe entità inutili che non sono necessarie al momento. Distraggono e provocano errori difficili da calcolare. Lo sostituirei con un insieme di oggetti, a cui accederei con semplici interfacce compatte. Ottenendo un'interfaccia - non devo ricordare nulla - l'interfaccia stessa mi limita, e mi impedisce, per esempio, di accedere al campo o all'oggetto sbagliato. Nel caso di un array grafico di kernel, tale gestione è molto possibile.
Cioè, nel caso in cui un blocco riceve un'interfaccia, il compilatore stesso "taglia via" tutte le entità non necessarie e impedisce all'utente di fare un errore. Ma nel caso di una matrice grafica del kernel, l'utente ha un sacco di informazioni inutili dove può facilmente fare un errore.
Nella mia esperienza so che mi trovo molto meglio quando il compilatore stesso tiene traccia delle cose che non dovrebbero andare dove non dovrebbero andare nel blocco corrente. E con un array grafico di kernel - devo ricordarmelo. Il meno del mio sistema è un'estensione del più. Se improvvisamente ho bisogno di qualcosa in un blocco che va oltre il compito corrente, con un kernel array grafico è facile - basta prendere i dati necessari e lavorarci. Ma con le interfacce OOP, dovrete o richiedere i dati necessari in un'interfaccia aggiuntiva, o (cosa molto più sgradevole) modificare l'interfaccia esistente.
Non c'è molto da pensare.
OOP è un meccanismo che ci permette di passare un sacco di controlli e approvazioni al compilatore. Tuttavia, dobbiamo spendere qualche sforzo in più per usarlo.
Ma se non abbiamo bisogno di tutti questi controlli e adattamenti - non ha senso l'OOP.
Ma perché semplificare così tanto? E che dire della chiarezza e della leggibilità? E la semplicità del rilevamento e della correzione degli errori? E la portabilità? E la facilità di aggiornamento? ecc. ecc. ....
Bene, allora il tema dovrebbe avere un suono diverso. Qualcosa come: "Un nuovo toolkit di programmazione" o "Un nuovo paradigma di programmazione"...
Se è vero che hai creato qualcosa di più figo di OOP, allora autograferai il tuo quando diventerai famoso?
Nessun problema! Nessuna spesa risparmiata per un autografo per i tuoi amici. ))))
Stai scherzando, ma nella mia immaginazione, ho una tale visione di questo approccio che è una vera seccatura. Sembra che con il tempo potrò avviare il meccanismo di auto-miglioramento del sistema. Se faccio un kernel logico e lo faccio generare casualmente diversi meccanismi. Poi basta fare un po' di selezione e scegliere quelli giusti. Poi macinarli un po'... grazie al kernel, si possono fare cose incredibili.
Perché semplificare così tanto le cose. E la chiarezza e la leggibilità? E la facilità di rilevamento e correzione degli errori? E la portabilità? E la facilità di aggiornamento? ecc. ecc. ....
bel banner pubblicitario :-) "Compra i nostri elefanti".
tutte queste tesi sono ugualmente applicabili a OOP e non-OOP e FP e ovunque
Non c'è molto da pensare.
OOP è un meccanismo che ci permette di passare un sacco di controlli e approvazioni al compilatore. Tuttavia, dobbiamo spendere qualche sforzo in più per usarlo.
Ma se non abbiamo bisogno di tutti questi controlli e adattamenti, non ha senso usare OOP.
Per esempio, sarei diffidente nel lavorare con un array multidimensionale di kernel grafico - perché ha troppe entità inutili che non sono necessarie al momento. Distraggono e provocano errori difficili da calcolare. Lo sostituirei con un insieme di oggetti, a cui accederei con semplici interfacce compatte. Ottenendo un'interfaccia - non devo ricordare nulla - l'interfaccia stessa mi limita, e mi impedisce, per esempio, di accedere al campo o all'oggetto sbagliato. Nel caso di un array grafico di kernel, tale gestione è molto possibile.
Cioè, nel caso in cui un blocco riceve un'interfaccia, il compilatore stesso "taglia via" tutte le entità non necessarie e impedisce all'utente di fare un errore. Ma nel caso di una matrice grafica del kernel, l'utente ha un sacco di informazioni inutili dove può facilmente fare un errore.
Nella mia esperienza, mi trovo molto meglio quando il compilatore stesso tiene traccia delle cose che non dovrei fare nel blocco corrente. E con un array grafico di kernel - devo ricordarmelo. Il meno del mio sistema è un'estensione del più. Se improvvisamente ho bisogno di qualcosa in un blocco che va oltre il compito corrente, con un kernel array grafico è facile - basta prendere i dati necessari e lavorarci. Ma con le interfacce OOP, dovrete o richiedere i dati necessari in un'interfaccia aggiuntiva, o (cosa molto più sgradevole) modificare l'interfaccia esistente.
Vi sbagliate a pensare che il kernel sia ridondante. Ed è molto facile ricordare le sue entità perché sono rivestite di parole umane attraverso le definizioni. Tutto è raccolto lì, ma questo contenuto ha un ordine chiaro e immutabile. Le proprietà di oggetti, finestre ed elementi sono direttamente accessibili in qualsiasi punto del programma. E quali meraviglie si possono fare con il kernel in loop...
Ti sbagli completamente a pensare che ci sia qualcosa in più nel kernel. E ricordare le sue entità è molto facile, perché sono rivestite di parole umane attraverso le definizioni. Tutto è raccolto lì, ma questo contenuto ha un ordine chiaro e immutabile. Le proprietà di oggetti, finestre ed elementi sono direttamente accessibili in qualsiasi punto del programma. E quali meraviglie si possono fare grazie al kernel in loop...
Non ho detto che "il kernel è ridondante", ho detto "inutile al momento". Se sto lavorando con una linea grafica - non dovrei essere in grado di accedere alle proprietà della finestra.
Solo il fatto che tutte queste proprietà sono direttamente accessibili in qualsiasi punto del programma è il principale svantaggio del tuo approccio. In qualsiasi punto del programma, dovrebbero essere accessibili solo gli elementi che sono necessari in quel momento. Tutto il resto non dovrebbe essere disponibile. Questo - permette di evitare automaticamente molti errori.
Tutte le "meraviglie che si possono fare grazie all'accessibilità dell'intero kernel" sono, secondo me, una potenziale fonte di errori difficili da trovare e di problemi di comprensione del codice. Si dovrebbe cercare di evitare tutti questi trucchi.
Questo approccio mi ricorda compiti molto stupidi quando puntatori, incrementi e riferimenti sono scritti in una riga in un'accozzaglia che è forse corretta dal punto di vista del linguaggio ma illeggibile. Ho citato la mia funzione sopra, che sembra anche assolutamente folle, ma ho pensato che la compattezza è più importante in questo caso.
Beh, perché semplificare così tanto? E la chiarezza e la leggibilità? E la facilità di individuare e correggere gli errori? E la portabilità? E la facilità di aggiornamento? ecc. ecc. ....
Fantastico!
1. Prima dell'oop, tutti costruivamo tutto da componenti Bespoke con strumenti eccezionalmente complessi
2. Prima dell'OOP, i programmi erano una composta eccezionalmente ben mescolata
3. Prima di OOP NON avevamo sentito parlare di localizzazione dei dati e del codice e questo rendeva la nostra manutenzione estremamente dolorosa
4. La protezione dei dati tra diverse parti dello stesso programma era un incubo!
5. Prima dell'OOP, nessuno ha mai esteso i sistemi.
Questo è un fallimento totale.
Mi siedo e penso che forse questa stessa OOP è cresciuta da me perché ho applicato tutto questo alla fine degli anni 70 e molte altre cose relative alla cultura della programmazione.
Non ho detto "c'è qualcosa di inutile nel kernel", ho detto "inutile al momento". Se sto lavorando con una linea grafica - non dovrei essere in grado di accedere alle proprietà della finestra.
Solo il fatto che tutte queste proprietà sono direttamente accessibili in qualsiasi punto del programma è il principale svantaggio del tuo approccio. In qualsiasi punto del programma, dovrebbero essere accessibili solo gli elementi che sono necessari in quel momento. Tutto il resto non dovrebbe essere disponibile. Questo - permette di evitare automaticamente molti errori.
Tutte le "meraviglie che si possono fare grazie all'accessibilità dell'intero kernel" sono, secondo me, una potenziale fonte di errori difficili da trovare e di problemi di comprensione del codice. Si dovrebbe cercare di evitare tutti questi trucchi.
Questo approccio mi ricorda i compiti più stupidi quando puntatori, incrementi e riferimenti sono scritti in una riga in un pasticcio che può essere corretto dal punto di vista del linguaggio ma è assolutamente illeggibile. Ho citato la mia funzione sopra, che sembra anche assolutamente folle, ma ho pensato che la compattezza è più importante in questo caso.
Stai ragionando sul kernel sulla base di nozioni teoriche momentanee basate sulla tua esperienza, che non ha nulla a che fare con la tecnologia di cui stai parlando. Da qui alcuni problemi di accesso, ricordare le entità...
Sto ragionando per esperienza pratica con questa tecnologia, e sto dicendo che non ci sono questi problemi di accesso o di limitazione. Onestamente, non so affatto di quali problemi di accesso stiate parlando. Non ci sono e non ci sono mai stati questi problemi.
Per favore, spiegate a quali problemi di accesso vi riferite.
Cosa vi fa pensare che l'accesso debba essere limitato se causa errori? Questo è qualcosa di nuovo per me.
L'accesso diretto a un array globale in un codice di procedura può causare da solo errori difficili da trovare?
Stai parlando del kernel sulla base di nozioni teoriche immediate basate sulla tua esperienza, che non ha nulla a che fare con la tecnologia di cui stai parlando. Da qui alcuni problemi di accesso, ricordare le entità...
Sto ragionando per esperienza pratica con questa tecnologia, e sto dicendo che non ci sono questi problemi di accesso o di limitazione. Onestamente, non so affatto di quali problemi di accesso stiate parlando. Non ci sono e non ci sono mai state queste difficoltà.
Cosa intendi per "nessun problema" quando dici "si può accedere a tutto da ogni luogo"?
Questo è il problema principale! Non dovrebbe essere accessibile!
Il punto è spostare il compito del controllo degli accessi sul compilatore. Tutto è aperto e il programmatore controlla l'accesso.
Non ci sono state complicazioni perché si ricorda tutto. Beh, alla fine scoprirete che la vostra memoria sta iniziando a cedere, e allora apprezzerete la capacità del compilatore di controllare l'accesso. Non mi ricordo. E sospetto che la maggior parte delle persone dimentichi anche periodicamente come funziona qualcosa scritto mesi fa. È in queste circostanze che il controllo degli accessi diventa una manna.
Diciamo che se sei all'interno del blocco che si occupa di piazzare gli ordini - hai solo la possibilità di piazzare ordini. E non avete la capacità di disegnare un grafico. Se ti trovi in un blocco che è responsabile del disegno di un grafico, non puoi fare un ordine da lì. Questo semplifica molto il lavoro. E quando nella funzione di disegno del grafico vedrete improvvisamente una richiesta di effettuare un ordine, dovrete ricordare per molto tempo perché l'avete fatto. Sarebbe bello se ci fosse un commento dettagliato che spieghi perché è stata presa questa decisione... Ma è meglio quando gli ordini sono inseriti in un unico blocco dedicato.
Come può esserci "nessun problema" se si dice che "tutto è accessibile da qualsiasi luogo"?
Questo è il problema principale! Non deve essere accessibile!
Il punto è solo spostare il compito del controllo degli accessi al compilatore. Tutto è aperto e il programmatore controlla l'accesso.
Non ci sono state complicazioni perché si ricorda tutto. Beh, alla fine scoprirete che la vostra memoria sta iniziando a cedere, e allora apprezzerete la capacità del compilatore di controllare l'accesso. Non mi ricordo. E sospetto che la maggior parte delle persone dimentichi anche periodicamente come funziona qualcosa scritto mesi fa. È in queste circostanze che la delimitazione dell'accesso diventa una manna.
Diciamo che se sei all'interno del blocco che si occupa di piazzare gli ordini - hai solo la possibilità di piazzare ordini. E non avete la capacità di disegnare un grafico. Se ti trovi in un blocco che è responsabile del disegno di un grafico, non puoi fare un ordine da lì. Questo semplifica molto il lavoro. E quando nella funzione di disegno del grafico vedrete improvvisamente una richiesta di effettuare un ordine, dovrete ricordare per molto tempo perché l'avete fatto. Sarebbe bello se ci fosse un commento dettagliato che spieghi perché è stata presa questa decisione... Ma è meglio quando gli ordini sono inseriti in un unico blocco dedicato.