Introduction
In the previous chapter, I extracted all the information I could find from the problem statement. In this chapter, I will design a solution in terms of object-oriented principles. First, I will pinpoint all the relevant conceptual classes from the given scenario. Then, I will define the relationships between each of those classes. Lastly, I will convert the conceptual classes into real software classes.
Discovering conceptual classes
Let’s analyse the problem statement again and discover candidate conceptual classes for the parking space booking domain.
In the presented scenario, I found five conceptual classes: car park, parking space, visitor, car, and booking. In addition, my solution will include a payment class and a money class. A money class? Yes, we will need it to make some financial calculations on our bookings in task 3 (new feature). I'll explain when we get to the bridge. Finally, we will have a payment method interface for the various payment methods that the system will accept. The program will accept both card payments and mobile payments.
NB: The main reason for adding new features to the program is so that I learn as many Java core concepts as possible.
The UML designs
I will use the open-source diagramming tool called Dia to draw all the diagrams in this series. In this session, I will draw the class diagrams to show the relationships between the conceptual classes and their individual properties. This is the first iteration of the process.
For those unfamiliar with the UML, I suggest you refer to the links and books listed at end of the post. I will just describe the UML relationships between the classes in the problem context.
Classes in detail (iteration 1)
Let’s first look at the Visitor class. My first assumption is that each visitor has a single car and can only book a parking space for that one particular car. In addition, the visitor can only use a single payment method to make a booking. The payment methods can only be (at the moment) one of the listed payment methods. Via the payment method, a visitor can checkout/pay for a booking creating a payment object which will be saved in the booking.
The Booking class is quite large. It stores the details about the visitor making the booking, the allocated parking space, the selected booking date and the information about the payment made for that booking. Each booking has a reference to only one visitor and one parking space. All the bookings are created through the Carpark class which represents the organization owning the parking spaces. All these bookings are stored in a collection in the Carpark class.
Notice, the ParkingSpace class has a price which is the cost of parking on that spot. It will be useful in the future if the organization decides to have different types of parking spaces that are priced differently.
This is the end of our first Iteration. I think I tried to keep things as simple as possible to create some working code that shows how everything fits together. Let’s implement this design in the next chapter.