Cosa può fare il codice OOP che il codice procedurale non può fare? - pagina 2

 
Doerk Hilger:
Programmare GUI è stato ciò che ho fatto per la maggior parte del mio tempo come programmatore. Non è possibile codificare una GUI completa che ha bisogno di comunicare in diverse direzioni tramite if e else. Avreste bisogno di così tante dichiarazioni che il codice diventerebbe illeggibile e alla fine troppo lento, il che porterebbe a non raggiungere l'obiettivo. Fatto.

Non costruirò una GUI in linguaggio procedurale per dimostrare che hai torto. Ma potrei senza alcun dubbio.

A proposito, è anche facile codificare codice illeggibile e molto più lento in OOP, e come sapete la libreria standard Metaquotes è una buona prova di questo.

 
Doerk Hilger:

...

A causa della circostanza che una CPU non sa nulla di OOP, si può - ovviamente - codificare tutto senza usare solo puntatori e array complessi. Ma questo è assurdo. Potrei anche assumere 10000 persone che disegnano il contenuto del mio schermo su pellicola in tempo quasi reale e lo trasmettono in sequenza con un proiettore di luce sul muro. Anche questo è raggiungere l'obiettivo?

Sei d'accordo che il sistema operativo Windows offre una buona interfaccia grafica? Per quanto ne so, è scritto in C. Linguaggio procedurale, non OOP.

Ti sbagli Dirk se pensi che un programma complesso possa essere costruito solo con OOP. Dovresti piuttosto spiegare perché è meglio codificarlo con OOP.

 
Doerk Hilger:
Uh, andiamo ;) Non proprio ;) Se qualcosa di nativo potrebbe fare il lavoro in qualche modo strano, allora i suoi puntatori, ma ci sono restrizioni in MQL. Se poi altro ... il codice diventerebbe assurdo.
I puntatori difunzione sono già stati introdotti in MQL5, e MQL4 probabilmente supporterà anche questa caratteristica. Il codice procedurale NON sarà assurdo, perché è stato per molti anni l'unico modo di codificare prima che l'OOP diventasse mainstream. Il codice procedurale sembrerà in generale più complesso e più difficile da capire rispetto all'analogo OOP - questo è tutto.
 
Alain Verleyen:
Dubito fortemente che OOP sia un modo più breve di codificare.
Naturalmente, non intendo un caso banale di una funzione, ma un tipo di compito del mondo reale che richiede decomposizione del codice, controllo delle dipendenze e altro personale simile.
 
Alain Verleyen:

Sei d'accordo che il sistema operativo Windows offre una buona interfaccia grafica? Per quanto ne so, è scritto in C. Linguaggio procedurale, non OOP.

Ti sbagli Dirk se pensi che un programma complesso possa essere costruito solo con OOP. Dovresti piuttosto spiegare perché è meglio codificarlo con OOP.

Ho codificato GUI in Assembler, interamente. Ma in Assembler posso lavorare con i puntatori, in C posso lavorare con i puntatori e naturalmente la base di Windows non è OOP, ma parliamo di MQL che non supporta i puntatori nulli in modo nativo e a causa di ciò, non sarete in grado di codificare GUI complesse con solo if then else, almeno non con un risultato che può essere utilizzato senza grande mancanza di prestazioni.

E questa risposta include già la domanda, perché è meglio con OOP - dove "meglio" è ancora l'aggettivo sbagliato. Il metodo OOP implementa l'uso di tali puntatori, ma senza costringervi a trattare con essi. Internamente, l'OOP è realizzato con array multidimensionali per i puntatori di funzioni e variabili. Cercare di codificare cose del genere è come reinventare una ruota che non rotolerà mai così liscia come quella che avete già davanti a voi.

 
Doerk Hilger:

Ho codificato GUI in Assembler, interamente. Ma in Assembler posso lavorare con i puntatori, in C posso lavorare con i puntatori e naturalmente la base di Windows non è OOP, ma parliamo di MQL che non supporta i puntatori nulli in modo nativo e a causa di ciò, non sarete in grado di codificare GUI complesse con solo if then else, almeno non con un risultato che può essere usato senza grande mancanza di prestazioni.

E questa risposta include già la domanda, perché è meglio con OOP - dove "meglio" è ancora l'aggettivo sbagliato. Il metodo OOP implementa l'uso di tali puntatori, ma senza costringervi a trattare con essi. Internamente, l'OOP è realizzato con array multidimensionali per i puntatori di funzioni e variabili. Cercare di codificare cose del genere è come reinventare una ruota che non rotolerà mai così liscia come quella che avete già davanti a voi.

Non sono uno specialista di GUI, quindi non discuterò ulteriormente. Ho capito il tuo punto di vista: OOP permette di creare software complessi che altrimenti sarebbero meno efficienti o implicherebbero troppo lavoro.
 

È solo la mia preferenza personale dovuta alla mia piccola(!) esperienza!

1) Non mi piace ad esempio Java perché il 99% delle volte cercavo una funzione senza sapere come potrebbe essere il suo nome, se esiste o meno e se devo comunque codificarla da solo...

2) Non mi piace il C++ perché devo scrivere più di quanto mi servirebbe per scrivere un linguaggio tipo script come mq4 o anche Perl.

3) Non mi piace il C++ perché capire il codice di qualcun altro mi fa saltare da un file all'altro dove trovo solo funzioni di 2,3 righe che rendono molto difficile capire cosa e come viene calcolato il s.th. Naturalmente ci sono spiegazioni come "calcolo dello stop" ma la procedura di calcolo è anche divisa in diverse funzioni in diversi file.

4) Sono assolutamente a posto con enum e array di enum-variabili. Non ho bisogno di codificare oggetti reali immaginati. Le GUI potrebbero essere un problema diverso in quanto consistono in molte altre cose che potrebbero essere codificate come oggetti per un facile modo di riutilizzarle. Ma di quanti oggetti diversi ha bisogno un EA? Uno per le posizioni? Se ci fossero molti "oggetti" diversi (GUI) potrebbe aiutare - ma non li vedo qui.

5) Infine MQ5 non può ancora eseguire il suo backtest sui tick dei clienti:( <Modificato dal moderatore come off-topic: questo non ha nulla a che fare con mql5 ma con MT5>.

 
Rispetto davvero qualcuno che codifica assemblare, si deve avere una buona conoscenza di come funziona l'hardware stesso, semplicemente incredibile, duro nessuno usa oggi
 
coringajoker:
Rispetto davvero qualcuno che codifica assemblare, si deve avere una buona conoscenza di come funziona l'hardware stesso, semplicemente incredibile, duro nessuno usa oggi

Non lo codifico più, ma in passato soprattutto. Sui chip Intel 80x86 era l'unica possibilità di ottenere un vero vantaggio in termini di prestazioni visive. E naturalmente, è una conoscenza di base che non voglio assolutamente perdere, anche se non ne ho più bisogno in dettaglio, ma sai sempre cosa succede con il tuo codice alla fine e sai come usare questo come un vantaggio in termini di velocità di esecuzione.

Sì, i "buoni" vecchi tempi ;) ... Ma anche folli, non c'erano nemmeno variabili, nessuna funzione vera e propria, nessun if then else, solo registri, stack, interrupt e indirizzi di memoria. Roba da pazzi :)

 

OOP è uno strumento per dividere il codice in piccole parti riutilizzabili. Ma la parte migliore sono i modelli. Questa caratteristica permette di semplificare il codice. Il miglior esempio è la classe array. In Java devi creare una classe per tipo. In C++ e Mql5 si può avere tutto in una classe riducendo il codice ridondante e aggirando alcuni problemi quando si mischiano primitive e oggetti.

PS: A proposito di ASM, è vecchia scuola. L'ho usato quando prima dei primi compilatori in modalità di protezione ed era divertente superare le limitazioni. 64K segmenti con selettori erano l'incubo dei codificatori di allora. Ogni volta che scrivevi nel posto sbagliato dovevi riavviare il computer :)