The typical solution would be introduce a common interface, so that ValidateVehicle
can work with either type:
public interface IVehicle{
Color color {get; set;}
}
public class Car:Wheel, IVehicle {
public Color color {get; set;}
}
public class Bike:Wheel, IVehicle
{
public bool hasRadio {get ; set;}
public Color color {get; set;}
}
private void ValidateVehicle(IVehicle vehicle)
{
// Implementation here
}
This obviously require IVehicle
to expose all methods and properties that are used by ValidateVehicle
.
If the validation logic is different for cars and bikes you should just place the validation method on your vehicle type. This way each vehicle can be validates in their own way.
public interface IVehicle{
Color color {get; set;}
bool ValidateVehicle();
}
A third way would be to use type checks:
private void ValidateVehicle(object vehicle)
{
if(vehicle is Car car){
...
}
if(vehicle is Bike bike){
...
}
}
But this is not as easy to maintain. Say that you introduce a motorbike, if you use a interface you just need to make your new vehicle inherit that interface, and the compiler complain if you made any mistake. If you use type-checks you need to remember all the various places you check for type and add another check for your motorbike, that can quickly become a maintenance nightmare. Because of this type checks are generally frowned upon.
I'm guessing this is for an assignment, but I dislike examples of object orientation like this. Notably a car is not a wheel, it has wheels, i.e. the wheel should be a property and not inherited.
I generally prefer geometry when demonstrating object orientation, it has plenty of examples of composition and inheritance, and is actually useful in real programs. In contrast, I have difficulty imagining where a vehicle inheritance hierarchy would actually be useful.