How would a SRP `class Car` look like? [closed]

Question

SRP insists that a class should have only a single a reason to change. Please guide me through the following example.

class Car
{
    drive_forward();
    embark();
    disembark();
    fuel_up();
}

All the methods are business level of abstraction. But driving depends on the quality of the road while fueling depends on gas prizes. And all 4 depend on implementation details. How do we apply the S from SOLID here?

Answer 1

There is no global answer to this, and in particular it depends on what your program is simulating. To take some highly simplified examples:

• If your Car represents a Formula 1 race car, you probably want to go into great detail as to how drive_forward() is implemented, but don't need to worry so much about the price of fuel.
• On the other hand, if your Car represents a car in a taxi service, your drive_forward() implementation is going to be a lot simpler than that for the Formula 1 car, but the price of fuel is something you're going to want to model.

This is where the skill of a programmer comes in - it's your job to identify which parts of the business domain which are complex and/or may need to change in the future and ensure that your domain model allows those parts to be testable and modified easily. For the bits which are simple and not likely to change in the future, YAGNI applies and you can just hard-code those assumptions - for example, it's probably a safe assumption that your Formula 1 car has 4 wheels.