OOP vs programmazione procedurale - pagina 39

 
Andrei:

La classe ha solo variabili interne e nessun ingresso o uscita... Dove avete visto l'uso nella programmazione di un tale oggetto che non ha alcun contatto con il mondo esterno e bolle nel suo stesso succo?


Perché state discutendo di qualcosa che non avete visto? Viene creato un costruttore di classe che può ottenere qualsiasi numero di parametri. Diverse classi figlie possono avere set di parametri completamente diversi nei loro costruttori. Potete semplicemente scrivere metodi per impostare i parametri.

 
СанСаныч Фоменко:

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 documentazione.


Quante volte devo dirvi la stessa cosa? OOP non è solo un mezzo di strutturazione del codice; contiene anche meccanismi che sono assenti nella vostra programmazione procedurale.

Questo è forse il caso in cui se una persona non ha visto le montagne, non capirà cos'è, anche se glielo dici.

 
Реter Konow:

Personalmente cerco la versatilità nelle soluzioni. Questo richiede lo "splicing" di funzioni simili in un unico blocco senza aumentare la dimensione del codice. Aumenta l'efficienza del meccanismo e non c'è bisogno di sovraccaricare e dividere. Devi solo usare un po' il tuo cervello - tutto qui).

Cioè, c'erano due funzioni di 20 righe ciascuna. Entrambi eseguono azioni simili o risolvono compiti simili. Il mio obiettivo è fare una funzione che faccia il lavoro di entrambe con non più di 20 righe di codice. Questo è il modo in cui creo i blocchi.


Da quanto tempo stai studiando questa tua biblioteca?

 

Per la gioia - R è scritto in un modo assolutamente disgustoso "tutto in un bidone della spazzatura senza differenziazione di accesso". Un approccio vecchia scuola di vent'anni fa, senza aree di visibilità, protezione o multisessione. Scrivo come se fossi l'unico. Sì, il progetto è nato sotto una persona da sviluppatori non professionali. Deve essere riscritto da zero. Almeno una volta.

Ho avuto l'idea di fare un'interfaccia normale in R da MQL5, ma dopo aver scavato più a fondo ho deciso di non integrarla affatto. Il sistema è categoricamente incapace di proteggere i dati e le sessioni.

Finché un programmatore non lavora in normali team di sviluppo con requisiti rigorosi (sbattendo le mani per un paio d'anni almeno) non diventerà uno sviluppatore in senso normale. Noi afferriamo la testa il 90% delle volte quando guardiamo i lavori di prova quando consideriamo i candidati. Orrore totale in tutta l'industria dello sviluppo.

Quindi, ancora una volta, gli oppositori dell'OOP stanno mostrando una sorta di buffoneria qui.

Scusa ancora.

 
СанСаныч Фоменко:

Wow!

Mi chiedevo: c'è un altro modo nella programmazione di oggi per confondere un problema di livello dell'uovo in modo più fresco?

Avvicinarsi a una macchina ferma in un ingorgo, guardare come è messa e dire al guidatore: "C'è un modo per confondere meglio il problema, camminare per cento metri qui"?

Come dimostra la mia esperienza, questi "problemi confusi" sono molto più facili da capire che gli EA "senza problemi" fatti copiando da un unico modello con tutte le variabili globali.

 
Dmitry Fedoseev:

E perché state discutendo di qualcosa che non avete visto? Viene creato un costruttore di classe che può ottenere qualsiasi numero di parametri.

Leggete attentamente, riguardava la classe, non il costruttore della classe.

Inoltre, suggerisci di nuovo di fare un lavoro da scimmia - piantare un giardino su un terreno quando possiamo avere accesso ai parametri senza fare NULLA in caso di variabili esterne o passarli direttamente senza alcun mal di testa inutile con costruttori-distruttori e tutte le perdite di memoria che ne derivano.

 
СанСаныч Фоменко:

Il mioOnInit() sembra più o meno lo stesso - una dozzina di linee...

Quindi?

Per Reason, in TUTTI i miei EA ci sono dieci linee (senza contare le inclusioni e i commenti).

#include <MyLib\DebugOrRelease\DebugSupport.mqh>
#include <MyLib\Factories\ForTrade\EURGBP\B1H2C20T2_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B2H2C20T4_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B3H2C20T2_0001_EPF.mq5>

// Объявляем фабрики частей эксперта.
CB1H2C20T2_0001_EPF epfFact_0;
CB2H2C20T4_0001_EPF epfFact_1;
CB3H2C20T2_0001_EPF epfFact_2;

// Объявляем функцию получения указателя на фабрику.
CEAPartsFactoryT* CEAPartsFactoryT::GetAdvisorsPartsFactory(uint uiFactIdx = 0)
{
   if(uiFactIdx == 0) return(GetPointer(epfFact_0)); 
   if(uiFactIdx == 1) return(GetPointer(epfFact_1)); 
   if(uiFactIdx == 2) return(GetPointer(epfFact_2)); 
   return(NULL); 
};

#include <MyLib\TSTemplate\ExpertAdvisorT.mq5>

Nel nostro caso, ci sono tre TS completamente diversi in un EA. Lavorano tutti simultaneamente, senza interferire l'uno con l'altro.

Ulteriori TC possono essere aggiunti dichiarando il factory appropriato e aggiungendo il codice che lo restituisce in una funzione.

Ma la vera questione non è se ci sono troppo poche o troppe linee di codice. La questione è quanto siano facili da mantenere e modificare se necessario.

SanSanych, puoi capire facilmente il file della tabella fornito da Peter? E modificarlo facilmente? Bene, allora tu, come Peter, non hai bisogno di OOP.

 
Реter Konow:
OOP è un metodo per separare, avvolgere e nascondere parti di un meccanismo. Se questo è necessario o no, sta allo sviluppatore deciderlo. Non ha niente a che vedere con il rendere il meccanismo più efficiente. Struttura il modo di pensare, sì. Non si sa se la struttura sia corretta o meno. Se sia necessario dipende da una persona in particolare, imho.

Esattamente. Questa è l'essenza dell'incapsulamento.

Ci sono anche l'ereditarietà e il polimorfismo.

 
Реter Konow:
OOP è un metodo per separare, avvolgere e nascondere parti di un meccanismo. Se questo è necessario dipende dall'individuo. imho.

Esattamente, dipende dall'individuo. Perché un programmatore, che non soffre di schizofrenia, dovrebbe nascondere strenuamente l'accesso a una parte del proprio codice che lui stesso sta debuggando? Non preferiresti legarti le mani da solo? :)

 
Renat Fatkhullin:

Finché un programmatore non ha lavorato in normali team di sviluppo con requisiti rigorosi (battuto le mani per un paio d'anni minimo), non diventerà uno sviluppatore nel senso normale del termine. Noi afferriamo la testa il 90% delle volte quando guardiamo i lavori di prova quando consideriamo i candidati. Orrore totale in tutta l'industria dello sviluppo.

Mi chiedo in cosa si manifesta questo "orrore".

Posso supporre che abbia a che fare con l'uso di OOP, perché nella programmazione procedurale l'attenzione principale è rivolta alla logica del lavoro dell'algoritmo e non a tutti i tipi di aggiunte esterne OOP-esque, con le quali è molto facile costruire una foresta di qualsiasi ottusità.