OOP vs programmazione procedurale - pagina 13
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
Cosa intende per efficienza della soluzione?
Per efficienza della soluzione, intendo la qualità della soluzione in cui il meccanismo - e il software è senza dubbio un meccanismo - funzionerà nel modo più stabile. Il meccanismo dovrebbe essere chiaro, coerente e produttivo. La funzionalità del motore dovrebbe implementare tutti i compiti che gli sono stati assegnati. Il meccanismo non accetta nulla di superfluo e nello sviluppo di questo meccanismo, tutto ciò che è superfluo deve essere tagliato.
Altrimenti, o non ci sarà sviluppo o non ci sarà efficienza.
Questa è solo la mia opinione e non la impongo a nessuno.
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.
Non voglio creare un coro qui, ma mi chiedo se i sostenitori dell'OOP possono presentare del codice che risolva un problema, dove sia chiaramente visibile che questa soluzione è più efficiente di una soluzione senza OOP?
Sono un maestro nel risolvere i problemi senza OOP e vorrei combattere un maestro nel risolvere i problemi con OOP.
Cercherò di spiegarvi: diciamo che siete un esecutore e avete un cliente che vi dà sempre del lavoro da fare. E poi dopo 5-6 ordini si nota che tutti i suoi compiti sono simili in qualche modo... E che si possono combinare in un modello... E al cliente piace anche combinare questi modelli tra loro in grandi quantità... E quando il cliente chiede di nuovo un lavoro difficile, basta creare il numero necessario di istanze (diciamo, 10) di questo modello (classe) e ad ognuna di esse impostare quelle proprietà (nel costruttore) che sono capitate al cliente... Alla fine, la decisione di aprire un ordine sarà semplicemente basata su un ciclo che vedrà il risultato in ciascuna delle 10 istanze, e questo è tutto... Puoi rivettare tali ordini in 5 minuti...
Ma non sarete in grado di fare un'istanza senza OOP e dovrete rifare quasi tutto, sperando che i cambiamenti non rompano quello che avete... Come risultato, passerete molto più tempo...
Conclusione: un programmatore che conosce l'OOP sarà in grado di risolvere problemi (che sono adatti all'OOP) molto più velocemente e con meno errori...
Cercherò di spiegare, diciamo che sei un esecutore e hai un cliente che ti dà sempre lavoro... E poi dopo cinque o sei ordini si nota che tutti i suoi compiti sono in un certo senso gli stessi... E che puoi combinarli in un modello... E al cliente piace anche combinare questi modelli tra loro in grandi quantità... E quando il cliente chiede di nuovo un lavoro difficile, basta creare il numero necessario di istanze (diciamo, 10) di questo modello (classe) e a ciascuna di esse impostare quelle proprietà (nel costruttore) che sono venute in mente al cliente... Alla fine, la decisione di aprire un ordine sarà semplicemente basata su un ciclo che visualizzerà il risultato in ciascuna delle 10 istanze, e questo è tutto... Puoi rivettare tali ordini in 5 minuti...
Ma non sarete in grado di fare un'istanza senza OOP e dovrete rifare quasi tutto, sperando che i cambiamenti non rompano quello che avete... Come risultato, passerete molto più tempo...
Conclusione: un programmatore che è abile in OOP sarà in grado di risolvere problemi (che sono adatti per OOP) molto più velocemente e con meno errori...
Forse hai ragione. Non ho mai fatto ordini e non so cosa vogliono i clienti. Quello che stai descrivendo sembra più un lavoro di routine, mentre è di sviluppo che sto parlando qui. Probabilmente per il lavoro di routine (che è anche fatto da un team), OOP è insostituibile. Non ho questa esperienza e semplicemente non lo so.
E puoi dare un esempio specifico di questi compiti di tipo singolo, che è meglio non fare senza OOP?
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.
Credo fermamente che ogni programmatore debba lavorare in un team, idealmente più di 4 persone, solo per capire che l'efficienza e la generalità del codice non significa che il codice sia buono.
Oh, lavorare in una squadra è una canzone a parte! E guidare un team di programmatori è una canzone in misura pari al numero dei partecipanti.
Vi racconterò una storia di un sabato sera. Sui tempi in cui la nostra azienda entrava e usciva dal ferro. Se si è ripetuto, mi scuso, forse ho già ripassato la storia qualche tempo fa.
Il mio capo mi ha convocato e mi ha chiesto: 'Sei troppo occupato al lavoro? Ho detto: "Non proprio.
-Che cosa fai adesso, comunque? Il capo non ha mai saputo cosa faccio, perché mi sono fatto un'agenda personale, che comprendeva un assenteismo costante)).
Ho detto: "Sì, sto solo scrivendo un pacchetto di test per la nostra attrezzatura. Il capo era così contento: "Grande, giusto in tempo per provarlo in Siberia". Alexey, dobbiamo sorvolare, i ragazzi sono bloccati lì, non riescono a capire. Amavo i viaggi d'affari, avevo una libertà totale.
Volo a Krasnoyarsk, i miei ragazzi mi incontrano e mi guardano, sembrano tutti colpevoli. Siamo andati in un bar, abbiamo bevuto qualcosa e abbiamo iniziato a parlare. Gli ho chiesto: "Cosa c'è che non va? Il capo era perplesso, lei era stato in viaggio d'affari per tre mesi ed era bloccato ad un certo punto. Ha solo il tempo di mandarti dei soldi tramite bonifico.
Beh, sono allo scoperto. Hanno guidato fino a un villaggio siberiano, hanno alloggiato in una casa di accoglienza e lì c'erano due giovani sorelle. Così l'amore ha girato e gli amici sono stati coinvolti, in modo che nessuno si offendesse.
Ho detto loro che non ti avrei denunciato, io sono come te. Ma dobbiamo mantenere il ritmo. Aggiustiamo tutta la corona, mancano solo pochi chilometri, 500 chilometri, poi ti darò un bonus, strizzerò i soldi del capo e tu e questi amici festeggerete il nuovo anno, ok?
Ora le donne saranno indignate, ma Lekha è stata la prima ad essere d'accordo, dicendo che mia moglie dovrebbe partorire, preferisco restare qui per un po'! Tutti erano sposati e per qualche motivo nessuno di loro voleva tornare a casa).
D'altra parte, ho capito dentro di me quanto duramente i ragazzi potessero lavorare quando giovani e belle ragazze siberiane li aspettavano).
Questo non è affatto un argomento.
Qualsiasi compito può essere risolto con o senza OOP. Senza OOP potete anche creare facilmente funzioni unificate, che saranno usate molte volte e l'intero programma non si romperà a causa dei cambiamenti che introducete in esso. C'è un po' più di codice con OOP. La leggibilità migliora grazie all'uso di OOP? Non lo so.
Ho ogni classe memorizzata in un file separato e ogni funzione anche in un file separato. Solo una questione di abitudine e convenienza.
Un altro esempio più semplice, che è sulla superficie... Generatore di EA in MetaEditor... Chiunque, anche se non sa programmare, può mettere insieme un EA contenente un numero enorme di indicatori e condizioni in 10 secondi )))) E tutto questo è OOP ))
Non c'è assolutamente nulla da discutere.
Qualsiasi compito può essere risolto con o senza OOP. Potete anche creare facilmente funzioni unificate senza OOP che saranno usate molte volte e l'intero programma non si romperà a causa dei cambiamenti che introducete in esso. C'è un po' più di codice con OOP. La leggibilità migliora grazie all'uso di OOP? Non lo so.
Ho ogni classe memorizzata in un file separato e ogni funzione anche in un file separato. Solo una questione di abitudine e convenienza.
Qui in questo thread c'era un esempio di un problema che può essere risolto senza OOP, ma in un modo molto irrazionale.
Questo non è affatto un argomento.
Qualsiasi compito può essere risolto con o senza OOP. Senza OOP potete anche creare facilmente funzioni unificate, che saranno usate molte volte e l'intero programma non si romperà a causa dei cambiamenti che introducete in esso. C'è un po' più di codice con OOP. La leggibilità migliora grazie all'uso di OOP? Non lo so.
Ho ogni classe memorizzata in un file separato e ogni funzione anche in un file separato. Solo una questione di abitudine e convenienza.
Posso dire con certezza che non ho bisogno di OOP nello sviluppo personale, ma non sono sicuro del lavoro di squadra su un grande progetto. Lo sviluppo e la comunicazione del codice creato da diversi programmatori non mi è mai venuto in mente e non so come lo implementerei a modo mio. Questo è l'unico argomento per l'OOP nello sviluppo che attualmente accetto.
Questo non è l'argomento principale.
Non esiste un equivalente del polimorfismo nella programmazione procedurale.