Interessante presa di posizione sull'OLP
Questo non è un problema di OOP, ma della sua applicazione, e ancora di più di coloro che la applicano. Sono quelli che si sentono...
entusiasmo, persino l'estasi che con l'aiuto di OOP si può scrivere incredibilmente
codice incredibilmente complicato (e anche competere in esso :). Si sentono un'élite speciale.
Hanno anche inventato il loro "grande libro" che hanno letto e letto e letto ma non possono
ma non possono leggerlo. Si chiama "Design Patterns" - in linguaggio umano
si traduce come "The Ultimate Art of Writing Fuzzy, Muzzy and Confusing Code". Se, tuttavia.
È una cosa molto, molto bella, incredibilmente semplificante e
semplifica e semplifica la vita.
Ecco, sempre sospettato)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Dovresti capire che tali articoli sono molto probabilmente scritti da persone che non hanno familiarità con la FP e i suoi ganci confusi, che possono includere 20 tabs....
Hard FP è un'altra cosa. Poi si comincia a pensare al laconismo e alla convenienza dell'OOP, si può dichiarare alcune delle funzionalità in anticipo e così via..... In sostanza, la somiglianza dell'uno con l'altro. Questo è solo che tali articoli sono spesso scritti da persone che hanno padroneggiato solo il codice procedurale - e questo non è nemmeno vicino al FP, quindi se non sapete cosa sono gli hooks e l'uso vivido di esso, nessun FP è fuori questione
Inoltre molti dei "linguaggi morenti" elencati nell'articolo supportano la piena funzionalità di FP e OOP, perché dovrebbero morire? E un paio di loro sono i più pagatinel CISSi tratta piuttosto di "spaghettificare" in OOP, senza alcun pensiero di "annegare" in FP. Secondo me, il paradigma procedurale è realistico e più efficiente in termini di risorse di OOP.
solo che il codice stesso è più lungo su oop? beh, sì, c'è un costruttore e in alcuni casi il codice è solitamente più lungo su di esso.... tecnicamente, la distribuzione FP dovrebbe essere più efficiente per la generazione di codice macchina.... ma il codice non diventa più semplice ed è impossibile fare dei wrapper normali per quanto riguarda la digitazione...
in questi giorni, si può spesso trovare una miscela di uno e l'altro - i modi non interferiscono l'uno con l'altro
solo che il codice stesso è più lungo su oop? beh, sì, c'è un costruttore e in alcuni casi il codice è solitamente più lungo su di esso.... tecnicamente, la distribuzione FP dovrebbe essere più efficiente per la generazione di codice macchina.... ma il codice non diventa più semplice ed è impossibile fare dei wrapper normali per quanto riguarda la digitazione...
Al giorno d'oggi, è spesso possibile vedere un misto dell'uno e dell'altro.
Senza OOP e FP tutto funziona più facilmente e più velocemente (sì, senza "bellezze", pannelli ecc.), ma a volte è difficile capire anche il proprio codice)
Senza OOP e FP, tutto funziona più facilmente e più velocemente (sì, senza "bellezze", pannelli, ecc.), ma a volte è difficile capire anche il proprio codice).
Prima padroneggiate l'uno o l'altro, o meglio entrambi, e poi decidete cosa preferite. E con un approccio come quello di adesso, col tempo ti trasformerai in Fedoseev che è d'accordo con tutto quello che non capisci (cioè quasi tutto).
Che reazione distruttiva all'argomento e che discussione distruttiva. Mi dica un seguace della programmazione procedurale come evitare la "spaghettizzazione" in OOP, come analizzare e se ha senso usare gli "spaghetti" di qualcun altro?
Dopo tutto, quello che si scopre, OOP è soprattutto per la leggibilità e la programmazione di gruppo, cioè per i grandi progetti. Un Expert Advisor che commercia un simbolo al suo grafico con il controllo del rischio massimo del saldo / fondi nel conto, beh, non può essere chiamato un grande progetto - è sufficiente e più redditizio in memoria / velocità - programmazione procedurale.
Domande:
- svantaggi/svantaggi di OOP (come imperativo) per esperienza personale
- svantaggi/svantaggi della FP (in quanto dichiarativa) per esperienza personale.
E un'opinione sulle prospettive è ovviamente interessante, soprattutto nella direzione del calcolo parallelo. Non vedo il motivo di toccare l'argomento quantistico.
Dimmi, come programmatore procedurale, come evitare la "spaghettizzazione" in OOP
La ricetta è data nell'articolo citato: sforzatevi di scrivere funzioni deterministiche.
Come smontare e ha senso usare gli "spaghetti" di qualcun altro?
Buon codice, sì, ma non spaghetti.
Dopo tutto cosa si ottiene, OOP è principalmente per la leggibilità e la programmazione di gruppo, cioè per i grandi progetti.
Giusto.
Un EA che commercia un simbolo su un grafico di cui è attaccato con il massimo controllo del rischio dei fondi del saldo/conto, beh, non può essere chiamato un grande progetto - quindi la programmazione procedurale è sufficiente e più redditizia in termini di memoria/velocità.
Per viaggiare in Australia, è più conveniente usare un aereo (OOP), per viaggiare in una città vicina, una macchina o anche una bicicletta è sufficiente (PP). Devi solo scegliere il mezzo più conveniente per 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
Ecco, sempre sospettato)
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23