Firstly, there is not a single conceivable solution modelled in any OO language using inheritance from a base class, which could not also be modelled effectively using composition.
Inheritance from a base class can occasionally make code more convenient to write when compared with composition, but nothing about the resulting behaviour of the derived class will be any better or different than the alternative solution using composition.
Typically by using inheritance you're just saving yourself from writing a small amount of extra boilerplate code; but in saving that extra boilerplate code you're surrendering a lot of flexibility by forcing your derived class to be entirely dependant on its base class.
So with the above in mind, and to answer your question directly, to solve a problem where you might consider multiple inheritance as a solution, what you're actually seeking is a solution which is more flexible, so you need to rely on composition and accept a bit of additional boilerplate code.
e.g.
// ERROR!
public class MyIllegalClass : MyBaseClass, MyOtherBaseClass
{
}
Can be represented like this, although you will not get any extra flexibility:
public class MyClass
{
public MyBaseClass Base { get; private set; }
public MyOtherBaseClass OtherBase { get; private set; }
public MyClass()
{
// NOT a good solution. MyClass is still dependent on these.
Base = new MyBaseClass();
OtherBase = new MyOtherBaseClass();
}
}
For increased flexibility:
// Better - has more flexibility than multiple inheritance
public class MyClass
{
public MyBaseClass Base { get; private set; }
public MyOtherBaseClass OtherBase { get; private set; }
public MyClass(MyBaseClass base, MyOtherBaseClass otherBase)
{
// BETTER. Anything which derives from these will also work.
Base = base;
OtherBase = otherBase;
}
}
In your specific example, the problem you have is not only "What if I want a RotatableField
?" but also "What if I want a RotatableConnectableField
?" and then later on you might even wonder "what if I want a ColourableRotatableField
?" etc.
As the complexity of your Field
increases, inheritance will lead you down a very messy pathway, i.e. trying to reconcile Rotatable, Connectable and Colourable behaviours, with whatever else may come in future; which is why other replies have suggested the use of interfaces - Your Field
class won't need to worry anything about whether it happens to use a Rotator, A Connector, etc.
e.g. using constructor dependency injection, and treating Rotate/Connect separately:
public class Field
{
private IRotator _rotator;
private IConnector _connector;
public Field(IRotator rotator, IConnector connector)
{
_rotator = rotator;
_connector = connector;
}
}
public class Program
{
public static void Main(string[] args)
{
var myField = new Field(new NinetyDegreeRotator(), new FieldConnector());
}
}
or instead of injecting Rotate
and Connect
as separate concerns, you might rationalise them into a single interface:
public class Field
{
public void AddModifier(IFieldModifier modifier)
{
modifier.Modify(this);
}
}
public class Program
{
public static void Main(string[] args)
{
var myField = new Field();
myField.AddModifier(new NinetyDegreeRotator());
myField.AddModifier(new FieldConnector());
myField.AddModifier(new BorderColour(Colour.Red));
// etc.
}
}
In both cases, Field
would remain independent of the behaviour which rotates or connects. The interface(s) will give you more extensibility in future when you decide you want need to change that behaviour in some other way.