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
and there are some extra fields
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
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.
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.
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:
date
member) to all kind of reservations, even when it makes no sense. This is against the Interface Segregation Principle 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 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 . 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:
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
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.