How to handle a real world multiple inheritance scenario in .Net?

Question

I've heard of the pitfalls of multiple inheritance before, and I know the .Net devs are against it's inclusion.

With that said, consider a simple example such as 'Game Companies'. A game company can be:

• a software developer, like Platinum Games
• a publisher, like for instance Agetec
• a developer AND publisher at the same time, as in Blizzard Entertainment
• a gaming hardware manufacturer only (don't have examples of a company that is solely a manufacturer in hand)
• all of the above, i.e. Nintendo

If I had to model this in .Net, how would I go about the fact that the "is a" relationship is present and a company can be multiple of those at the same time? Imagine that I have modeled a:

1. Game class, having List<Developer> and Publisher as properties
2. Console class that had a Manufacturer property.

In an ideal scenario, this should be as type safe as possible and easy to filter and navigate to and from each class (like a fully connected Entity Framework mapping of sorts).

I thought about something in the same vein, for which I probably known the 'right' answer.

What if I had FatPerson and TallPerson as base classes and wanted to 'work around' the multiple inheritance limitation? Because it's quite possible to have someone who is both fat and tall at the same time. In this case, it would probably be cleaner if there was a single Person had two properties, Weight and Height, eliminating the base classes altogether. It would be just a matter of rewriting whatever filtering I had before that was based around the type of the objects to consider these new properties.

Is there something inherently equivalent to this for every multiple inheritance case? What about for this particular case I proposed?

Update:

I've read that answer that is marked as a duplicate of mine (before posting this one), but I disagree slightly here. I think this is the same as marking a SQL optimization question as duplicate of every other SQL optimization question. In the end, each case is a different case, and would require a different approach/answer. I think this applies here since I asked about a very fixed case, like the other answer did.

Answer 1

This scenario is a good example for Role Based Software Engineering which is a current topic in research. That's because there is no one and only solution to the problem. There are several approaches, but all of them have their drawbacks.

Interfaces are a good way to design the relation of types. If you make e.g. Developer and Publisher interfaces, there can be companies that are both. However, you cannot inherit code from interfaces and you usually end up with lots of duplicate code.

Going one step further, you come up with mixin inheritance. That's basically interface implementation augmented with extension methods. Take a look at this example:

class Company { }

interface Publisher { }
public static class PublisherMixin
{
    public static void Publish(this Publisher p) 
    {
        //do something
    }
}

class CompanyThatIsAPublisher : Company, Publisher { }

And then you can do

var c = new CompanyThatIsAPublisher():
c.Publish();

You can do this for several mixins. You can even provide state for the mixins with the help of weak reference dictionaries.

Another way to avoid code duplication is delegation. You still have your interface hierarchy, but create objects for the developer role, the publisher role etc. The company then just forwards method calls to these sub-objects. However, this results in object schizophrenia. The sub-objects do not really belong to the main object which can pose a problem. However you can easily exchange them.

In C# you could also use a DynamicObject. With this you could dynamically register roles and dynamically reroute method calls to the appropriate objects. So a developer company can become a publisher eventually without having to loose its identity. This approach also suffers from the object schizophrenia problem.