serving up future-proof kinfolk - extensible contract interfaces [closed]

Question

Ok, I have this human here, but what can it do, how would you discover its special abilities? And when you find out what kind of expert you've got then how would you actually make use of its unique responsibilities?

An example for this architectural pattern question:

Base Interface with Characteristics Common to All

interface IHuman {
    DateTime GetDoB();
}

Extended Interface 1

interface ICivilian : IHuman {
    string GetEmail();
    void SendEmail();
}

Extended Interface 2

interface IAccountant : IHuman {        
    double CalculateProfits();
}

Extended Interface n+

interface IAnotherSpecializedHuman : IHuman {
    void DoSomethingExpert();
}

Specialized API Discovery and Usage

How would you design

• a highly pluggable and loosely-coupled system
• with which you can carry out all the common human operations (e.g. get age),
• but also carry out any specialized operations that are available,
• depending on which modules are incorporated
  • e.g. you can send email, because ICivilian module is provided
  • but you cannot calculate profits, because IAccountant plug-in is not provided
• and the question is not so much about providing different implementations but about providing different specialized APIs (and APIs that have a common parent with shared functionality)

Answer 1

First things first, I would not have different APIs share a common parent. As soon as you run into alien accountants or want to get the age of a dog, you're out of luck.

I would (and have) dealt with this via Component Based Entity designs. Instead of making a solid object that implements a ton of interfaces, you have a very thin object that contains a ton of interfaces. The user can then query "do you have some capability that satisfies this contract?". The consumer still needs to know about all of the contracts it wants to use, but the entity is free to construct, aggregate, or otherwise supply these (or not!) at its discretion. Need a new capability? Just add the new one to the collection and give the contract to end users to ask for.

The traditionally hard part with these designs is how to split up the contracts. Invariably the different components of the entity need to talk to each other, or share some common data. How you solve that tends to be specific to your particular problem.