Return to Answer

There are two problems to solve:

1. At design time, enforce that for every new vehicle type which is implemented, there must be also some code implemented which is able to create a corresponding mechanic.

2. At run time, enforce, if a mechanic object shall actually be created, it is the correct mechanic type which corresponds to the type of a given vehicle object.

The first problem is solved by the classic Abstract Factory pattern, using an interface like

 interface VehicleFactory
 {
      Vehicle CreateVehicle();
      Mechanic CreateMechanic();
 }

It avoids any necessity to clutter the vehicle interface with methods which don't belong there. It still forces implementers to create factories which can always produce both types of objects, vehicles and corresponding "mechanic" objects. It is not easily possible to "forget" to add new mechanic derivation when a new vehicle type is added.

For solving the second problem, one has to know precisely how and where in the whole code base "mechanic objects" are created. Since you don't want to clutter your Vehicle interface with this, you need somewhere in your system a centralized factory method of the form

   mechanic = createNewMechanic(vehicle)   // returns  a corresponding mechanic

This centralized function then can internally use a map to find and call the correct factory object:

 Map.of(Car.class, carFactory, 
        Bus.class, busFactory)

The factory objects (of which there will be exactly one per type in your program) can register themselves in this map when they are created by a generic implementation in their base class constructor. So this will make sure the map is dynamically kept up-to-date when new types of vehicles are added, without haviung to change the factory method. So this obeys the OCP.

I am sure instead of implementing this kind of map and factory method by yourself, you could also utilize some DI container for this. I never tried it this way before, but I would actually be astonished if that's not possible.

There are two problems to solve:

1. At design time, enforce that for every new vehicle type which is implemented, there must be also some code implemented which is able to create a corresponding mechanic.

2. At run time, enforce, if a mechanic object shall actually be created, it is the correct mechanic type which corresponds to the type of a given vehicle object.

The first problem is solved by the classic Abstract Factory pattern, using an interface like

 interface VehicleFactory
 {
      Vehicle CreateVehicle();
      Mechanic CreateMechanic();
 }

It avoids any necessity to clutter the vehicle interface with methods which don't belong there. It still forces implementers to create factories which can always produce both types of objects, vehicles and corresponding "mechanic" objects. It is not easily possible to forget adding new mechanic derivation accidentally when a new vehicle type is added.

For solving the second problem, one has to know precisely how and where in the whole code base "mechanic objects" are created. Since you don't want to clutter your Vehicle interface with this, you need somewhere in your system a centralized factory method of the form

   mechanic = createNewMechanic(vehicle)   // returns  a corresponding mechanic

This centralized function then can internally use a map to find and call the correct factory object:

 Map.of(Car.class, carFactory, 
        Bus.class, busFactory)

The factory objects (of which there will be exactly one per type in your program) can register themselves in this map when they are created by a generic implementation in their base class constructor. This will make sure the map is dynamically kept up-to-date when new types of vehicles are added, without having to change the factory method for each new triple Vehicle/Mechanic/VehicleFactory. I guess this is probably the kind of "OCP design" you want to achieve: the source code of the factory method can be inside some "freezed" library, and a user of that library can still extend the "features" without changing the lib.

I am sure instead of implementing this kind of map and factory method by yourself, you could also utilize some DI container for this. I never tried it this way before, but I would actually be astonished if that's not possible.

There are two problems to solve:

1. At design time, enforce that for every new vehicle type which is implemented, there must be also some code implemented which is able to create a corresponding mechanic.

2. At run time, enforce, if a mechanic object shall actually be created, it is the correct mechanic type which corresponds to the type of a given vehicle object.

The first problem is solved by the classic Abstract Factory pattern. It avoids any necessity to clutter the vehicle interface with methods which don't belong there. It still forces implementers to create factories which can always produce both types of objects, vehicles and the corresponding mechanics. It is not possible to "forget" to add new mechanic derivation when a new vehicle type is added.

For solving the second problem, one has to know precisely how and where in the whole code base "mechanic objects" are created. Ideally, one can centralize the creation in some factory method

   mechanic = createNewMechanic(vehicle)   // returns  a corresponding mechanic

The centralized function for this then can internally use a map to find and call the correct factory object:

 Map.of(Car.class, carFactory, 
        Bus.class, busFactory)

The factory objects (of which there will be exactly one per type in your program) can register themselves in this map when they are created by a generic implementation in their base class constructor. So this will make sure the map is dynamically kept up-to-date when new types of vehicles are added.

I am sure instead of implementing this kind of map and factory method by yourself, you could also utilize some DI container for this. I never tried it this way before, but I would actually be astonished if that's not possible.

There are two problems to solve:

1. At design time, enforce that for every new vehicle type which is implemented, there must be also some code implemented which is able to create a corresponding mechanic.

2. At run time, enforce, if a mechanic object shall actually be created, it is the correct mechanic type which corresponds to the type of a given vehicle object.

The first problem is solved by the classic Abstract Factory pattern, using an interface like

 interface VehicleFactory
 {
      Vehicle CreateVehicle();
      Mechanic CreateMechanic();
 }

It avoids any necessity to clutter the vehicle interface with methods which don't belong there. It still forces implementers to create factories which can always produce both types of objects, vehicles and corresponding "mechanic" objects. It is not easily possible to "forget" to add new mechanic derivation when a new vehicle type is added.

For solving the second problem, one has to know precisely how and where in the whole code base "mechanic objects" are created. Since you don't want to clutter your Vehicle interface with this, you need somewhere in your system a centralized factory method of the form

   mechanic = createNewMechanic(vehicle)   // returns  a corresponding mechanic

This centralized function then can internally use a map to find and call the correct factory object:

 Map.of(Car.class, carFactory, 
        Bus.class, busFactory)

The factory objects (of which there will be exactly one per type in your program) can register themselves in this map when they are created by a generic implementation in their base class constructor. So this will make sure the map is dynamically kept up-to-date when new types of vehicles are added, without haviung to change the factory method. So this obeys the OCP.

I am sure instead of implementing this kind of map and factory method by yourself, you could also utilize some DI container for this. I never tried it this way before, but I would actually be astonished if that's not possible.

There are two problems to solve:

1. Enforce that for every new vehicle type which is implemented (at design time), there must be also some code implemented which is able to produce a corresponding mechanic.

2. Enforce that at run time, if a mechanic object shall actually be created, it is the correct mechanic type which corresponds to the type of a given vehicle object.

The first problem is solved by the classic Abstract Factory pattern. It forces implementers to create factories which can always produce both types of objects, vehicles and the corresponding mechanics. It is not possible to "forget" to add new mechanic derivation when a new vehicle type is added.

For solving the second problem, one has to know precisely how and where in the whole code base "mechanic objects" are created. Ideally, one can centralize the creation in some factory method

   mechanic = createNewMechanic(vehicle)   // returns  a corresponding mechanic

The centralized function for this then can internally use a map to find and call the correct factory object:

 Map.of(Car.class, carFactory, 
        Bus.class, busFactory)

The factory objects (of which there will be exactly one per type in your program) can register themselves in this map when they are created by a generic implementation in their base class constructor. So this will make sure the map is dynamically kept up-to-date when new types of vehicles are added.

I am sure instead of implementing this kind of map and factory method by yourself, you could also utilize some DI container for this. I never tried it this way before, but I would actually be astonished if that's not possible.

There are two problems to solve:

1. At design time, enforce that for every new vehicle type which is implemented, there must be also some code implemented which is able to create a corresponding mechanic.

2. At run time, enforce, if a mechanic object shall actually be created, it is the correct mechanic type which corresponds to the type of a given vehicle object.

The first problem is solved by the classic Abstract Factory pattern. It avoids any necessity to clutter the vehicle interface with methods which don't belong there. It still forces implementers to create factories which can always produce both types of objects, vehicles and the corresponding mechanics. It is not possible to "forget" to add new mechanic derivation when a new vehicle type is added.

For solving the second problem, one has to know precisely how and where in the whole code base "mechanic objects" are created. Ideally, one can centralize the creation in some factory method

   mechanic = createNewMechanic(vehicle)   // returns  a corresponding mechanic

The centralized function for this then can internally use a map to find and call the correct factory object:

 Map.of(Car.class, carFactory, 
        Bus.class, busFactory)

The factory objects (of which there will be exactly one per type in your program) can register themselves in this map when they are created by a generic implementation in their base class constructor. So this will make sure the map is dynamically kept up-to-date when new types of vehicles are added.

I am sure instead of implementing this kind of map and factory method by yourself, you could also utilize some DI container for this. I never tried it this way before, but I would actually be astonished if that's not possible.