CODEWITHSUNDEEP
c++design-patternscoding-style
nakiya
nakiya

Reputation: 14413

Is it better to have lot of interfaces or just one?

I have been working on this plugin system. I thought I passed design and started implementing. Now I wonder if I should revisit my design. my problem is the following:

Currently in my design I have:

  1. An interface class FileNameLoader for loading the names of all the shared libraries my application needs to load. i.e. Load all files in a directory, Load all files specified in a XML file, Load all files user inputs, etc.

  2. An Interface class LibLoader that actually loads the shared object. This class is only responsible for loading a shared object once its file name has been given. There are various ways one may need to load a shared lib. i.e. Use RTLD_NOW/RTLD_LAZY...., check if lib has been already loaded, etc.

  3. An ABC Plugin which loads the functions I need from a handle to a library once that handle is supplied. There are so many ways this could change.

  4. An interface class PluginFactory which creates Plugins.

  5. An ABC PluginLoader which is the mother class which manages everything.

Now, my problem is I feel that FileNameLoader and LibLoader can go inside Plugin. But this would mean that if someone wanted to just change RTLD_NOW to RTLD_LAZY he would have to change Plugin class. On the other hand, I feel that there are too many classes here. Please give some input. I can post the interface code if necessary. Thanks in advance.

EDIT:

After giving this some thought, I have come to the conclusion that more interfaces is better (In my scenario at least). Suppose there are x implementations of FileNameLoader, y implementations of LibLoader, z implementations of Plugin. If I keep these classes separate, I have to write x + y + z implementation classes. Then I can combine them to get any functionality possible. On the other hand, if all these interfces were in Plugin class, I'd have to write x*y*z implementation classes to get all the possible functionalities which is larger than x + y + z given that there are at least 2 implementations for an interface. This is just one side of it. The other advantage is, the purpose of the interfaces are more clearer when there are more interfaces. At least that is what I think.

Upvotes: 2

Views: 795

Answers (5)

Andy Thomas
Andy Thomas

Reputation: 86391

You might be interested in the Interface Segregation Principle, which results in more, smaller interfaces.

"Clients should not be forced to depend on interfaces that they do not use."

More detail on this principle is provided by this paper: http://www.objectmentor.com/resources/articles/isp.pdf

This is part of the Bob Martin's synergistic SOLID principles.

Upvotes: 2

DaveE
DaveE

Reputation: 3637

Having the One Big Class That Does Everything is wrong. So is having One Big Interface That Defines Everything.

Upvotes: 0

eglasius
eglasius

Reputation: 36027

There isn't a golden rule. It'll depend on the scenario, and even then you may find in the future some assumptions have changed and you need to update it accordingly.

Personally I like the way you have it now. You can replace at the top level, or very specific pieces.

Upvotes: 0

user206705
user206705

Reputation:

My c++ projects generally consists of objects that implement one or more interfaces.

I have found that this approach has the following effects:

  • Use of interfaces enforces your design.
  • (my opinion only) ensures a better program design.
  • Related functionality is grouped into interfaces.
  • The compiler will let you know if your implementation of the interface is incomplete or incorrect (good for changes to interfaces).
  • You can pass interface pointers around instead of entire objects.

Passing around interface pointers has the benefit that you're exposing only the functionality required to other objects.

COM employs the use of interfaces heavily, as its modular design is useful for IPC (inter process communication), promotes code reuse and enable backwards compatiblity.

Microsoft use COM extensively and base their OS and most important APIs (DirectX, DirectShow, etc.) on COM, for these reasons, and although it's hardly the most accessible technology, COM's not going away any time soon.

Will these aid your own program(s)? Up to you. If you're going to turn a lot of your code into COM objects, it's definitely the right approach.

The other good stuff you get with interfaces that I've mentioned - make your own judgement as to how useful they'll be to you. Personally, I find interfaces indispensable.

Upvotes: 5

T.E.D.
T.E.D.

Reputation: 44804

Generally the only time I provide more than one interface, it will be because I have two completely different kinds of clients (eg: clients and The Server). In that case, yes it is perfectly OK.

However, this statement worries me:

I thought I passed design and started implementing

That's old-fashioned Waterfall thinking. You never are done designing. You will almost always have to do a fairly major redesign the first time a real client tries to use your class. Thereafter every now and then you'll discover edge cases of client use that require (or would greatly benifit by) an extra new call or two, or a slightly different approach to all the calls.

Upvotes: 2

Related Questions