Il linguaggio di programmazione Delphi
 

Ancora OO ?

Stark 8 Mar 2017 20:43
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 ******* 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
Delta11 9 Mar 2017 00:46
On 03/08/2017 08:43 PM, Stark wrote:
> 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 ******* sia più opportuno lavorare come
> attualmente con query sql.
>
> Come la vedete e cosa mi suggerite ? Grazie in anticipo..
>

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!!!
4ndre4 9 Mar 2017 08:17
On Wednesday, 8 March 2017 19:43:45 UTC, Stark wrote:

[...]
> 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 ******* sia piů opportuno lavorare come attualmente
> 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..
Delta11 9 Mar 2017 08:22
On 03/09/2017 08:17 AM, 4ndre4 wrote:
> 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.. *******

--
Ripristinare il trattato di Vienna è imperativo!
W IL LOMBARDO-VENETO.
W LA LIBERTA'.
ONORE E GLORIA A S.M. CARLO D'ASBURGO-LORENA!!!
Stark 9 Mar 2017 10:13
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
Stark 9 Mar 2017 10:19
"4ndre4" ha scritto nel messaggio
news:c239b834-0a15-4d3c-b446-7a7caa62e1da@googlegroups.com...

On Wednesday, 8 March 2017 19:43:45 UTC, Stark wrote:

[...]
> 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 ******* sia piů opportuno lavorare come attualmente
> 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..
--
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
4ndre4 9 Mar 2017 11:53
On Thursday, 9 March 2017 09:13:49 UTC, Stark wrote:

[...]
Lascia perdere quel ******* di Delta11, e` un troll che da tempo infesta questo
e altri ng.

>Se TTitolo ha un attributo Costo dell'investimento, non
dovrei realizzare una qualche classe che ha questo attributo calcolato come
somma ?

Non puoi chiedere consigli "a ******* senza specificare quale requisito stai
cercando di implementare nella tua applicazione. Specifica qual e` il tuo
obiettivo finale. Le risposte possibili alla tua domanda possono essere
centinaia, e tutte valide.

>"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.
Stark 9 Mar 2017 21:31
"4ndre4" ha scritto nel messaggio
news:5dfb2605-d28b-45a8-a8fb-055d60acc3b7@googlegroups.com...

Non puoi chiedere consigli "a ******* senza specificare quale requisito stai
cercando di implementare nella tua applicazione. Specifica qual e` il tuo
obiettivo finale. Le risposte possibili alla tua domanda possono essere
centinaia, e tutte valide.

>"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.
--
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 ...




---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
Delta11 10 Mar 2017 01:16
On 03/09/2017 10:13 AM, Stark wrote:
> 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 ?
>

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 ******* 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.

--
Ripristinare il trattato di Vienna è imperativo!
W IL LOMBARDO-VENETO.
W LA LIBERTA'.
ONORE E GLORIA A S.M. CARLO D'ASBURGO-LORENA!!!
Delta11 10 Mar 2017 01:43
>>
>
> 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 ******* 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.
>

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.




--
Ripristinare il trattato di Vienna è imperativo!
W IL LOMBARDO-VENETO.
W LA LIBERTA'.
ONORE E GLORIA A S.M. CARLO D'ASBURGO-LORENA!!!
Morde 10 Mar 2017 11:50
On 09.03.2017 21:31, Stark wrote:
>
> 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.

Ed è giusto così, se la parte di *****isi è implementata sul DB,
mantienila là.

> 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 ?

Lui creerebbe degli oggetti che su una collezione di titoli facciano le
aggregazioni dovute. Es. un oggetto T*****isi al quale aggiungere titoli
e che espone dei getValore, getRendimento, filterByType,
filterByManager. Tutto in memoria senza SQL.

Se hai già tutto su DB, continua così: a che pro dovresti duplicare le
logiche per portarle da SQL a istruzioni per calcolare in memoria?
Faresti un lavoro di porting, che costa tempo e ti costringerebbe a
rivalidare tutti i calcoli.

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.

O la mia soluzione tutto sommato non contrasta
> necessariamente con quell'ottica ?

No non contrasta: poichè stai cambiando il design del tuo applicativo,
mantieni SQL e oggetti separati.

--
Morde
Stark 10 Mar 2017 16:30
Lui creerebbe degli oggetti che su una collezione di titoli facciano le
aggregazioni dovute. Es. un oggetto T*****isi al quale aggiungere titoli
e che espone dei getValore, getRendimento, filterByType,
filterByManager. Tutto in memoria senza SQL.

Se hai già tutto su DB, continua così: a che pro dovresti duplicare le
logiche per portarle da SQL a istruzioni per calcolare in memoria?
Faresti un lavoro di porting, che costa tempo e ti costringerebbe a
rivalidare tutti i calcoli.

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.

O la mia soluzione tutto sommato non contrasta
> 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.


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
Stark 10 Mar 2017 16:38
"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ò..


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
4ndre4 10 Mar 2017 19:50
On Thursday, 9 March 2017 20:31:42 UTC, Stark wrote:

[...]
> 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 ?

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
4ndre4 10 Mar 2017 20:34
On Friday, 10 March 2017 15:38:14 UTC, Stark wrote:

[...]
> 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ò..

Lascia perdere i "consigli" che ti da` quell'imbecille. E` un troll che, oltre a
non capire un ******* di OOP, non capisce un ******* 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.
4ndre4 11 Mar 2017 09:19
>Lui creerebbe degli oggetti che su una collezione di titoli facciano le
aggregazioni dovute. Es. un oggetto T*****isi 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.
4ndre4 11 Mar 2017 09:22
>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.
Stark 11 Mar 2017 15:35
"4ndre4" ha scritto nel messaggio
news:504e0288-4a77-4949-a66e-7866d5313565@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.


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus
Enrico Bianchi 14 Mar 2017 15:19
On 2017-03-11, 4ndre4 <a.laforgia@gmail.com> wrote:

> Il problema del codice SQL su db è che tende a diventare una montagna di
> spaghetti code procedurale e non testabile.

Son d'accordo ma non sono d'accordo ;)
In effetti tende a diventare un ******* 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
andrea.laforgia.work@gmail.com 14 Mar 2017 15:54
On Tuesday, March 14, 2017 at 2:19:24 PM UTC, Enrico Bianchi wrote:

[...]
> con un po' di metodo

Il problema e` che il metodo che serve per poter fare le cose per bene con SQL
e` molto maggiore di quello che serve con altri sistemi. Il problema e` sempre
quanto e` facile fare certe cose, non se si possano fare.

> si riesce a tirare fuori qualcosa di manutenibile.

In bocca al lupo.

>Per il discorso del test, molto dipende dal tipo di test.

Se e` unit test, non esiste un "tipo".

>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.
Delta11 14 Mar 2017 18:31
On 03/14/2017 03:54 PM, andrea.laforgia.work@gmail.com wrote:
> io sono riuscito a fare test unitari su codice PL/SQL abbastanza
semplicemente.

TU non sai nemmeno cosa sia il PL/SQL.. *******
--
Ripristinare il trattato di Vienna è imperativo!
W IL LOMBARDO-VENETO.
W LA LIBERTA'.
ONORE E GLORIA A S.M. CARLO D'ASBURGO-LORENA!!!
andrea.laforgia.work@gmail.com 15 Mar 2017 11:34
On Tuesday, March 14, 2017 at 2:54:59 PM UTC, andrea.laf...@gmail.com wrote:

[...]
> 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

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio di programmazione Delphi | Tutti i gruppi | it.comp.lang.delphi | Notizie e discussioni delphi | Delphi Mobile | Servizio di consultazione news.