Should I use an API/ABC when designing a class used by several in C++?

Question

Hi,

I am about to add a class X that will be used by my three previously designed classes (A, B and C).

The new class X will contain data and functions for new features as well as provide services to the classes that use it to hide lower layers. The problem is that A, B and C will use class X quite differently, that is, use different functions of it.

My question is if I should provide an API (or Abstract Base Class in C++) for the new class X or not. If I should, should that API be per X class or per A, B and C class? I have read somewhere that an API is sometimes more closely related to that caller that the class that implements it. If I do provide one API for each caller, the API will only contain the functions that the particular caller needs.

Or should I just create a normal C++ class and let the callers use a subset of the public functions of X in each of A, B and C, although they "technically" can use them all? The functions of class X are not very likely to change neither is the need to create a similar class to X.

If I'm not completely lost in object oriented programming, one reason for providing an interface/API for a class is that code that use the interface/API doesn't need to change if you add another subclass since the caller works on the interface name and uses dynamic binding to resolve the correct subclass type.

Best regards and please let me know if anything is unclear and I'll try to answer that as quickly as possible.

Thanks,

Tomas

Answer 1

Are you sure all these functions belong to the same class X? Think about separating different functionality into different classes: http://en.wikipedia.org/wiki/Low-Coupling_/_High-Cohesion_pattern

But without knowing what the functions of X are it is difficult to help further.

Answer 2

If things are unlikely to change then it's probably not worth the extra effort.

If you decide to, though, the question is whether new classes would implement all or just part of the functionality. For example, do they share backend storage, so all would need to be updated at once (in which case there is no point in splitting), or do they relate to entirely separate concerns in which case splitting (as suggested by @GarethOwen) is probably the way to go.