Is the number of inherited interfaces on an object a code smell?

Question

I've got an object (well 3 similar objects) that inherits from 6 interfaces:

public class PaperContract : 
    IDocument, 
    ICanSell, 
    IPrintable, 
    INotifyPropertyChanged, 
    IDataErrorInfo, 
    ISerializeable

The first signifies that this is a document which has properties for the file format it gets saved to and other stuff that makes it to conform to legacy practices that had to stay consistent with the paper documents this is replacing.

The second signifies that the document has financial info on it.

The third signifies that this document can be printed (seems obvious).

And the rest should be fairly obvious, databinding for winforms and serializing because the app is a sometimes-connected app.

I'm wondering if this is a sign that the object is defying the SRP, but at the same time, I don't want object explosion by splitting the class up into a million smaller sub-classes.

Answer 1

While I wouldn't say that the absolute number of interfaces would be a code smell, it looks like this object is on its way to becoming a dreaded God Object that contains a lot of information about a contract - how to print it, format it, data bind it, and serialize it. You couldn't use a PaperContractDataBinder, PageContractSerializer, PaperContractFormatter, etc?

The SRP directly relates to small object explosion. Done correctly, you get lots of smaller, more focused classes that do a few very tightly coupled things.

Answer 2

It really depends.

In managed code I would say yes this is definitely a sign of code smell. There is nothing inherently wrong with a class implementing a lot of interfaces but it can be a sign of an object that should split up responsibilities. An example a valid case would be certain collection classes, like Dictionary<TKey,TValue> which implement a lot of interfaces due to the number of scenarios it can validly fill.

In COM programming this unfortunately is how a lot of code is developed. IME, it's common in COM programming for a particular object to be expected to implement a host of COM interfaces in order to achieve full functionality. Especially in applications which maintain APIs accross many releases and add new APIs by adding new interfaces. This forces the author of the object into this model.

Answer 3

The question to ask is 'is this interface used to provide polymorphism?'

For example; ISerializable is used to allow the serialization system to treat all classes the same (all cast to ISerializable). IDataErrorInfo is used to allow data binding to treat all classes the same to display error messages. INotifyPropertyChanged is used to allow data binding to treat all classes the same to synchronize data.

Is IPrintable used to treat several classes the same way? What about ICanSell?

There is one architectural school of thought that states that classes should have lots of interfaces if they are used by many subsystems\services. This allows a level of decoupling between the services and the classes.