0

Is it generally considered a good practice to have every single class (excluding domain models) of your application based off of an interface? Even if the class is called only within your package?

Update: Based on the comments, here is a sample scenario I can think of, where I feel it would had been good to have classes based off an interface.

enter image description here

A Calculator class within my parent package, does some calculations and uses another class (Printer) to print out the results, to a file system. Suppose the Calculator class is public, Printer class has package protection. Now what if I want the Printer to send the result over HTTP instead of writing it to the file system?

If the Printer class was based off of an interface, and if I was injecting Printer class using Spring. I could had swapped out the implementation with a new one very easily.

developer747
  • 15,419
  • 26
  • 93
  • 147
  • 6
    No, why should it? – Tom Feb 26 '16 at 00:19
  • Swapping the implementation is easier if you base it off of an interface. Also its more compatible with spring where you generally inject dependencies, as an implementation of an interface. – developer747 Feb 26 '16 at 00:21
  • How is swapping the implementation a problem if the class is only called within your package? How is dependency injection relevant for classes that are not implementation of services to depend on? – Thilo Feb 26 '16 at 00:22
  • 1
    the second rule of design is keeping things simple – Dmitry B. Feb 26 '16 at 00:24
  • @developer747 *"Swapping the implementation is easier if you base it off of an interface."* I wonder how often you swap base classes (like model classes [even though they often have an interface for the most common parts (like an `Identifiable` interface), I hope you don't also create interfaces for each single model class]). – Tom Feb 26 '16 at 00:25
  • Based on your edit, you could have a printer with various *strategies* as opposed to writing various types of printers. – ChiefTwoPencils Feb 26 '16 at 00:48
  • this kind of meets an example in my answer below. Your Calculator just needs somehow to print something, it shouldn't really care how to. in this case the Printer would be a good Interface candidate. – Ivo Feb 26 '16 at 00:52
  • This is design issue, but not one directly pertaining to interfaces. Why should a user of a calculator be required to print anything? It would be better to return a result to the caller than to couple the separate responsibilities of Calculations and Outputting. – Silas Reinagel Feb 26 '16 at 01:02

3 Answers3

1

Not at all.

Interfaces are best used where you plan to provide for various polymorphic implementations, or where you wish to invert dependencies for the purpose of unit testing.

Interfaces should only be created when necessary. They should be carefully designed.

Silas Reinagel
  • 4,155
  • 1
  • 21
  • 28
0

Its largely a design choice. In theory it is better to "code to interfaces" in practise to have everything implement an interface often leads to extra work and class called SomethingImpl the ~Impl being some what redundant given the implements keyword and not very descriptive of the implementation.

Gavin
  • 1,725
  • 21
  • 34
  • An interface is merely a formal statement of the contract for an API. The "extra work" you're talking about is the effort of laying out an API, a practice which down the road often improves maintainability, improves robustness, and makes code more readable. The idea that interfaces impose a high burden of redundant coding is not correct. – scottb Feb 26 '16 at 00:53
  • Interfaces will define an API. quite useful when you are in the functional design phase where you just want to specify the bindings. Haven't you defined the Printer as an Interface in the example above, you would either have different types of Calculators or use the Printer as a service. – Ivo Feb 26 '16 at 00:59
  • I expressed myself badly, I was think of the cases where interface are used on all class often leading to classes named ```MyInterfaceImpl``` this in my opinion is a burden to development. I do agree with you statements and wasn't try to suggest interface should never be used nor intentionally suggesting they are a burden. – Gavin Feb 26 '16 at 13:30
0

IMO Interfaces should be used when you clearly want to functionally specify what a class is supposed to do. Normally I'd create an Interface when I predict that at some point the class that contains the Interface will need a different Implementation. That same class doesn't really care how something will be done as long as its Interface knows what to do.

"Programming to an Interface" allows you to "plug" different Implementations at run time with Spring etc while the functional specification remains intact. Strategy Pattern as an example.

Also, two completely different classes (no inheritance) can implement a common interface if at some point is expected for them to perform the same action/ exhibit the same behaviour.

Although you could potentially extract an Interface out for any class, there is probably no reason to do so all the time.

Ivo
  • 450
  • 3
  • 18