Design patter, strukturering af objekter
Hejsa,Jeg skal til og i gang med endnu et lille program, denne gang et spil. Men der er en ting jeg gerne vil have på plads inden jeg starter, hvilket omhandler strukturen i applikationer.
Typisk har alle min små programmer indeholdt objekter som 'brugere', 'produkter', 'ordre', 'lager' osv. Men jeg har aldrig været 100% tilfreds med strukturen. Så denne gang har jeg sat mig for, at bikset en god/solid model sammen, som jeg kan genbruge eller delvis genbruge fra projekt til projekt.
Et af disse strukturelle problemer som altid har irriteret mig er hvordan jeg skal lagre objekter. F.eks. ’brugere’. Det siger sig selv at man skal bruge en klasse af typen ’bruger’, men efter at have læst brugeren in fra en db eller fil, hvor skal det objekt så lagers? . Her er et par eksempler hvordan jeg løst eller tænkt på at løse det og hvad jeg syntes om det.
1) Lave en kontroller klasse som f.eks. gemmer alle brugere, produkter og ordre i hver sin datastruktur (linked list, trees, arryas osv.). Det fungere selvfølgelig, men syntes det er utrolig rodet. Kontroller objektet kommer til at flyde med metoder beregnet til at operere på de forskellige data objekter.
2) Lave en container klasse for enten hvert objekt type eller bare en til alle sammen. Her flytter vi bare data objekterne ud fra kontroller objektet og der derved virker det ikke så rodet som da det hele lå en kontroller objektet. Men dette virker også lidt gak, gak da man så skal til lave en container klasse for hver, data objekt type, der så kan indeholde data objekterne. Kunne som sagt nøjes med en ’container klasse’ som indeholder alle data objekterne, men igen, der er noget der irritere mig ved denne løsning. Syntes ikke den er pæn.
Et andet problem der har irriteret mig er adgang til objekter, problemet hænger sådan set sammen med ovenstående problem. Et eksempel.
Når man i første omgang sidder om moduler sine diagrammer virker det indlysende, at et ’ordre’ objekt skal indeholde en kvittering, altså ’kvittering’ objektet. Fint nok, det er jo også ganske praktisk når man har hentet en ordre ud og vil se hvad der står på kvitteringen. Kvitteringen lagres jo i ’ordre’ objektet og derfor ligt til at hente. Men, hvad nu hvis vi ikke er interesseret i at se nogen ordre men bare bladre igennem alle kvitteringer? . Ja så er vi tilbage ved mit første problem, hvor man på en eller anden måde skal have læst alle kvitteringer ud hvilket vil sige at man i praktisk skal hen og lave specielle klasser eller metoder for hvert enkelt objekt som man kunne tænke sig at se på som gruppe.
Jeg er så begyndt at studere de her design patterns og luret lidt composite pattern. Jeg har lavet et lille diagram over hvordan man evt. kunne bruge dette pattern til ovenstående problem. I kan se diagrammet her www.onk.dk/temp/composite.jpg
Hvis tager udgangs punkt i mit diagram og jeg vil hente en ordre ud skal jeg vel bare have implementeret en metode i ’produkter’(composite) objektet som hedder getOrdre(int id). Denne metode skulle så hente ordre objektet hvilket er et ’leaf’ objekt, men den skal jo også have ’kunde’ og ’kvittering’ objektet, men til det sender den vil bare requestion for disse, videre ned gennem træet som så bliver sendt op gennem hierarkiet til der hvor det skal bruge, eller med andre ord den som har efterspurgt det.
Og hvis vi så vil liste alle kunder hopper vi vel bare ned til ’kunder’ composite og får den til at hive dem alle ud.
For at dette skal kunne lade sig gøre skal jeg vil lave et interface/component som har alle tænkelige metoder både generelle, men også de specifikke for de enkelte leafs?
Det fede jeg lige kan se med det her composite pattern er at, det gør en complex datastruktur meget enkelt, let at tilføje nye typer, tilgås uniformt og har et ’entry point’ for at tilgå stort set al din data.
Ved at det var lidt at en lang smøre det her, men ville meget gerne have nogle kommentar/råd med på vejen.
Er mine første løsninger ikke noget møj?
Hvordan strukturerer i sådanne objekter?
Har jeg fat i den rigtige endnu ang. Composite pattern eller er der andre patterns som er mere anvendelig til denne slags opgaver? Dette her må jo være en klassisk problemstilling og lur mig ikke om andre før mig ikke er kommet frem til en generel og mere genial måde at løse dette på.
På forhånd tak,
- Christian
