类图UML

Question

I'm creating a class diagram for a room reservation system. There is an option of creating a regular reservation (for example every Tuesday in March). I´m wondering whether I should design a specific class like this:

Answer 1

• Should I design a specific class? Maybe
• Like this? No

Whether to use inheritance or not is IMHO a cost/benefit question.

When implementing inheritance there is usually some cost involved in terms of extra classes, tables, documentation and other results that need to be created after the decision to use inheritance.

Inheritance is about special and general cases. First you might want to ask what is the difference between the cases - (called a discriminator). In your case it is the type of reservation and you could avoid the inheritance by modelling this type of reservation and implementing the different behavior based on the reservation type. That would lead to a design like:

Avoiding inheritance

If the inheritance has a high benefit because there are a lot of extra attributes, relation or operations for each special case then you can apply it.

In this case there is

• an extra 1:n relation between regular reservation and reservation (which was not visible in your design but implied by the attribute regular Reservation)

and there are some extra fields

• start date
• end date
• frequency

What is missing at this time is common behavior that would make it sensible to apply inheritance. In the image below I added the generalization nevertheless. It would not be needed at this point in time but as soon as there are general operations you would like to apply to any type of reservation:

Applying inheritance

Answer 2

I would definitely not model the collection as a subclass of the single. If anything, the inheritance relationship runs the other direction: a Reservation is a special kind of Regular Reservation where startDate == endDate and frequency == 1 .

But then why even model two classes? Consider that all reservations are regular. Conceptually, a Reservation is a collection containing only one item. A Regular Reservation is a collection containing multiple items.

Answer 3

Try utilizing a single Reservation abstract class in this case, and creating two sub classes from that, SingleReservation and RecurringReservation as shown in this diagram :

This will help your business logic determine how to handle each reservation, and prevent the use of null-able columns in your database.

Answer 4

Isn't this design seriously flawed ?

Inheritance should not be used just as a trick for reusing some class members. If RegularReservation would inherit from Reservation , it would mean that a regular reservation IS SOME KIND OF simple reservation. Is this the really case ? For example what about the single Date of Reservation : has a date. Does it have any meaning for a regular reservation ?

So there are some flaws here:

• it imposes a useless part of the (private) interface ( date member) to all kind of reservations, even when it makes no sense. This is against the Interface Segregation Principle
• the base class must know about the inheriting classes ( regular_reservation member). So if tomorrow you'd wanted to create a MultipleReservation (several unrelated dates), you'd need to modify the base class again. This is against the Open Close Principle
• classes using Reservation would need to know the details about the different kind of reservations to handle their specific abilities. This is against the Principle of the least knowledge .

What problem do you want to solve ?

The challenge for a room reservation system is not only to register reservations, but also to know for each given time slot if the room is free or if there's already a reservation.

Consequences:

• You must be able to get all the occurrences of a regular reservation in a given time interval.
• You should decide whether occurrences of a regular reservation are single reservations, or whether single and regular reservation should both have some kind of occurence objects.

Proposed design

An abstract Reservation is always about a Client booking a Room with a price for one or several TimeSlots . TimeSlots are only about dates, time, duration. This helps to ensure a separation of concerns:

The number of slots and how these are created will depend on the kind of Reservation . But the general principle is that deleting a reservation would delete all its time slots (ok: what if there are slots in the past ?).

You may also have some general methods:

• getAllSlots() would return the full collection of time slots
• getSlotsInInterval(startDate, endDate) would return only those time slots in the interval