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)
  • @MadKeithV et al, please reconsider your close vote in the light of the answer provided..
    – Cel
    May 8, 2013 at 15:54

1 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.

  • I think I understand this answer, but would really prefer a concrete example to help me get my head around it. Is there any chance on a car analogy or something?
    – Racheet
    May 8, 2013 at 14:51
  • Thanks a lot for the answer, and I now found many in-depth explications thanks to you keyword. Also, I do not understand why this question was voted to be closed, as evidenced by your answer I do not see any mismatches..
    – Cel
    May 8, 2013 at 15:53
  • @cel - to be fair, the entire domain of "how to architect extenisble systems" could fit within an entire book. Further, how I would do it isn't the sort of objective question that the site favors. Something like "How does a component based entity help with product extensibility?" might be more focused, objective and useful for future visitors.
    – Telastyn
    May 8, 2013 at 17:04
  • @Telastyn the issue is that i had never heard of component based entity systems. I have tried asking architectural questions in stackoverflow and been pointed to Programmers as the place for more meta-type questions. I think questions with large scope can have useful specific answers that answer at an equivalent macro level and use links to refer to the narrower scopes (which I would otherwise not know to visit).
    – Cel
    May 8, 2013 at 17:38
  • @cel - I would be inclined to agree with you. Intelligent discussion of not-strictly-answerable questions has its own benefit.
    – Telastyn
    May 8, 2013 at 17:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.