Ik ben bezig met het ontwerpen en implementeren van een boekingssysteem voor de medewerkers van een reisbureau, en dat systeem moet ook gekoppeld worden aan een website, zodat klanten online kunnen boeken. Dit houdt in dat regels voor de prijzen en beschikbaarheid van verschillende reisitems (hotels, vliegtickets, huurauto's en evt. extra's) dynamisch moeten kunnen worden bepaald aan de hand van de ingevoerde gegevens van klanten (vertrekdata, passagiersleeftijden etc.). Dit heeft mij voor een lastig ontwerpprobleem gesteld. Ik werk met Hibernate, en ik heb de volgende relevante entities reeds gedefiniëerd:
TicketItem
HotelItem
RentalCarItem
ExtraItem
Een Trip bestaat uit een combinatie van deze items, plus natuurlijk klantgegevens enzo. Deze items hebben allemaal een referentie naar een StandardItem, die als het ware een template is om nieuwe reizen samen te stellen (er zit een beschrijving, plaatjes etc. aan gekoppeld). Ook heeft een StandardItem één of meerdere PricingRanges, die simpelweg een standaardprijs toekennen aan een bepaalde periode. Daarnaast kan een StandardItem één of meerdere PricingExceptions hebben.
De PricingException entity heeft de volgende relevante eigenschappen:
De className moet verwijzen naar een implementatie van de interface PricingExceptionProcessor:
De methode processPrice moet dus een nieuwe prijs geven (of de boeking blokkeren) op basis van de oude prijs, maar ook op basis van de verschillende eigenschappen (vertrekdata etc.) van het item waar deze exception op wordt toegepast. Het probleem is dat de verschillende items hierboven opgesomd (TicketItem etc.) niet erven van één "TripItem" klasse o.i.d. Waarschijnlijk is dit wel nodig, realiseer ik me nu (
), maar voordat ik grote refactorings ga doorvoeren wil ik even jullie mening hebben over dit model.
Edit: Oja, dit gaat over de inkoopprijzen van de verschillende items, maar volgens mij is dat niet relevant (verkoopprijzen gaan vergelijkbaar).
Gaat dit fijn werken, denken jullie? Of moet ik het helemaal anders aanpakken? Heeft iemand misschien ervaring met het bedenken van representaties van pricing & availability models?
TicketItem
HotelItem
RentalCarItem
ExtraItem
Een Trip bestaat uit een combinatie van deze items, plus natuurlijk klantgegevens enzo. Deze items hebben allemaal een referentie naar een StandardItem, die als het ware een template is om nieuwe reizen samen te stellen (er zit een beschrijving, plaatjes etc. aan gekoppeld). Ook heeft een StandardItem één of meerdere PricingRanges, die simpelweg een standaardprijs toekennen aan een bepaalde periode. Daarnaast kan een StandardItem één of meerdere PricingExceptions hebben.
De PricingException entity heeft de volgende relevante eigenschappen:
Java:
1
2
3
| String className; Map arguments; StandardItem standardItem; |
De className moet verwijzen naar een implementatie van de interface PricingExceptionProcessor:
Java:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
| public interface PricingExceptionProcessor { /** * Processes the given price, and returns the new price. * * @return the new price * @param originalPrice the original price * @param arguments a map of arguments that this processor can use * @throws BlockBookingException in case this processor decides that the * booking should not be allowed, for instance on certain blackout dates. */ public Money processPrice(Money originalPrice, Map arguments) throws BlockBookingException; // Money is een wrapper voor een decimal & een currency /** * Returns a textual representation of this processor, when using the given * arguments. * * @return the textual representation * @param arguments the arguments */ public String toString(Map arguments); /** * Returns a map of possible argument keys, linked to the argument's required * type. * * @return the map (key ==> argument type) */ public Map<String, Class> getPossibleArguments(); /** * Returns the name of this processor, intended for graphical display. * * @return the name of this processor */ public String getName(); /** * Returns a textual description of this processor. * * @return the description */ public String getDescription(); } |
De methode processPrice moet dus een nieuwe prijs geven (of de boeking blokkeren) op basis van de oude prijs, maar ook op basis van de verschillende eigenschappen (vertrekdata etc.) van het item waar deze exception op wordt toegepast. Het probleem is dat de verschillende items hierboven opgesomd (TicketItem etc.) niet erven van één "TripItem" klasse o.i.d. Waarschijnlijk is dit wel nodig, realiseer ik me nu (
Edit: Oja, dit gaat over de inkoopprijzen van de verschillende items, maar volgens mij is dat niet relevant (verkoopprijzen gaan vergelijkbaar).
Gaat dit fijn werken, denken jullie? Of moet ik het helemaal anders aanpakken? Heeft iemand misschien ervaring met het bedenken van representaties van pricing & availability models?
[ Voor 3% gewijzigd door Eelke Spaak op 13-10-2005 12:28 ]
