OOP vs programmazione procedurale - pagina 41

 
George Merts:

Ti avvicini a un'auto ferma nel traffico, guardi com'è messa - e dici al guidatore: "C'è un modo più figo per confondere il problema, è a cento metri".

Come dimostra la mia esperienza, tali "problemi complicati" sono molto più facili da capire rispetto agli EA "senza problemi" fatti copiando da un unico modello con tutte le variabili globali.


Georges, ho incontrato recentemente una mia vecchia amica, è una contabile e sta cercando di padroneggiare la 1C. Nel 2007 stava cercando di capire il suo foraggio ed è allora che ho scoperto MQL4.

Ho dato un'occhiata a quella 1C e mi ha fatto sentire male ))

 
Реter Konow:

Due anni di lavoro ininterrotto.

Il nucleo dell'interfaccia grafica (a proposito, c'è anche un proto-core che contiene elementi prototipali. Occupa 2 megabyte. Consiste in tabelle come quella che ho citato e contiene migliaia di variabili. Pensi che se non avessi usato il kernel come un centro e non avessi sparso le variabili su classi e strutture e non avessi impostato la comunicazione tra di esse attraverso varie restrizioni di accesso, sarei riuscito a far fronte al mio compito? - Mai da solo. Avrei moltiplicato il numero di entità nel mio programma. I collegamenti all'interno del codice tra funzioni e classi diventerebbero così complessi che semplicemente non sarei in grado di continuare a lavorare da solo. L'efficienza dell'intero meccanismo sarebbe crollata.

Avrei raggiunto il mio limite molto prima e mi sarei fermato.

Molte volte mi sono posto la domanda - "cosa avrei ottenuto se avessi usato OOP?" e ogni volta, sulla base della pratica quotidiana, mi sono reso conto che non avrei potuto arrivare a tanto da solo.

Inoltre, il mio pensiero è già strutturato e quindi non ho bisogno di OOP a questo proposito.


Ho una libreria di controlli grafici nei miei articoli (naturalmente ha anche dei difetti) - è stato fatto in una quindicina di giorni, e due settimane per scrivere l'articolo. Qualche anno dopo l'ho usato per scrivere un altro articolo - tutto mi è venuto in mente quasi istantaneamente guardando l'elenco a discesa dei metodi, senza guardare l'articolo o il codice.

 
Dmitry Fedoseev:

Ho una libreria di controlli grafici nei miei articoli (ovviamente ha anche dei difetti) - è stata fatta in una quindicina di giorni, e due settimane per scrivere l'articolo. Qualche anno dopo l'ho usato per scrivere un altro articolo - tutto mi è venuto in mente quasi istantaneamente guardando l'elenco a discesa dei metodi, senza guardare l'articolo o il codice.

Non voglio sminuire il tuo lavoro o il mio, ma stai paragonando un elefante e un'oca. La scala è diversa. Il livello di complessità è diverso. Non ho solo una serie di controlli. È un intero ambiente grafico, che potete costruire con il vostro linguaggio di markup. Ed è disegnato, non basato su oggetti.
 
Реter Konow:
Non voglio sminuire il tuo lavoro o il mio, ma stai paragonando un elefante e una talpa. La scala è diversa. Il livello di complessità è diverso. Non ho solo una serie di controlli. È un intero ambiente grafico, che potete costruire con il vostro linguaggio di markup. Ed è disegnato, non basato su oggetti.

Tuttavia, non è un lavoro di due anni. La quantità di lavoro è paragonabile all'utilizzo di oggetti grafici, ma naturalmente con il giusto approccio. Ma per passarci due anni... Scusa, spostati.

Aggiungiamo la creazione di canvas, ma è in una classe padre, facciamo un metodo per disegnare un rettangolo e un paio di metodi per disegnare le forme geometriche più semplici. Tutto il resto è esattamente lo stesso.

E il fatto che voi tutti vogliate derogare al mio lavoro mi è chiaro da tempo, quindi non c'è bisogno di preamboli. Questa biblioteca qui è come una roccia di discordia, che porta la folla all'isteria di massa.

 
Dmitry Fedoseev:

Tuttavia, non è un lavoro di due anni. La quantità di lavoro è paragonabile all'utilizzo di oggetti grafici, ma naturalmente con il giusto approccio. Ma per passarci due anni... Scusa, spostati.

E il fatto che tutti voi vogliate umiliare il mio lavoro - l'ho capito da tempo, quindi non c'è bisogno di preamboli. Questa biblioteca qui è come una roccia di discordia, che porta la folla all'isteria di massa.

Umiliare le persone senza motivo non è nella mia natura. Non fare il permaloso, semplicemente non capisci. Probabilmente non riesco a spiegarlo. Quindi, pensa a te stesso come al "serpente gorynych").
 
Реter Konow:
Umiliare le persone senza motivo non è nella mia natura. Non essere così duro con te stesso, è solo che non capisci. Probabilmente non sarò in grado di spiegare. Quindi, pensa a te stesso come al "serpente gorynych").

Pensa per te, ma io non scrivo per due anni quello che si può fare in un mese.

 
Dmitry Fedoseev:

Pensa per te, ma io non scrivo per due anni quello che si può fare in un mese.

Allora fallo, qual è il problema?
 
Реter Konow:
Allora fallo, qual è il problema?
Non ne ho bisogno.
 
George Merts:


SanSanych suggerisce di sostituire l'OOP con la documentazione.

Sei tu che l'hai inventato - non lo sto suggerendo io.

Dal mio studio.

  • Il ToR è un documento di ben oltre 400 pagine. Il ToR è rivisto e approvato
  • Poi il progetto tecnico. Questo documento è stato preparato da 40-50 persone. Per professione, erano: economisti di diverse specialità, matematici, creatori di algoritmi, sysadmin nella terminologia corrente, ingegneri elettronici.
  • Poi la bozza di lavoro. È qui che appare la ripartizione dei programmi e delle funzioni. La codifica effettiva e il debug sono fatti. La documentazione viene creata: per lo sviluppatore, per i diversi utenti della CPU, per i diversi utenti dell'applicazione (management, middle management, dispatcher...).
  • Inoltre c'è un'operazione di prova. L'indicatore principale è il tempo medio tra i guasti. Se tutto è fatto correttamente, documentato, il principio della codifica primitiva è preso in considerazione, il tempo tra i fallimenti dopo la prossima cattura di errori dovrebbe diminuire esponenzialmente. Se è lineare, molto probabilmente non funzionerà MAI.

Dov'è l'OOP qui? OOP è qualche requisito aziendale durante lo sviluppo. E ha poco effetto sul risultato finale, ma può essere molto utile (così mi sembra), se si trova una persona e sviluppa tutte le classi per l'intero progetto, non confonderà nulla, le classi saranno naturali dall'obiettivo finale del progetto....

 
Per favore non deviate dall'argomento del thread.