Combinatorial explosion of interfaces: How many is too many?

Posted by mga on Programmers See other posts from Programmers or by mga
Published on 2014-06-12T20:54:23Z Indexed on 2014/06/12 21:37 UTC
Read the original article Hit count: 196

I'm a relative newcomer to OOP, and I'm having a bit of trouble creating good designs when it comes to interfaces.

Consider a class A with N public methods. There are a number of other classes, B, C, ..., each of which interacts with A in a different way, that is, accesses some subset (<= N) of A's methods.

The maximum degree of encapsulation is achieved by implementing an interface of A for each other class, i.e. AInterfaceForB, AInterfaceForC, etc.

However, if B, C, ... etc. also interact with A and with each other, then there will be a combinatorial explosion of interfaces (a maximum of n(n-1), to be precise), and the benefit of encapsulation becomes outweighed by a code-bloat.

What is the best practice in this scenario?

Is the whole idea of restricting access to a class's public functions in different ways for other different classes just silly altogether? One could imagine a language that explicitly allows for this sort of encapsulation (e.g. instead of declaring a function public, one could specify exactly which classes it is visible to); Since this is not a feature of C++, maybe it's misguided to try to do it through the back door with interaces?

© Programmers or respective owner

Related posts about design

Related posts about c++