Newsgroup: it.comp.lang.delphi
Titolo: Ancora OO ?

Grazie ai vostri suggerimenti, sto modificando passo passo  in senso OO 
un'applicazione di gestione titoli.
Adesso lavoro con una classe TTitolo e con una Lista di oggetti TTitolo, che 
č una ObjectList che carico da dataset con una classe TListLoader.
 
La parte che mi rimane da affrontare tratta tutti i titoli determinando dei 
valori complessivi e sintetici di rendimento. Attualmente lo fa accedendo 
direttamente al dataset e estraendone dei summary che poi servono ai calcoli 
finanziari.
 
Mi chiedo se sarebbe opportuno costruire una classe dove la ObjectList 
potrebbe essere la fonte dei calcoli  o se invece nel caso di calcoli 
riassuntivi su un intero file sia piů opportuno lavorare come attualmente 
con query sql.
 
Come la vedete e cosa mi suggerite ? Grazie in anticipo..
 
 
 
 
---
Questa e-mail č stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 


 
inserisci il rendimento nel TTitolo quindi puoi fare una COLLECTION di 
TTitolo e ricavarne cosi il portafoglio(TPortafoglio) la sommatoria dei 
singoli rendimenti nel TTitolo ti danno il rendimento del 
portafoglio(TPortafoglio)
 
per TTitolo intendo non semplicemente azionario ma anche 
obbligazionario, materie prime, preziosi, etc. etc., al limite come 
titolo si potrebbe pensare anche ad altro portafoglio.
 
...se ho capito bene.
 
 
-- 
Ripristinare il trattato di Vienna è imperativo!
W IL LOMBARDO-VENETO.
W LA LIBERTA'.
ONORE E GLORIA A S.M. CARLO D'ASBURGO-LORENA!!!

 con query sql.
 
Dipende da quanti sono i titoli, in media, di cui stiamo parlando e dal tipo di calcoli che vuoi fare, da quante tabelle sono coinvolte, ecc..

 Dipende da quanti sono i titoli, in media, di cui stiamo parlando e dal tipo di calcoli che vuoi fare, da quante tabelle sono coinvolte, ecc..
 
ma vai a cagareeeeeeeeeee....espertone!
sei proprio un fasullo...cazzo!


inserisci il rendimento nel TTitolo quindi puoi fare una COLLECTION di
TTitolo e ricavarne cosi il portafoglio(TPortafoglio) la sommatoria dei
singoli rendimenti nel TTitolo ti danno il rendimento del
portafoglio(TPortafoglio)
 
per TTitolo intendo non semplicemente azionario ma anche
obbligazionario, materie prime, preziosi, etc. etc., al limite come
titolo si potrebbe pensare anche ad altro portafoglio.
...se ho capito bene.
---
Si, hai capito bene. In effetti lo chiamo TTitolo, ma include una qualsiasi 
forma di investimento. Ma quella che chiami una Collection di TTitolo 
potrebbe essere semplicemente la ObjectList che già utilizzo e che è fatta 
di oggetti TTitolo ?
 
Essemplificando, se TTitolo ha un attributo Costo dell'investimento, non 
dovrei realizzare una qualche classe che ha questo attributo calcolato come 
somma ? 
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

 
 
"4ndre4"  ha scritto nel messaggio 
news:c239b834-0a15-4d3c...@googlegroups.com...

--
Sto parlando di portafogli di qualche centinaio di titoli e le tabelle 
coinvolte sono sostanzialmente quella che rappresenta il portafoglio e 
quella che rappresenta i movimenti che quel portafoglio creano .. 
 
 
---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
 
 

"La parte che mi rimane da affrontare tratta tutti i titoli determinando dei valori complessivi e sintetici di rendimento."
 
Potresti avere una classe "sommario" che contiene quei dati, ma tutto dipende da cosa vuoi farci dopo. Per un centinaio di record, puoi fare tutto benissimo in memoria.
 

dei valori complessivi e sintetici di rendimento."
 
Potresti avere una classe "sommario" che contiene quei dati, ma tutto 
dipende da cosa vuoi farci dopo. Per un centinaio di record, puoi fare tutto
benissimo in memoria.
--
Mi pareva di avere esemplificato i requisiti. Comunque immagina che ogni 
titolo sia accompagnato da proprietà come costo
investimento, valore corrente, ricavi, durata, rendimento assoluto, 
rendimento annuo. Ora l'obiettivo è di calcolare questi valori a vari 
livelli di aggregazione (come tipi di investimento, società di gestione 
etc.).
 
Ora come ora, partendo da dati e calcoli eseguiti a livello singolo titolo e 
raccolti in un dataset di meno di mille records, faccio tutto con delle 
query sql i cui risultati mostro in forms appositi con DBEdits e DBGrid.
 
Lavorando con una base dati, mi viene naturale usare gli strumenti delle 
basi dati. Poichè non sono abituato a lavorare con l'OO mi è sorta una 
domanda: ma uno che ragiona in ottica OO, cosa farebbe con i dati elementari 
di cui sopra per conseguire gli stessi risultati che io ottengo con delle 
query ? O la mia soluzione tutto sommato non contrasta necessariamente con 
quell'ottica ?
 
Non chiedo delle soluzioni, ma dei ragionamenti su quanto sopra, magari dee 
su delle ipotesi di lavoro ...



 
dipende : se lavori su serie storica direi di no, se invece lavori su 
valori aggregati forse si ma non so dove questa strada ti porti.
 
I titoli di norma si trattano per serie storiche ovvero
titolo=fiat data=1/1/2017 qta=1000 pzo-ape=xxxx pzo-chiu=yyyy (per 
calcolo ottieni il rendimento giornaliero)
 
e cosi via per piu titoli che compongono il portafoglio fino al 
raggiungimento della quota iniziale dell'investimento.
 
A seguire , nel tempo, puoi avere un guadagno o una perdita a seconda 
dell'andamento del portafoglio.(un titolo perde un altro titolo guadagna)
 
SE ti risulta facile potresti avere una apertura contratto dove riporti 
la data apertura e l'importo totale dell'investimento richiesto, ma è 
solo indicativo in quanto non è detto che con il valore nominale dei 
titoli al momento dell'apertura contratto tu riesca a soddisfare 
l'intero ammontare richiesto. Es. hai 100 euro da investire mentre la 
sommatoria ad oggi dei titoli potrebbe essere 99 o 101, in ogni caso 
sull'informazione "contratto" dovrai riportare il valore richiesto 
all'apertura dello stesso e il valore reale del portafoglio che sei 
riuscito a comporre.
 
il resto vien da se.
 
Per quanto riguarda la objectlist di delfi non ricordo se possa essere 
vista come una collection ma io terrei comunque separata la parte logica 
(TCollection) dalla parte visualizzazione e una objectlist secondo me 
entra in gioco piu nella parte visualizzazione.
 
Questo aspetto dovresti valutarlo maggiormente tu in base a quello che 
vai a fare.



 
non l'ho specificato ma partendo dalla serie storica giornaliera puoi 
ricavare la serie storica mensile, trimestrale, semestrale, annuale
 
la struttura dei dati non cambia prendendo il primo prezzo di apertura 
del periodo e l'ultimo prezzo di chiusura del periodo.
 
certamente lo saprai ma te l'ho ricordato.


 necessariamente con quell'ottica ?
 
No non contrasta: poichè stai cambiando il design del tuo applicativo,
mantieni SQL e oggetti separati.
 
-- 
Morde

 necessariamente con quell'ottica ?
 
No non contrasta: poichè stai cambiando il design del tuo applicativo,
mantieni SQL e oggetti separati.
Morde
--
Grazie, è il tipo di ragionamenti che intendevo stimolare e (a parte che 
tiri un pò l'acqua al mio mulino) volevo proprio capire se l' approccio ad 
oggetti va sempre considerato preferibile, anche quando si lavora con basi 
di dati e in questo caso quali classi immaginare. Gli esempi che mi hai dato 
mi danno un'idea della strada alternativa che avrei, anche se per il momento 
come consigli lascerò le cose come sono. 


"Delta11"  ha scritto nel messaggio news:o9sr4h$4k9$1...@dont-email.me...
Descrivi più o meno la logica che utilizzo a livello di singolo titolo. A 
livello aggregato, con diversi tipi di aggregazione, adesso realizzo tutto 
con delle query e mi chiedevo se fosse preferibile un approccio meni legato 
alle basi dati e sfruttare i concetti OO. Non ne farò niente perchè non ho 
chiaro cosa dovrei fare..
Al di la di questo, la tua idea di 'contratto' come concetto a cui riferire 
il rendimento di portafogli valori mi sa che lo userò.. 


 query ? 
 
E a te cosa fa pensare che l'ottica OO sia in contrasto con una base dati e le query? Si scrive software OO che si interfaccia con base dati tutto il tempo. Io credo che tu sia esperto nel complicarti la vita. Se conosci i db e li sai usare, continua pure ad usare SQL ed eseguire query per raggruppare ed aggregare i dati che ti servono. Se proprio ci tieni ad approfondire come usare i dati in un'ottica OO, comincia da qui:
 
https://martinfowler.com/eaaCatalog/dataTransferObject.html
 
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
 
https://en.wikipedia.org/wiki/Object-relational_mapping
 

 il rendimento di portafogli valori mi sa che lo userò.. 
 
Lascia perdere i "consigli" che ti da` quell'imbecille. E` un troll che, oltre a non capire un cazzo di OOP, non capisce un cazzo di informatica. Ha scritto due righe di codice in COBOL un millennio fa, si crede Alan Turing, e infesta praticamente ogni ng con le sue stronzate.
 
Un portafoglio titoli non ha necessariamente legame con un contratto. Devi mappare il concetto di contratto nella tua applicazione solo se ne hai effettivamente bisogno, altrimenti non ha alcun senso.
 

>Lui creerebbe degli oggetti che su una collezione di titoli facciano le 
aggregazioni dovute. Es. un oggetto TAnalisi al quale aggiungere titoli 
e che espone dei getValore, getRendimento, filterByType, 
filterByManager. Tutto in memoria senza SQL
 
Ma non deve essere necessariamente tutto in memoria. Se usi un layer di persistenza come Hibernate, per esempio, i dati risiedono su db e usi SQL per fare le tue operazioni. 

>Inoltre ti sconsiglio di usare oggetti che eseguono loro stessi SQL di 
calcoli: meglo mantenere separate le due cose. Del resto, lato DB le 
stored procedure e le viste, sono là apposta per questi scopi. 
 
Il problema del codice SQL su db è che tende a diventare una montagna di spaghetti code procedurale e non testabile. È essenziale che TUTTO il codice in un sistema sia testabile, stored procedures comprese. Oltretutto quel codice dovrebbe essere versionato come tutto il resto. Tutto ciò complica molto la vita ma si può fare.

"4ndre4"  ha scritto nel messaggio 
news:504e0288-4a77-4949...@googlegroups.com...
https://martinfowler.com/eaaCatalog/dataTransferObject.html
 
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html
 
https://en.wikipedia.org/wiki/Object-relational_mapping
 
--
Interessantissimi.. ho letto un pò, ma bisogna studiare. 


 spaghetti code procedurale e non testabile.
 
Son d'accordo ma non sono d'accordo ;)
In effetti tende a diventare un casino perché si tende a modificare le stored
procedure inline, o perché spesso le query SQL tendono ad essere scritte nel
codice che andiamo a sviluppare nell'applicazione, ma con un po' di metodo
si riesce a tirare fuori qualcosa di manutenibile. Per il discorso del test,
molto dipende dal tipo di test. In teoria puoi testare la funzione,
difficilmente puoi fare test unitari
 
Enrico

In teoria puoi testare la funzione, difficilmente puoi fare test unitari
 
Non e` vero, io sono riuscito a fare test unitari su codice PL/SQL abbastanza semplicemente.
 

 io sono riuscito a fare test unitari su codice PL/SQL abbastanza semplicemente.
 
TU non sai nemmeno cosa sia il PL/SQL...idiota


 Non e` vero, io sono riuscito a fare test unitari su codice PL/SQL abbastanza semplicemente.
 
Tanto per dare qualche riferimento, in caso qualcuno sia interessato:
 
https://docs.oracle.com/cd/E15846_01/doc.21/e15222/unit_testing.htm#RPTUG45000