Cosa può fare il codice OOP che il codice procedurale non può fare?
OOP è progettato per lavorare e pensare come gli esseri naturali, immaginiamo se vogliamo sviluppare un gioco di guerra dove abbiamo veicoli con molti tipi, soldati con molte abilità e armi con molte specifiche.
sviluppare questo tipo di gioco senza OOP sarà un dolore per lo sviluppatore di tenere traccia di tutti questi tipi di oggetti e di gestire i dati-strutture e la memoria bene, e anche per simulare le caratteristiche OOP come l'ereditarietà sarà difficile (anche se può essere fatto), OOP reso più facile da pensare e sviluppare anche esier a scrivere leggere e debug del codice.
Alcune volte avere OOP più del necessario renderà la comprensione e la lettura del codice poco amichevole (il mio punto di vista personale) che non mi piace
Infatti, non credo che possa esistere un compito che non possa essere rifatto da codice procedurale a OOP o viceversa. La differenza è nella manutenibilità e leggibilità del codice. Per esempio, nel codice procedurale si può fare riferimento a dati globali e/o locali (variabili). Oltre a questi, OOP aggiunge un ulteriore ambito - le variabili interne dell'oggetto (stato). È molto facile e naturale usarle in OOP, mentre l'implementazione procedurale della stessa logica richiederebbe qualche tipo di workaround con codice e strutture dati aggiuntive. In altre parole l'OOP è solo un modo più breve e più bello di codificare.
Come vuoi costruire un workaround per le funzioni virtuali sovraccaricate, incluso l'albero dell'ereditarietà - che è la parte più importante dell'OOP? Sembra che tu parli di strutture, non di OOP.
OOP è progettato per lavorare e pensare come gli esseri naturali, immaginiamo se vogliamo sviluppare un gioco di guerra dove abbiamo veicoli con molti tipi, soldati con molte abilità e armi con molte specifiche.
sviluppare questo tipo di gioco senza OOP sarà un dolore per lo sviluppatore di tenere traccia di tutti questi tipi di oggetti e di gestire i dati-strutture e la memoria bene, e anche per simulare le caratteristiche OOP come l'ereditarietà sarà difficile (anche se può essere fatto), OOP reso più facile da pensare e sviluppare anche esier a scrivere leggere e debug del codice.
alcune volte avere OOP più del necessario renderà la comprensione e la lettura del codice poco amichevole (il mio punto di vista personale) che non mi piace
Forum sul trading, sistemi di trading automatizzati e strategie di trading di prova
Cosa può fare il codice OOP che il codice procedurale non può fare?
Alain Verleyen, 2016.05.22 14:03
Sto aprendo questo argomento nella speranza di raccogliere informazioni utili sui vantaggi della programmazione orientata agli oggetti rispetto alla programmazione procedurale.
Inoltre, questo argomento è indipendente dal linguaggio in quanto mql4 e mql5 offrono lo stesso linguaggio OOP (tranne alcune nuove funzionalità avanzate non ancora disponibili in mql4 al momento).
Non voglio una "guerra" tra sostenitori e oppositori dell'OOP, quindi questo argomento sarà strettamente moderato, non sprecate il vostro e il mio tempo per favore.
Si prega inoltre di fornire esempi e codice per illustrare il vostro punto, non alta teoria o concetti astratti.
EDIT: mentre questo argomento è indipendente dalla lingua, stiamo ancora parlando di trading e mql4/mql5, quindi niente "giochi di guerra" o esempi "mele e arance" per favore.
Sono un grande fan di OOP - non posso nemmeno immaginare di tornare al MQL procedurale. È più facile rendere i programmi più complessi. Comunque... il problema di MQL è che per un nuovo utente è difficile iniziare.
- i metodi di eventi incorporati non sono OO. Bisogna agganciarsi a loro, il che richiede la dichiarazione degli oggetti di ascolto nel livello principale. Uno dei principi fondamentali di OOP è compromesso con questo design.
- mancano pacchetti di codice "di sistema" con modelli comuni. Impedisce la creazione di pacchetti compatibili tra gli utenti, e un serio codificatore OOP ha bisogno di molto tempo per creare quelli privati. I prefissi dei nomi di classe non supportati (nomi di pacchetti) sono solo un problema minore - quando non si può riutilizzare il codice esterno in ogni caso.
Quindi non consiglierei di iniziare a imparare l'OOP proprio nel MQL. Il codificatore ha bisogno di sapere cosa gli serve per farlo funzionare.
La frase "se...allora...altrimenti..." dovrebbe fare il lavoro.
Ma dai ;) 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. E se si accetta il codice assurdo come risposta alla domanda di questo thread, allora è obsoleto a tutti ;) Siete d'accordo che l'assurdità è una buona frontiera? Dai, dì di sì, solo una volta e solo per il mio ego ;)
Mi dispiace ma no, non dirò di sì... un codice o raggiunge il suo obiettivo o no, se funziona secondo le specifiche, non c'è niente di assurdo.
La domanda è "cosa può fare l'OOP che il procedurale non può fare"? Stanislav stava dicendo che l'OOP può fare le stesse cose del procedurale ma in un modo "più corto e più bello". Tendo ad essere d'accordo (tranne che sull'idea del più corto, ma non è così importante).
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 anche troppo lento, il che vorrebbe dire: Obiettivo non raggiunto, perché non voglio essere costretto a bere una tazza di caffè dopo ogni clic finché non vedo il risultato.
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?
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Sto aprendo questo topic nella speranza di raccogliere informazioni utili sui vantaggi della programmazione orientata agli oggetti rispetto alla programmazione procedurale.
Inoltre, questo argomento è indipendente dal linguaggio in quanto mql4 e mql5 offrono lo stesso linguaggio OOP (tranne alcune nuove caratteristiche avanzate non ancora disponibili in mql4 al momento).
Non voglio una "guerra" tra sostenitori e oppositori dell'OOP, quindi questo argomento sarà strettamente moderato, non sprecate il vostro e il mio tempo per favore.
Si prega inoltre di fornire esempi e codice per illustrare il vostro punto, non alta teoria o concetti astratti.
EDIT: mentre questo argomento è indipendente dalla lingua, stiamo ancora parlando di trading e mql4/mql5, quindi niente "giochi di guerra" o esempi "mele e arance" per favore.