Interessante presa di posizione sull'OLP - pagina 5
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
Se la domanda è al mio esempio - almeno nascondi l'implementazione (la nascondi anche a te stesso) - cioè scrivi solo la logica dei calcoli, è conveniente, è leggibile, ti permette di evitare errori logici
SZZY: Per quanto riguarda il trading - ho scritto e faccio ancora esperimenti con griglie di ordini, dove scrivo la logica di immissione degli ordini come A + B - C, dove A, B, e C - cioè ordini con parametri predefiniti, molto utile per gli algoritmi genetici- argomento interessante
I wrapper sono una soluzione buona e logica. Quando è adatto allo scopo. E penso che i wrapper siano un'innovazione nel linguaggio procedurale. Esattamente nel senso di novità e utilità.
Per quanto riguarda il trading - ho scritto e continuo a fare esperimenti con griglie di ordini dove scrivo la logica del posizionamento degli ordini come A + B - C, dove A, B e C sono ordini con parametri predefiniti - è molto utile per gli algoritmi genetici- è un argomento interessante
A, B e C con parametri predefiniti- come fenotipo per gli algoritmi genetici?
L'incapsulamento dà libertà di nomi. E se questo problema è risolto dalla logica dei nomi. Questo naturalmente è costoso. allora python può essere scritto in funzioni. ma non sarà una soluzione commerciabile. MA È POSSIBILE.
In python, ogni funzione è un oggetto, proprio come una variabile)
A proposito, un esempio di OOP continuo è Python. Lì, piuttosto, nessuno sa che esiste qualcosa di diverso da OOP.
ci sono le chiusure e si può scrivere senza OOP, almeno nella vecchia, come si vuole.
in python, qualsiasi funzione, come una variabile, è un oggetto)
Tutto quello che si può fare è usare i riferimenti per risolvere tutto, a patto che i nomi non si sovrappongano. Una funzione è naturalmente un oggetto, ma il suo risultato è unificato internamente, e solo in globale e pubblico si può guardare dentro. mi piace la logica di python)))
ci sono le chiusure ed è possibile scrivere senza oop, nel vecchio almeno, come si vuole
Beh, si può, ma comunque il blocco minimo di costruzione è un oggetto
Non lo vedo da un po'...
È davvero andato sotto un altro nome di schermo?
No, non è Peter, è un diverso stile di scrittura.
l'OOP nettamente aziendale è Java. Nel nostro campo, Du* *opy è rappresentato (spruzzato per evitare di essere preso). Se volete la bellezza degli oggetti - cercate sobriamente di capire e ricordare le loro API, per fortuna il tema è noto :-)
Ma sono tutte stronzate...
Per aumentare la vostra abilità di programmazione, potreste voler imparare qualcosa di sconvolgente. Per esempio c'è Rebol/Red ( https://www.red-lang.org/)- roba piuttosto forte, non è facile da capire ma è forte.
o un classico, Smalltalk(https://pharo.org/). Qualcuno lo sta addirittura usando in produzione.
E tutto questo "scriviamo A+B in stili diversi" è un gioco da ragazzi, onestamente.
E allora tutte le domande su chi è più figo, OOP o FP, spariranno da sole.
Beh, si può, ma ancora il blocco minimo di costruzione è la struttura
l'oggetto era una svolta.
Dove OOP è più conveniente, uso OOP, dove ho bisogno di risparmiare memoria e tempo, e codice per me stesso, rimango con la procedura. Mi sono appena imbattuto in un articolo, volevo ascoltare le opinioni, dove/cosa è meglio). Risultato - ho sentito un sacco di cose diverse nel mio indirizzo, non sulla programmazione) Tutto come al solito.
Quindi nessuno vi dirà niente di nuovo. Usate quello con cui vi sentite a vostro agio, tutto qui.
Per minimizzare gli errori, c'è tutta un'area chiamata programmazione probatoria (la verifica formale in particolare).
Come misura parziale per migliorare la qualità del codice, si può suggerire di seguire uno stile di codifica comune (ad esempio google codestyle), usare le asserzioni, i vincoli (const, override, specificatori di accesso) che di fatto non influenzano l'esecuzione ma causano errori di compilazione se usati in modo scorretto, acquisire familiarità con gli approcci nella progettazione in generale
Il fatto è che, a parte le aree critiche di programmazione, è generalmente più importante far uscire rapidamente la versione di produzione che ottenere la qualità del codice, che è brutto ma vero