OOP vs programmazione procedurale - pagina 36
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
1. Non in nessuna misura. La redditività non dipende dall'AOP.
2. Secondo me, di un ordine di grandezza (dieci volte). Ma il guadagno principale di OOP è nel supporto del codice. Ora riesco a capire molto rapidamente il codice che ho scritto un anno o più fa. Ricordo bene come ho capito i miei primi programmi ANSI C in stile puramente procedurale. Era molto più difficile.
1. questa è la principale risposta alla necessità di OOP.
2. è una questione di esperienza nelle squadre. Ho scritto tutto ciò di cui avevo bisogno. Un paio di anni fa ho deciso di scrivere ancora un po' - tutto si legge, senza problemi.
Dalle vostre risposte ho capito una cosa: OOP è un certo standard che introduce la disciplina della programmazione, introduce l'uniformità e, su questa base, meno errori inizialmente e, soprattutto e più importante, riduce i problemi di modifica in principio. Ma lo stesso risultato è stato ottenuto con un'attenta osservanza dei GOST, delle fasi di sviluppo, della documentabilità.
Non riesco a capire perché non ho MAI incontrato nulla di simile nel mio lavoro. Perché ci sarebbe un problema di differenziazione di accesso variabile per UN solo sviluppatore in un programma non così grande? Ci sarebbero 100 sviluppatori, ognuno dei quali scriverebbe 100 funzioni. Teoricamente, potrebbe essere inventato. Ma praticamente, la programmazione si è evoluta a OOP per quasi 40 anni, sono state scritte montagne di codice e non ho mai sentito niente del genere.
Beh, all'inizio i programmi erano scritti in codice.
OOP è solo una tecnologia che permette di scrivere programmi più complessi più velocemente e poi mantenerli in modo più efficiente.
Ma non significa che OOP sia una panacea. Io dico che se avete memoria come Peter, non avete bisogno di OOP per niente - dichiarate tutto globalmente e fatelo, dato che vi ricordate tutto e permettete facilmente di evitare collisioni o mescolanze di variabili. Ma ho una memoria molto peggiore. E la delimitazione - la uso molto. Negli ultimi anni mi è piaciuto molto il modificatore const - prima lo usavo raramente. Ora lo uso molto spesso. Solo per avere accesso solo a ciò di cui ho bisogno e non di più. In modo che questo accesso sia di sola lettura nei luoghi in cui non è destinato ad essere modificato.
George Merts:
Sì, infatti, ci sono situazioni in cui improvvisamente si scopre che è quasi impossibile ottenere i dati di cui si ha bisogno. Sono nascosti dietro diverse interfacce virtuali. Tuttavia, questa situazione mostra chiaramente che il sistema non è stato originariamente progettato correttamente, non prevedeva il trasferimento di questi dati. Questa situazione è davvero molto spiacevole. O dobbiamo costruire frettolosamente delle "stampelle" sotto forma di interfacce aggiuntive, o ristrutturare l'intero sistema. Beh... motiva il programmatore a pensare più attentamente all'architettura del sistema.
Se il programmatore è un profeta e chiaroveggente, che vede in anticipo e in tutti i dettagli della struttura di dati necessaria per tutte le possibili varianti dell'idea principale, allora probabilmente ha senso agire nel suo modo. O farlo nella fase finale, quando tutto funziona già e il codice è debuggato senza usare questi add-on, ma di nuovo, a condizione che non ci sia mai bisogno di cambiare e riorganizzare nulla...
1. questa è la principale risposta alla necessità di OOP.
2. è una questione di esperienza nelle squadre. Ho scritto tutto ciò di cui avevo bisogno. Un paio di anni fa ho deciso di scrivere ancora un po' - tutto si legge, senza problemi.
Dalle vostre risposte ho capito una cosa: OOP è un certo standard che introduce la disciplina della programmazione, introduce l'uniformità e su questa base, meno errori inizialmente e, soprattutto e più importante, i problemi durante la modifica sono essenzialmente ridotti. Ma lo stesso risultato è stato ottenuto con un'attenta osservanza dei GOST, delle fasi di sviluppo, della documentabilità.
1. No. L'OOP non è uno strumento per garantire la redditività. E non si può parlare della necessità dell'OOP mentre si guarda alla redditività. OOP è uno strumento per semplificare lo sviluppo e la manutenzione del codice.
2. È bello quando i TC di dieci anni fa funzionano ancora. Non posso vivere così, smettono regolarmente di funzionare per me, devo costantemente modificarli. E OOP è un grande aiuto per me in questo.
E riguardo all'OOP-qualcosa di standard, sì, tutto vero. Ed è vero che si può ottenere lo stesso risultato se lo si mantiene scaglionato e documentato. Ma mi sembra che ci voglia più sforzo che nel caso dell'OOP.
All'inizio, i programmi erano scritti in codice.
OOP è semplicemente una tecnologia che permette di scrivere programmi più complessi più velocemente, e poi mantenerli in modo più efficiente.
Ma questo non significa che OOP sia una panacea. Io dico che se avete memoria come Peter, non avete bisogno di OOP - dichiarate tutto globalmente e avete finito, dato che vi ricordate tutto e permettete facilmente di evitare collisioni o mescolanze di variabili. Ma ho una memoria molto peggiore. E la delimitazione - la uso molto. Negli ultimi anni mi è piaciuto molto il modificatore const - prima lo usavo raramente. Ora lo uso molto spesso. Solo per non avere accesso solo a quello che mi serve e non di più. In modo che questo accesso sia di sola lettura in quei posti dove non si vuole che sia modificato.
All'inizio, i programmi erano scritti in codice.
Non rigiriamo la frittata, va bene?
OOP è semplicemente una tecnologia che permette di scrivere programmi più complessi più velocemente e poi mantenerli in modo più efficiente.
Questo è discutibile, e molto discutibile.
I programmi più veloci sono scritti e mantenuti in modo efficiente se hanno una buona documentazione di progettazione. Echi di questo problema si possono trovare nel mercato, dove si presta molta attenzione alla TOR. Se il TOR è pessimo, nessun OOP aiuterà.
I programmi che hanno una buona documentazione di progetto sono scritti e mantenuti in modo più rapido ed efficiente. Echi di questo problema si possono trovare nel mercato, dove si presta molta attenzione alla TOR. Se il TOR è pessimo, nessun OOP aiuterà.
Se il programmatore è un profeta e chiaroveggente, vedendo in anticipo e in tutti i dettagli la struttura di dati necessaria per tutte le possibili varianti dell'implementazione dell'idea principale, allora probabilmente ha senso agire nel vostro modo. Oppure farlo nella fase finale, quando tutto funziona già e il codice è debuggato senza usare questi add-on, ma di nuovo, a condizione che non ci sia mai bisogno di cambiare e riorganizzare nulla...
OOP è semplicemente una tecnologia che permette di scrivere programmi più complessi più rapidamente, e poi mantenerli più efficacemente.
Come spiegato sopra, OOP non è originariamente inteso per la scrittura e il debugging veloce del codice a causa dei molti wrapper aggiuntivi, sovrastrutture intermedie e adattatori... Ha senso solo nella fase finale, quando tutto funziona e viene debuggato e la struttura dei dati ha acquisito la sua forma finale... Cioè, è una procedura puramente cosmetica di imballaggio del codice pronto per il successivo stoccaggio...
Ma un'altra cosa è più importante per me - Igor ha detto correttamente sopra - ogni classe è responsabile solo delle proprie variabili, è impossibile "entrare" nelle variabili di qualcun altro da essa. Di conseguenza, la maggior parte dei problemi sono tagliati fuori nella fase di compilazione.
La classe ha solo variabili interne e nessuna variabile di ingresso o uscita... Dove avete visto l'uso nella programmazione di un tale oggetto che non ha contatto con il mondo esterno e bolle nel suo stesso succo?
.... I programmi moderni non hanno praticamente bisogno di documentazione - tutto è sul palmo della mano nelle interfacce di classe.
Spiegate questo ai meta-citi: perché hanno scritto enormi manuali per il terminale, per il linguaggio e in generale, dove è finita questa montagna di documentazione per i prodotti software su Cp... In effetti, ci sono prodotti software senza documentazione? È strano che non lo noti.