Designspørgsmål vedrørende (sub)klasser og objekter

[Bertel Lund Hansen]

Hej alle

Jeg har et teoretisk problem. Jeg har nemlig lavet et lille
program, og jeg har fundet en måde at gøre det på. Men jeg blev
interesseret i designprincipperne ved organisering af klasser.

Programmet skal give et overblik over ens portefølje som omfatter
aktier og investeringsforeninger (og kan selvfølgelig udvides til
andre papirer).

I min første version lavede jeg en klasse, Paper, med en
konstruktør hvor navn, købsdato, antal, pris og papirtype angives
ved kaldet, og som aflæser dagskurs og laver et par beregninger.
Det betød at der var flere objekter for samme aktie hvis
der var købt flere portioner på forskellige tidspunkter.

1.
Derefter tænkte jeg på at lave en grundklasse, Paper, og oprette
subklasser af den til hver aktie hvor konstruktoren så aflæser
dagskursen. Så kan der laves objekter af subklassen for hvert
køb, og de nødvendige beregninger laves i konstruktoren.

2.
Man kunne også give klassen Paper en konstruktor der kan kaldes i
en løkke der opretter objekter for hver aktie. Deres konstruktor
kan så aflæse dagskursen og lave beregningerne.

Ved 1. er det nemt at lave objekter som arver fællesdata, men
hvis man nu køber 200 forskellige slags papirer, bliver det et
monsterkodearbejde.

Ved 2. kan jeg ikke lige se hvordan man får overført fællesdata
til de endelige objekter (men jeg har måske glemt for meget om
klasser?), men ellers kan arbejdet jo lægges i en løkke så der
ikke skal kodes andet end lidt grunddata (navn, købsdato, og
købskurs) når nye papirer skal oprettes (og det kan lægges i en
inifil).

Hvordan skal opgaven designes?

PS. Spørgsmålet har jeg sendt før, men da der er knas med
news.stofanet.dk, sender jeg det igen via Dotsrc.

[Jacob Sparre Andersen]

Post by Bertel Lund Hansen
1.
Derefter tænkte jeg på at lave en grundklasse, Paper, og oprette
subklasser af den til hver aktie hvor konstruktoren så aflæser
dagskursen. Så kan der laves objekter af subklassen for hvert
køb, og de nødvendige beregninger laves i konstruktoren.
2.
Man kunne også give klassen Paper en konstruktor der kan kaldes i
en løkke der opretter objekter for hver aktie. Deres konstruktor
kan så aflæse dagskursen og lave beregningerne.

Generelt bruger man forskellige klasser når der er forskellige opførsler
der skal modelleres. Hvis man vil følge den tankegang, er det helt
klart løsning to der er at foretrække.

I virkeligheden tror jeg jeg ville ende med et design med fire klasser.
En klasse til at repræsentere generelle stamdata for et vilkårligt
værdipapir. En anden klasse, nedstammende fra den første, der
repræsenterer aktiespecifikke stamdata. En tredje klasse der
repræsenterer investeringsforeningsspecifikke stamdata (jeg er lidt
usikker på om den bør nedstamme fra værdipapirer eller aktier). Og
endelig en klasse der kan repræsentere en beholdning af et værdipapir,
der har en reference til et objekt i klassen værdipapir, som holder styr
på hvilket værdipapir det drejer sig om.

God fornøjelse,

Jacob

[Bertel Lund Hansen]

Post by Jacob Sparre Andersen
I virkeligheden tror jeg jeg ville ende med et design med fire klasser.

Tak for svaret. Jeg kikker på det.