Let's say I have a grid with square fields. For the fields I have an abstract Field class. This class has several subclasses, for example EmptyField or RoadField. Some of these fields can be connected to each other, thus I have an interface IConnectable that these classes implement. Now every connectable field should have a Connections object. However interfaces can't have member objects. My idea was that instead of an interface I use another abstract class for that, ConnectableField, which is a subclass of Field and the parent class for all connectable classes. But what do I do if I want to add another such abstract class, say a RotatableField which has a Rotation object. I can't make an interface out of it because of the member object. But I also can't inherit from it because a class can only have one base class. What do I do?EDIT:(The following is not actually the reason why I asked this question, it's just an example as to why I don't think I can use interfaces.)I can't make it an interface because I want to declare an enum, like this:interface IConnectable {    public enum Orientation_CW { ZERO, NINETY, ONEEIGHTY, TWOSEVENTY };}It won't let me do that with the following error:Error CS0524  'IConnectable.Orientation_CW': interfaces cannot declare types
What to do if I need more than one base class in C#?
c#;interfaces;inheritance;multiple inheritance
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 inheritancepublic 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. 