educative.io

Quiz: Object-oriented Design Principles - Grokking the Low Level Design

In Question 9, Why both B & C can’t be the answer ?


Course: https://www.educative.io/courses/grokking-the-low-level-design-interview-using-ood-principles
Lesson: Quiz: Object-oriented Design Principles

Hi @Rahul_Chaudhary !!
In this scenario, only option B is correct because:

  1. Base Class: Vehicle (startMoving:void): The base class Vehicle should contain the common functionality for all vehicles, which includes the startMoving() method. Since not all vehicles require fuel, it’s better to keep the addFuel() method out of the base class.

  2. Child Class: FuelVehicle (startMoving:void, addFuel:void): Introducing an intermediate class FuelVehicle that inherits from Vehicle and has an addFuel() method is a good design choice. This way, only vehicles that require fuel will inherit from FuelVehicle, and you avoid adding the addFuel() method to all vehicles.

  3. Bicycle (startMoving:void): A bicycle does not require fuel, so it directly inherits from Vehicle without the addFuel() method.

  4. Carriage (startMoving:void): Similarly, a carriage does not require fuel, so it also directly inherits from Vehicle without the addFuel() method.

  5. Child Class of FuelVehicle: Car (startMoving:void, addFuel:void): The Car class, which requires fuel, inherits from FuelVehicle. This way, it inherits both the startMoving() method from the base class Vehicle and the addFuel() method from FuelVehicle.
    This hierarchy allows you to manage vehicles with different characteristics effectively. Vehicles that require fuel, like cars, inherit from FuelVehicle, while those that don’t require fuel, like bicycles and carriages, inherit directly from the base class Vehicle.
    I hope it helps. Happy Learning :blush:

Thanks for the detailed explanation. Yes I understood why option B is correct. What I am asking is why option C is not correct. Why can’t we create two abstract class called fuelVehicle and nonFuelVehicle and respective class can extend these classes as in option C

@Rahul_Chaudhary Option C could also be a valid approach, but it might not be the most efficient or suitable design for the given scenario. Here are some reasons why Option B is preferable over Option C:

  1. Complexity: Option C introduces an extra level of abstraction (nonFuelVehicle) that might not be necessary. Introducing unnecessary complexity can make the code harder to understand and maintain.

  2. Scalability: If you have more types of vehicles that require fuel or do not require fuel, the hierarchy could become more convoluted and difficult to manage with Option C. Option B keeps the hierarchy simple and easy to extend.

  3. Redundancy: Option C might result in redundant code, as both the FuelVehicle and nonFuelVehicle classes may end up containing similar or identical code for the startMoving() function. In such cases, it is better to minimize redundancy and keep the code concise.

  4. Maintainability: Option B follows the principle of keeping classes simple and focused. This simplifies maintenance and ensures that each class has a clear and specific purpose, making the codebase more maintainable in the long run.

While Option C is not necessarily incorrect, it might lead to unnecessary complications in the hierarchy, making the codebase less efficient and harder to maintain. In contrast, Option B follows a more straightforward and manageable approach for the given scenario.
Happy Learning

1 Like