educative.io

Multiple questions on Parking lot design

Courses
,
#1

Hi, I have few questions on the Parking lot design and would like to clarify it. Appreciate your help on this.

  1. The Vehicle has a one-way association with ParkingTicket. Where is it shown in terms of code. I see ParkingTicket is passed as a parameter to assignTicket() method. Can you please explain the object associations in terms of code.
  • The ParkingSpot has a one-way association with Vehicle.
  • The Vehicle has a one-way association with ParkingTicket.
  • The Payment has a two-way association with ParkingTicket.
  1. ParkingTicket contains instances of the Vehicle , Payment , Entrance and Exit classes. Does this mean ParkingTicket is an Aggregate of all these objects? (Object Association)
  2. Why does AddEntrance() and AddExit() methods are inside the ParkingLot, do they belong to Admin()?
  3. Who is instantiating the ParkingLot class. How does Vehicle, Entrance and ParkingLot are related here.

I have few other questions, but would like to get these clarified and analyze the system again. Thanks again for helping me on this.

Course: Grokking the Low Level Design Interview Using OOD Principles - Learn Interactively
Lesson: Code for the Parking Lot

#2

Can someone help me in explaining the above queries. Thanks.

#3

Hi @Mounica,

  1. Vehicle Association with ParkingTicket: In the code, the association between Vehicle and ParkingTicket is established through the assignTicket(ParkingTicket ticket) method in the Vehicle class. When a vehicle is assigned a parking ticket, it implies a one-way association from Vehicle to ParkingTicket. This method allows us to link a specific vehicle with its corresponding parking ticket within the system.

    • ParkingSpot Association with Vehicle: ParkingSpot has a one-way association with Vehicle. This association is created through the Vehicle parameter in the assignVehicle(Vehicle vehicle) method of the ParkingSpot class. When a vehicle is assigned to a parking spot, the parking spot is aware of the vehicle parked in it.
    • Payment Association with ParkingTicket: The Payment class exhibits a two-way association with ParkingTicket . This bidirectional association is evident in the code, as the Payment class contains a reference to ParkingTicket , and conversely, ParkingTicket contains a reference to Payment . This bidirectional linkage enables both classes to interact and update each other’s data as necessary. For example, when a payment is made, it can update the payment status in the associated parking ticket.

  2. ParkingTicket as an Aggregate or Associate:

    • Simple Association: Based on the code provided, it appears that ParkingTicket is associated with the objects it contains, such as Vehicle, Payment, Entrance, and Exit, through simple associations. This means that ParkingTicket and these objects are connected in a way that allows them to reference each other, facilitating interactions between them. It’s a straightforward relationship where each class knows about the other, and instances of these classes can access and interact with each other.
    • Aggregation: Based on the code provided, it appears that ParkingTicket can be considered an aggregate of the objects it contains, such as Vehicle , Payment , Entrance , and Exit . This representation aligns with the concept of aggregation, where ParkingTicket serves as a container for various objects that are part of a vehicle’s parking record. In this scenario, ParkingTicket encapsulates and aggregates these objects, and they can exist independently of ParkingTicket . This approach allows for a more structured and organized way of managing the related data and functionality.

Note: Both descriptions are accurate, but the choice between Simple Association and Aggregation depends on how you want to model the relationship between ParkingTicket and its contained objects. If you intend for ParkingTicket to be a container that encapsulates and manages these objects, then Aggregation is more suitable. If you see them as having a straightforward reference-based interaction, then Simple Association is appropriate.

  1. AddEntrance() and AddExit() Methods: The addEntrance() and addExit() methods are defined in the Admin class, indicating that they are related to administrative functionality. However, they are placed within the ParkingLot class, possibly for centralizing the management of entrances and exits. This design choice enhances the organization and allows for easier control and coordination of these crucial components from a single point.
  2. Instantiating the ParkingLot Class: The code does not explicitly show where the ParkingLot class is instantiated. However, since the ParkingLot class is designed as a Singleton, it ensures that there is only one active instance of the ParkingLot class at a time. The getInstance() method is used to obtain a reference to the single instance of the ParkingLot. Other classes, such as Entrance, may use this method to interact with the parking lot.

Please drop us a note if you have any other questions or concerns. Happy Learning :blush:

#4

Appreciate your patience in detailing the response. Thankyou!

Payment Association with ParkingTicket : I don’t see the ParkingTicket reference inside the Payment class. However, I understood the concept behind it:)
ParkingTicket as an Aggregate or Associate : ParkingTicket seems to be encapsulating the objects of vehicle, Payment, Entrance and Exit as they are declared Private. Is there any other case that differentiates Aggregation and Association here.
Instantiating the ParkingLot Class :I understand that the code doesn’t show the entire functionality here. Can I analyze that the Entrance class is responsible for creating the ParkingLot instance. Could you please clarify if I am wrong.

Thanks Saif :slight_smile:

Course: Grokking the Low Level Design Interview Using OOD Principles - Learn Interactively
Lesson: Class Diagram