OOP vs programmazione procedurale - pagina 40
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
Esattamente, da una persona specifica. Perché un programmatore che non soffre di schizofrenia dovrebbe nascondere strenuamente a se stesso l'accesso a una parte del proprio codice che sta debuggando? Non preferiresti legarti le mani da solo? :)
Bene, come ho detto, provate a lavorare con il file di struttura che Peter ha dato sopra. "Recupera" i dati che ti servono da lì, e poi li rimette al posto giusto.
E confrontalo con l'ottenere i dati di cui hai bisogno da un'interfaccia "tagliata" che ti dà una piccola parte della stessa struttura. Con un'interfaccia, semplicemente non c'è modo di ottenere qualcos'altro, o di scrivere qualcosa di "sbagliato".
No, è comprensibile che se sei un titano della memoria con una capacità di dimenticare atrofizzata - allora sei fortunato, e non hai bisogno di OOP. Ma non tutti sono così fortunati.
SanSanych propone di sostituire OOP con la documentazione - in linea di principio, è anche un'opzione, infatti, è molto più vicino alle strutture proposte da Peter. Ma con Peter tutta la documentazione è "in mente" e con SanSanych - su carta (o su supporti elettronici).
Mi chiedo cosa sia questo "orrore".
A proposito, Renat Fatkhullin, sarebbe davvero interessante guardare degli esempi...
No, è comprensibile che se sei un titano della memorizzazione con una capacità atrofizzata di dimenticare, allora sei fortunato e non hai bisogno di OOP. Ma non tutti sono così fortunati.
Così, SanSanych suggerisce di sostituire l'OOP con la documentazione, che è anche un'opzione, in linea di principio, molto più vicina alle strutture proposte da Peter. Ma la documentazione di Peter è tutta "a mente", mentre quella di SanSanych è su carta (o su un supporto elettronico).
Il significato di una variabile deve essere conosciuto in ogni caso, ma non è necessario ricordarlo - si può scrivere un commento se il contesto non è chiaro. Sembra ovvio.
Con OOP si deve ricordare e documentare molto di più, vale a dire, ciò che viene creato e distrutto quando e in quale momento, attraverso quali interfacce scorre in quale momento e altri pasticci assolutamente inutili per il risultato finale del mouse - solo da questo qualsiasi persona sana di mente può impazzire e rompersi il cervello.
A proposito, a tutti gli oppositori dell'OOP - sarebbe bene ricordare i tempi in cui i programmi erano scritti in linguaggio assembly.
E in particolare - lavorare con i file usando BIOS e DOS.
Secondo me, la differenza tra approcci procedurali e OOP è proprio la stessa che c'è nella gestione del disco con strumenti BIOS e DOS.
Sia il BIOS che il DOS hanno tutte le funzioni necessarie per lavorare con il disco.
Tuttavia, creare un file con le caratteristiche del BIOS e scriverci "Hello, world !" è un problema abbastanza grande anche per le unità FAT. Lo facevo per scommessa e non era facile per me. In DOS è facile farlo con una sola funzione.
Posso immaginare quanto sarebbe difficile creare un tale file per un sistema NTFS usando il BIOS...
Leggete attentamente, si tratta della classe, non del costruttore della classe.
Inoltre, suggerisci di nuovo di fare un lavoro da scimmia - piantare un campo su una trama, se possiamo avere accesso ai parametri senza fare NULLA in caso di variabili esterne o passandole direttamente, senza inutili mal di testa con costruttori-distruttori e tutti i memory leak che ne derivano.
Sì, ho bisogno di entrare e tu mi stai mostrando la porta qui. Probabilmente non sapete cos'è un costruttore di classe.
Solo i parametri generali - sono già visibili all'interno della classe, ma usarli non è buono, OOP è buono per la capacità di fuggire dallo spazio comune.
E direttamente come? Se non attraverso una porta, allora un muro? Attraverso il costruttore è proprio come passare direttamente. Si possono passare parametri immediatamente quando si crea un oggetto, anche senza new. Quindi sei troppo pigro per descrivere i parametri che la classe deve accettare? Non sei troppo pigro per scrivere funzioni e dichiarare variabili?
Evidentemente non hai capito niente di quello che ho scritto)).
Dmitry Fedoseev:
Non sei troppo pigro per scrivere funzioni e dichiarare variabili?
Bisogna scrivere funzioni e dichiarare variabili ovunque e anche in OOP. Solo con l'OOP ci sarà molto più casino, e questo se si prevede in anticipo tutto profeticamente, quale sarà la struttura dei dati alla fine del progetto, in modo da non doverla riscrivere cento volte. Sembra ovvio.
Bisogna scrivere funzioni e dichiarare variabili ovunque e anche in OOP. Solo in OOP sarà molto più pignolo, e questo se si prevede in anticipo tutto profeticamente, quale struttura di dati ci sarà alla fine del progetto, in modo da non doverla riscrivere cento volte. Sembra ovvio.
È più di una seccatura, ma ci sono molti casi in cui ne vale la pena. In generale, non è fatale.
È più di una seccatura, ma ci sono molti casi in cui ne vale la pena. Non è fatale in generale.
Da quanto tempo stai lavorando a questa tua libreria?
Due anni di lavoro ininterrotto.
Il kernel della GUI (a proposito, c'è anche un proto-kernel che contiene elementi prototipali. Occupa 2 megabyte. Consiste in tabelle come quella che ho citato e contiene migliaia di variabili. Pensate che se non avessi usato il kernel come centro e non avessi sparpagliato le variabili su classi e strutture e 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 chiesto "cosa avrei ottenuto se avessi usato OOP?" e ogni volta, sulla base della pratica quotidiana, mi sono reso conto che non sarei stato in grado di andare così lontano da solo.
Inoltre, il mio pensiero è strutturato così com'è e quindi non ho bisogno di OOP a questo proposito.
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 subito deciso di non integrarla. 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.
Renat, per favore non essere nervoso. Io stesso non sono un sostenitore della R. Sei un eccellente manager e programmatore, non prendere a cuore le grida del forum.
Auguro a te, a Rashid e alla tua squadra buona salute e successo creativo!