OOP vs programmazione procedurale - pagina 22
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
Il fatto che tutti i sistemi moderni usino OOP non è una prova di superiorità? Non sei pronto a capire, fai domande semplici e non puoi accettare una risposta complessa... e pensi che non ci sia una risposta... Beh, non è giusto...
La mentalità cambia, sì, e all'inizio sembra che per cosa? Ma quando il progetto diventa un sacco di migliaia di linee di codice, si cominciano a raccogliere i benefici)) e capire perché e per che cosa era tutto per)).
Se un progetto è difficile e costoso da mantenere e aggiornare, e costoso e costoso da estendere, e un altro è veloce e facile, il primo morirà - è una selezione naturale.
Anche nel mio programma ci sono molte migliaia di righe di codice. La mancanza di entità inutili è una salvezza per me. Non avrei potuto svilupparlo in nessun altro modo. È la pratica più pura.
Ma basta così. Lascio questo thread.
1. il fatto che tutti i sistemi moderni usano OOP non è una prova di superiorità?
2. Semplicemente non sei pronto a capire, fai domande semplici e non riesci ad afferrare la risposta complessa... e pensi che non ci sia una risposta... Non è giusto.
Quando la tua mentalità cambia, sì, e all'inizio ti chiedi per cosa. Ma quando il progetto diventa un sacco di migliaia di linee di codice, si cominciano a raccogliere i benefici)) e a capire perché e per cosa è stato tutto questo)).
Se un progetto è difficile e costoso da mantenere e aggiornare, e un altro è veloce e facile da implementare, il primo morirà - questa è la selezione naturale
1) Tutti qui sono così fighi, che non sarà una prova per loro, ma al contrario, la prova che sono tutti così fighi di loro stessi, e tutti intorno sono tristi babbei - sono caduti per OOP.
2. molto aneddotico, ma non se ne rendono conto.
Similmente a questo argomento )) Molto tempo fa ero abbonato alla rivista Popular Mechanics, c'era una pagina di umorismo
Un giorno Leo era sul piede di guerra. Quindi sta camminando, tutto sfacciato. Incontra una volpe. Fox, presto, chi è il re delle bestie?
- Leva, certo che lo sei!
Soddisfatto, continuò.
Ha incontrato la lepre, stesso risultato.
Ha incontrato l'elefante. E l'elefante era caldo, ha solo agitato la sua proboscide dalle mosche e il leone è volato via.
E sapete cosa disse all'elefante in partenza, seduto tra i cespugli?
- E non arrabbiarti se non sai le risposte).
A proposito del riccio:
"Il riccio è in piedi nella radura, in posa, flettendo i suoi bicipiti: - Sono forte, sono coraggioso, sono agile, sono forte, sono coraggioso, sono agile...
Un orso passa - gli dà un calcio una volta, il riccio vola dietro l'albero, si alza e si scuote:
- Sono forte, sono coraggioso, sono agile... Ma io sono facile...
Ma basta parlare di questo. Lascio questo argomento.
Il fatto che non ti fidi degli altri e vuoi capire da solo è anche un bene, gli altri possono sbagliare, alcune cose sono più facili da raggiungere da soli
1. Tutti qui sono così fighi che per loro non sarà una prova, ma piuttosto una conferma che sono tutti così fighi di se stessi, sanno come, e tutti intorno a tristi babbei - caduti per l'OLP.
2) Molto aneddoticamente, ma non se ne rendono conto.
))) È divertente come le persone che non capiscono molto vendono Market Expert Advisors per $10K o segnali con 2k abbonati e ottengono davvero tanti soldi )
Questo non è l'argomento principale.
Non esiste un analogo del polimorfismo nella programmazione procedurale.
Come non c'è, se lei stesso, diverse pagine prima, ha parlato di puntatori a funzioni? Questo è l'analogo del polimorfismo, e con possibilità molto più ampie, perché si può cambiare dinamicamente.
Sembra che vi siate persi le chiacchiere :-) i moderatori hanno messo un freno ai topic flaming... ma qui si tratta di OOP vs.
A proposito, il 99% di @Peter Konow usa OOP, ma lui non ne è consapevole :-) OOP non è necessariamente "classe e template"
e anche viceversa...la presenza di oggetti e classi in un programma non è indicativa di OOP
Come no, quando lei stesso ha menzionato i puntatori di funzione qualche pagina prima? Questo è l'analogo del polimorfismo, e con possibilità molto più ampie, perché può essere cambiato dinamicamente.
Questo era ieri, quando avevo un'opinione migliore dell'opposizione. I puntatori alle funzioni in MQL sono apparsi di recente, ma oggi si è scoperto che per tutti i sostenitori non esistono affatto. Si scopre che non sanno affatto di cosa stanno discutendo. Sono sicuro che gli sono sfuggite le parole"polimorfismo" e "puntatori" negli occhi e nelle orecchie. Hanno solo un argomento - "non hai citato nessuna prova", anche se qui vedono 1000 prove.
Potete cambiare i puntatori alle classi anche dinamicamente, l'unica cosa più semplice con le funzioni è che non dovete crearle prima.
Per efficacia della soluzione, intendo la qualità della soluzione alla quale il meccanismo - e il software è senza dubbio un meccanismo - funzionerà nel modo più stabile. Il meccanismo deve essere chiaro, coerente e produttivo. La funzionalità del motore dovrebbe implementare tutti i compiti che gli sono stati assegnati. Il meccanismo non accetta il superfluo e nello sviluppo di questo meccanismo, il superfluo dovrebbe essere tagliato.
Solo che nel vostro caso questo "non necessario" è il controllo dei tipi e altre cose fondamentali che hanno lo scopo di proteggere il codice da errori di programmazione accidentali. Ecco perché il vostro codice diventa molto inaffidabile. Non c'è alcuna stabilità. Anche se ora avete fatto il debug e l'avete ripulito, ma ulteriori modifiche causeranno errori difficili da trovare che sono molto difficili da ripulire.
Non c'è dubbio che OOP contiene molti strumenti aggiuntivi che uno sviluppatore può utilizzare. Tuttavia, si dovrebbe capire il prezzo da pagare per utilizzare questi strumenti. Vale a dire, dovreste immergervi nel paradigma OOP e nella strutturazione del codice corrispondente ad esso. Usare tutto il toolkit OOP e creare molti oggetti. Il prezzo principale è nella forte complicazione del codice. Tuttavia, la pratica dimostra che dal punto di vista dell'efficienza dei meccanismi creati dovrebbero essere semplici e la presenza di qualsiasi entità in essi dovrebbe essere assolutamente provata dall'aumento dell'efficienza e niente di più.
Solo che nel vostro caso questo "extra" è il controllo dei tipi e altre cose fondamentali progettate per mantenere il vostro codice al sicuro da errori di programmazione accidentali. Ecco perché il vostro codice diventa molto inaffidabile. Non c'è alcuna stabilità. Anche se ora avete fatto il debug e l'avete ripulito, ma ulteriori modifiche causeranno errori difficili da trovare che sono molto difficili da ripulire.