OOP vs programmazione procedurale - pagina 12
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
Come posso usare l'OOP se non posso nemmeno inserire le classi? Semplicemente non ne ho bisogno. Non ho bisogno di strutture. È una divisione artificiale, che non è giustificata dall'autosviluppo del mio programma. Esattamente - l'autosviluppo. Non c'è altro nome per definirlo.
Così, in questo processo, i blocchi di codice stessi sono divisi per necessità che nasce nel processo di miglioramento e di aggiunta di nuove funzioni. Prima vengono create le funzioni, e poi vengono gradualmente combinate in blocchi più grandi, che vengono rifiniti e aggiornati con nuove caratteristiche. Con il tempo, questi blocchi si disintegrano ed emergono nuovi blocchi. Tutto avviene in modo naturale. Faccio solo "girare" la nuova funzionalità per acquisire nuove caratteristiche, e poi la macino fino a uno stato di qualità. Allo stesso tempo, la struttura del codice cambia e si trasforma costantemente. Non tengo nessuno schema chiaro e tutto si sviluppa in direzioni imprevedibili. Improvvisamente, in questo processo, trovo opportunità per un salto di qualità. E faccio questo salto.
Ecco come si evolve il mio programma. Si espande, poi si restringe, si sgretola ed emerge trasformato. Ci sono cambiamenti globali, salti qualitativi, ma ci sono anche stati stabili a lungo termine.
In questo processo, qualsiasi regola non necessaria e sintassi aliena del linguaggio rallenterà solo le cose.
Come posso usare l'OOP se non posso nemmeno inserire le classi? Semplicemente non ne ho bisogno. Non ho bisogno di strutture. È una divisione artificiale, che non è giustificata dall'autosviluppo del mio programma. Esattamente - l'autosviluppo. Non c'è altra parola per definirlo.
Così, in questo processo, i blocchi di codice stessi sono divisi per necessità che nasce nel processo di miglioramento e di aggiunta di nuove funzioni. Prima vengono create le funzioni, e poi vengono gradualmente combinate in blocchi più grandi, che vengono rifiniti e aggiornati con nuove caratteristiche. Con il tempo, questi blocchi si disintegrano ed emergono nuovi blocchi. Tutto avviene in modo naturale. Faccio semplicemente "girare" la nuova funzionalità per acquisire nuove caratteristiche, e poi la macino fino ad uno stato di qualità. Allo stesso tempo, la struttura del codice cambia e si trasforma costantemente. Non tengo nessuno schema chiaro e tutto si sviluppa in direzioni imprevedibili. Improvvisamente, in questo processo, trovo opportunità per un salto di qualità. E faccio questo salto.
Ecco come si evolve il mio programma. Si espande, poi si restringe, si sgretola ed emerge trasformato. Ci sono cambiamenti globali, salti qualitativi, ma ci sono anche stati stabili a lungo termine.
In questo processo, qualsiasi regola e sintassi inutile con la lingua di qualcun altro rallenterà solo le cose.
Potrebbe valere la pena di passare una settimana, però, per sistemare le strutture. L'affermazione "non ho bisogno di strutture" sembra davvero stupida. L'unica conclusione è che non sai affatto cosa sia.
Ci sono compiti che non possono essere risolti in modo ottimale proceduralmente.
Dipende da cosa intendi per "in modo ottimale" )
Per quanto mi riguarda, OOP è solo un comodo involucro, non una soluzione ai problemi. Ecco perché la discussione è a un punto morto qui.
Nel complesso tutti sembrano essere d'accordo sul fatto che qualsiasi compito sarà risolto molto più velocemente e in modo più compatto utilizzando l'approccio strutturato-procedurale. E si spende più tempo nell'avvolgere le classi che nella codifica stessa. A volte ci si lascia trasportare, si incasina un mucchio di classi, e poi si pensa, perché preoccuparsi di tutto questo...
Un'altra cosa sulla "programmazione procedurale con puntatori di funzione" - perché dovrebbe essere messa in una categoria separata? Penso che i puntatori di funzione siano solo uno stile strutturale-procedurale.
Dipende da cosa intendi per "modo ottimale" )
Per quanto mi riguarda, OOP è solo un comodo involucro, non una soluzione a qualsiasi problema. Ecco perché la discussione è a un punto morto qui.
Nel complesso tutti sembrano essere d'accordo sul fatto che qualsiasi compito sarà risolto molto più velocemente e in modo più compatto utilizzando l'approccio strutturato-procedurale. E si spende più tempo nell'avvolgere le classi che nella codifica stessa. A volte ci si lascia trasportare, si incasina un mucchio di classi, e poi si pensa, perché preoccuparsi di tutto questo...
Un'altra cosa sulla "programmazione procedurale con puntatori di funzione" - perché dovrebbe essere messa in una categoria separata? Credo che i puntatori di funzione siano solo stile strutturale-procedurale.
Ilpolimorfismo nonè in alcun modo realizzabile per via procedurale, tranne che per i puntatori di funzione. OOP è definitivamente polimorfismo, mentre nella programmazione procedurale non ci sono necessariamente puntatori alle funzioni.
Non si dovrebbe avvolgere tutto in classi.
Non dovremmo passare almeno una settimana a occuparci delle strutture? L'affermazione "non ho bisogno di strutture" sembra davvero stupida. L'unica conclusione è che non sapete affatto cosa sia.
La struttura è una cosa che si spiega da sola. Combina un insieme nominato di variabili di tipo diverso. Il tipo principale nel mio programma è int. Uso il doppio solo in alcuni posti. solo in un blocco particolare.
Perché ho bisogno di strutture nel contesto dell'OOP?
Ho una struttura che appartiene al kernel. Cioè la struttura del kernel stesso al suo interno. Questo è tutto ciò di cui ho bisogno.
La struttura è autoesplicativa. Combina un insieme nominato di variabili di tipo diverso. Il tipo principale nel mio programma è int. Uso il doppio solo in alcuni posti. solo in un blocco particolare.
Perché ho bisogno di strutture nel contesto dell'OOP?
Ho una struttura che appartiene al kernel. Cioè la struttura del kernel stesso al suo interno. Questo è tutto ciò di cui ho bisogno.
Devi aver scritto un programma per te stesso per tre anni.
Si può, ma con diverse efficienze di funzionamento. Il supporto non è il problema qui, è troppo relativo.
Ci sono compiti che proceduralmente non si possono risolvere in modo ottimale.
Sono un sostenitore dell'OOP, ma di fatto, il processore non sa nulla dell'esistenza dell'OOP, può eseguire il codice macchina, tutto qui. Agli albori del computer si scrivevano programmi in questo modo, direttamente in codice macchina.
Ecco perché c'erano così tante donne programmatrici. Perché gli uomini si ubriacavano e impazzivano a causa di questo lavoro).
Dopo tutto, d'accordo - è l'efficienza della soluzione che conta.
Il sovraccarico della sintassi e la complessità delle regole non hanno mai contribuito a mantenere le soluzioni efficienti. Sono state la semplicità e la brevità espresse in concisione, universalità e leggibilità dei blocchi di codice ad aiutare.
E cosa si intende per soluzioni efficienti?
Le mie regole di programmazione sono: meno codice, meno regole, meno sintassi...
Non sono un fan di OOP.
Ma in termini di manutenibilità, scalabilità e facilità d'uso da parte di terzi, ciò che TC (Peter, non Karputov) sta spingendo è solo età della pietra.
Ho una forte opinione che ogni programmatore dovrebbe lavorare in un team, idealmente più di 4 persone, solo per capire che l'efficienza e l'universalità del codice non significa che questo codice sia buono.
Sono un sostenitore dell'OOP, ma di fatto, il processore non sa nulla dell'esistenza dell'OOP, può eseguire il codice macchina, tutto qui. Nei primi giorni del computer, è così che si scrivevano i programmi, direttamente nel codice macchina.
Ecco perché c'erano così tante donne programmatrici. Perché gli uomini bevevano molto e diventavano pazzi a causa di questo lavoro).
Cosa c'è? Finora una conclusione è che all'inizio si doveva scrivere un sacco di programmi in codice macchina))