Cons of Implementing an Interface - oop

Question

Here is a sample diagram that I am working on:
Cars and Busses are Vehicles
Driver has 0 or more Cars/Busses
Each Driver has a default Car or Bus
Cars/Busses can have max 1 drivers
Now I need to use the Driver and Vehicle in the same context, whenever I pass Driver, get me the default Car/Bus and whenever I pass Vehicle get me this. In this case, is it a bad idea introducing an interface above both of them? If yes, what are the reasons?
Edit:
This is legacy code and I just made up the classes (duh)
We can't modify the current structure
I feel like implementing an interface on top of them is not right, just need an explanation on that. Don't need an implementation.

Answer 1

Perhaps I'm misunderstanding the question, but here are my thoughts:
The driver should own Vehicles, not Car/Bus objects
The whole point of having the interface is that you can treat both of the types of objects in the same way, and reduce duplicated code.
The Vehicle should require a getter for the driver
Use a Vehicle::getDriver(), and have the Bus and Car objects contain a reference to a Driver.
There is no need to introduce an interface above Driver and Vehicle.
Quick untested code stub in C++ (riddled with bugs~~) for how some of this may be implemented:
class Driver;
// Vehicle interface
class Vehicle {
public:
virtual void setDriver(Driver* driver);
virtual Driver* getDriver() const;
/**
* Some exciting driving function!! :D
*/
virtual void drive();
};
class Car : public Vehicle {
Driver* m_driver = nullptr;
public:
void setDriver(Driver* driver) override { m_driver = driver; }
Driver* getDriver() const override { return m_driver; }
void drive() override { /* do something! */ }
};
class Bus : public Vehicle {
Driver* m_driver = nullptr;
public:
void setDriver(Driver* driver) override { m_driver = driver; }
Driver* getDriver() const override { return m_driver; }
void drive() override { /* do something! */ }
};
// Driver
class Driver {
int m_defIdx;
std::vector<Vehicle*> m_vehicles;
public:
void addVehicle(Vehicle* vehicle, bool setDefault = true) {
m_vehicles.push_back(vehicle);
vehicle->setDriver(this);
if (setDefault) m_defIdx = m_vehicles.length() - 1;
}
Vehicle* getDefaultVehicle() { return m_vehicles[m_defIdx]; }
Vehicle* getVehicle(int index) { return m_vehicles[index]; }
}
Note that if you're using C++, smartpointers would probably be a better idea, and instead of an interface, an abstract class may make more sense.
Now, let's take a look at how you'd interface with this.
void robBank(Driver& driver) {
/* do some totally criminal stuff! */
// run away!! Note that we can access the vehicle here.
driver.getDefaultVehicle()->drive();
}
int main() {
Driver sally;
Car* car = new Car();
sally.addVehicle(car, true);
robBank(sally);
delete car; // clean up after ourselves :)
}
Note that even though I only passed in a Driver to robBank(), because a Driver contains a reference to a Vehicle and the Driver object exposes this, we can access a Vehicle.
Cases where it makes sense for an interface to be shared between Driver and Vehicle
You could have an interface they both inherit from like Movable, which may have a Movable::move() function so that both Drivers and Vehicles can move around. This is a notion of having common functionality, and is the key behind the notion of composition over inheritance.

Answer 2

I hope I understood your question correctly.
I wouldn't introduce an interface above them, because it doesn't seem to reflect your domain. It appears to be difficult to come up with a name for it. It is not a good sign.
You can try a Strategy pattern, which can help encapsulate process of obtaining that Vehicle instance for your context.
In this specific case it may be an overkill, but may be that legacy code may benefit.
For example (C#).
class Context {
public Vehicle Drive(DrivingStrategy strategy) {
//...
return strategy.GetDrivable();
}
}
abstract class DrivingStrategy {
public static DrivingStrategy For(Driver driver) {
//...
return new DriverDrivingStrategy(driver);
}
public static DrivingStrategy For(Vehicle vehicle) {
//...
return new VehicleDrivingStrategy(vehicle);
}
abstract public Vehicle GetDrivable();
}
class DriverDrivingStrategy : DrivingStrategy {
private readonly Driver driver;
public DriverDrivingStrategy(Driver driver) {
//...
this.driver = driver;
}
public override Vehicle GetDrivable() {
//Default vehicle logic can be potentially moved from Driver to this class.
return driver.GetDefaultVehicle();
}
}
class VehicleDrivingStrategy : DrivingStrategy {
private readonly Vehicle vehicle;
public VehicleDrivingStrategy(Vehicle vehicle) {
this.vehicle = vehicle;
}
public override Vehicle GetDrivable() {
return vehicle;
}
}
class Driver {
public Vehicle GetDefaultVehicle() {
//...
}
}
class Vehicle {
//...
}
Client:
class Client {
public void Do() {
Context context = new Context();
Driver driver = new Driver();
Vehicle vehicle = new Vehicle();
context.Drive(DrivingStrategy.For(driver));
context.Drive(DrivingStrategy.For(vehicle));
}
}
Of course, VehicleDrivingStrategy class is not doing much, you can lose an abstract DrivingStrategy and make VehicleDrivingStrategy a base class for other ones.
Furthermore, you may want to expand strategies not to just retrieve Vehicle instance, but ask them to do something more for your context. It would be more suitable use for that pattern. Like for a driver strategy: driver.GetDefaultVehicle().Drive() / this.GetDefaultVehicle().Drive() and for a vehicle one: vehicle.Drive();