2

It's good practice for a class' implementation to be defined by interfaces. If a class has any public methods that aren't covered by any interfaces then they have the potential to leak their implementation.

E.g. if class Foo has methods bar() and baz() but only bar() is covered by an interface then any use of baz() doesn't use an interface.

It feels like to get cleaner code it would make sense to either:

  • create extra interfaces if the class has to have those methods (eg a separate interface to cover the behavior of baz() above)
  • or ideally refactor (eg using more composition) so the class doesn't need to have so many methods (put baz() in another class)

Having methods not covered by an interface feels like a code smell. Or am I being unrealistic?

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
dave1010
  • 15,135
  • 7
  • 67
  • 64
  • Your Question looks like almost similar to this one : http://stackoverflow.com/questions/6533147/interface-advantages-in-java – Piyush Kukadiya Feb 28 '14 at 13:24
  • What exactly do you mean by "leak their implementation"? If a method is declared as public the rationale is to make it known to the world. If you don't want to expose the method, a different visibility modifier should be used. But I might have misunderstood the benefit of having each public method be covered by an interface. – Nils Göde Feb 28 '14 at 13:57
  • @NilsGöde - there is one benefit - the whole class is completely interchangable to another one, who implement same interface. However its very unlikely, if interface contains all methods of concrete class. – libik Feb 28 '14 at 13:59
  • An interface so big that creating a concrete class that implements it is difficult is definitely a code smell. Interfaces should be nice and small. – dave1010 Feb 28 '14 at 14:05
  • @libik: I think the question assumes there can be more than one interface that covers the public methods. – Nils Göde Feb 28 '14 at 17:19

3 Answers3

2

I consider it as "overusing" the interface.

Interface can give you access only to limited functionality, therefore it is good for gathering more classes with similar functionality into one List<Interface> and using them, for example.

Or if you want to keep loose coupling principle, you rather give another component some interface than the whole class(es).

Also some classes should have restricted access to another classes, which can be done with interfaces too.

However high cohesion principle (which is usually connected to loose coupling) does not prevent you from using class itself, if two classes are and should be "strong" connected to each other.

libik
  • 22,239
  • 9
  • 44
  • 87
  • The interface should give you limited access but also the class shouldn't violate the SRP. If the class does something extra to the behavior defined by the interface then the class seems like it could be doing too much. If 2 classes have high cohesion then it makes sense that they might not need to use interfaces but this still reduces testability. – dave1010 Feb 28 '14 at 13:44
  • Note: I'm against extending an interface to cover all public methods of a class. I'm more interested in either creating new interfaces if the class needs to have those methods, or (generally better) refactoring so the class uses more composition and doesn't need to have non-interfaced methods. – dave1010 Feb 28 '14 at 13:47
  • 1
    Having interface (almost) in every situation is not what it is good for and used for. If it is possible, usually you divide your program into components and each component communicate with others with public interfaces. Interface does not have to reflect one-by-one methods. – libik Feb 28 '14 at 13:50
  • There's definitely value in having interfaces for when components communicate on a holistic level. I think there's also some value in using interfaces for classes with high cohesion: they can be refactored and mocked for testing on a more granular level. Though perhaps in some cases the it isn't worth the trade off of coding overhead and duplication. – dave1010 Feb 28 '14 at 14:01
  • This : "it isn't worth the trade off of coding overhead" – libik Feb 28 '14 at 14:02
1

I don't think that's the purpose of interfaces. If you actually talk about the 'is-a' and 'has-a' relationship between classes, not necessarily a class needs to cover all public methods in interfaces. That's like taking the concept too far.

A class can have methods which describe it's behavior but then, there are some methods that do not exactly describe the classes' behavior but rather describe what else the class can do.

In case if a question arises about SRP regarding the 'can-do' behaviors, it is possible that the class can use a component to execute those behaviors rather than implementing within itself.

For e.g., I have a class DataGrid, why would I need to have an interface called IDataGrid which exposes all the public methods. But may be there is an additional functionality that the DataGrid can do, which is export the data. In that case I can have it implement IExportData, and implement the ExportData method, which in turn does not export the data but uses a component, say DataExportHelper, that actually does the job. The DataGrid only passes the data to the component.

I don't think SRP will be violated in the above example.

EDIT:

I am a .Net developer, so would like to give you and example from MS library classes. For e.g., the class System.Windows.Window does not implemnt any interface that has Close() method. And I don't see why it should be a part of any presenter.

Also, it is possible that something might look seem like a code smell but not necessarily it might be wrong. Code smell itself does not mean there is a problem but that there is a possibility of problem. I have never come across any principle or guideline in software design which mentions that all the public members of a class need to be exposed in some or the other interface. May be doing that just for the sake of it might be a bad design.

Shakti Prakash Singh
  • 2,414
  • 5
  • 35
  • 59
  • I'm against expanding an interface just so that more methods are covered. Using your example, my point is that it seems like a code smell if there are any methods in DataGrid that aren't covered by IDataGrid or IExportData (or any other interface it implements). If DataGrid has a new sendReport method then it should have a new interface that covers that. Can you give me an example of a method that doesn't describe its behavior, that wouldn't need an interface? – dave1010 Feb 28 '14 at 16:11
  • I can give you real examples. Check [System.Windows.Controls.DataGrid](http://msdn.microsoft.com/en-us/library/system.windows.controls.datagrid(v=vs.110).aspx) class in msdn. This class has methods like BeginEdit(), CancelEdit(), CommitEdit() etc which are not a part of any interface or parent class but describe the functionality of the DataGrid. – Shakti Prakash Singh Mar 04 '14 at 06:23
  • It sounds like the DataGrid here also behaves like a component that can have its data edited - maybe it should implement an interface like EditableComponent. – dave1010 Mar 04 '14 at 16:04
  • I added an explanation as a part of an answer. But I think it is a matter of debate and people generally choose what they are more comfortable with and what programming ideology they believe in. I can keep on giving examples when not to put a method and you can keep up with suggesting new interfaces to put those methods into. I don't think it's about correct/incorrect way of doing things but I strongly think about both usability and 'has-a/can-do' and 'is-a' relationship before using interfaces. – Shakti Prakash Singh Mar 07 '14 at 08:13
0

No, I would definitely not consider methods not covered by an interface a code smell.

It seems like this might be dependent on the object infrastructure you are building in, but in the infrastructures I'm familiar with, the real point of interfaces is to provide a manageable form of multiple inheritance. I consider the overuse of multiple inheritance a notable smell.

In .NET at least, abstract classes are explicitly the preferred construct for exposing abstraction (not interfaces). The .NET design guidelines say: Do favor defining classes over interfaces., with rationale described here http://msdn.microsoft.com/en-us/library/vstudio/ms229013(v=vs.100).aspx.

Even in COM (where any externally visible functionality had to be defined in an interface) there are perfectly good reasons to have non-exposed functions: limiting the visibility of implementation details. COM was originally defined in C (not C++) which lacked the richer set of access modifiers that newer languages have, but the concepts were there: published interface members were public, everything else was internal.

Burt_Harris
  • 6,415
  • 2
  • 29
  • 64
  • It sounds like the abstract class is used to define the interface, i.e. for all intents and purposes is is an interface. You'd type hint to the abstract class in the same way you'd type hint to an interface (which I think can be perfectly fine). To call public methods in a concrete class that aren't in the abstract class you have to type hint for the concrete class instead of the abstract class / interface. – dave1010 Jul 21 '14 at 12:24