Question

I have looked on line for information that would help me solve a design issue that is confusing me. I am new to complicated inheritance situations so my solution could actually just be rooted in a better design. But in trying to figure out what my design should be, I keep ending up thinking I really just need to inherit more than 1 base class.

My specific case involves Assets and different types of Assets.

Starting with the Asset…

Every PhysicalDevice is an Asset
Every VirtualDevice is an Asset
Every Server is an Asset

Every PhysicalServer would need to be both a PhysicalDevice and a Server
Every VirtualServer would need to be both a VirtualDevice and a Server
Every NetDevice is a PhysicalDevice
Every StorageArray is a PhysicalDevice

One solution I guess is to duplicate the Server code for both PhysicalServers, and VirtualServers however, I feel like this goes against what im trying to do, which is inherit.

They need to be separate classes because each of the types will have properties and methods. For instance, Server will have OSCaption, Memory, Procs, etc. PhysicalDevice will have things like Location, Serial, Vendor etc. And VirtualDevice will have a ParentDevice, State, VHDLocation etc.

If the inheritance is liner then i run into the problem of not being able to describe these types accurately.

Something that seems intriguing is Interfaces. It seems that i can define all base classes as interfaces and implement them in my main classes as needed. but, I am simply unsure of what the implications are if I were to do that.

for instance, something like… PhysicalServer : IAsset : IServer : IPhysical

I am in deep water so I’m really just looking for suggestions or guidance.

Answer 1

Interfaces are an appropriate way of ensuring contract integrity across types, but you may end up with duplicate code for each implementation.

Your scenario may lend itself better to composition than inheritance (or a combination thereof).

Example – Inheritance + Composition

public class PhysicalServer : Asset
{
    public PhysicalInfo PhysicalProperties
    {
         get;
         set;
    }
}

public class VirtualServer : Asset
{
    public VirtualInfo VirtualProperties
    {
         get;
         set;
    }
}

Example – Composition Only

public class VirtualServer
{
    public VirtualInfo VirtualProperties
    {
         get;
         set;
    }

    public AssetInfo AssetProperties
    {
         get;
         set;
    }
}

You could then add polymorphism/generics into the mix and create derivatives of types to represent more specific needs.

Example – Inheritance + Composition + Genericized Member that inherits from a common type

public class VirtualServer<TVirtualInfo> : Asset
   where TVirtualInfo : VirtualDeviceInfo
{
    public TVirtualInfo VirtualProperties
    {
         get;
         set;
    }
}

public class VirtualServerInfo : VirtualDeviceInfo
{
   // properties which are specific to virtual servers, not just devices
}

There are countless ways that you could model this out, but armed with interfaces, composition, inheritance, and generics you can come up with an effective data model.