4 ms·

You don't have to create an interface! One of my favourite interview questions is why do you use interfaces in Java? The majority of people I interviewed said t

You don't have to create an interface! One of my favourite interview questions is why do you use interfaces in Java? The majority of people I interviewed said that it a good design used interfaces and had nothing more to say. In code review if you have an interface and only one implementation I'd make you remove the interface - I call this the unnecessary Impl pattern since the class is traditionally called NameOfInterfaceImpl. Also you don't have to name property accessors getX() and setX() if you don't want to.

neeleshs 15y ago
Interfaces are a (or used to be ) huge help with unit tests with mocking etc. With better class mocking libraries now, that advantage has diminished.
VladRussian 15y ago
> In code review if you have an interface and only one implementation I'd make you remove the interface which changes the contract from "this component will accept and work with anything implementing this interface" to "this component will accept and work with anything of this class or inheriting from this class". And without multiple inheritance ... Do you feel the difference?
- reddiric 15y ago
  If there is only one implementation of an Interface, "anything implementing this Interface" and "anything of this class" are the same thing. Coding to an interface is a good thing - but it's the concept "interface", not necessarily the language feature named "Interface" that's important. If/when you have multiple concrete objects which share the same interface, it's trivial there to switch references from the concrete type to that of the Interface (you were coding to a conceptual interface representing a consistent abstraction of a single responsibility in the beginning so your Interface is interchangeable, correct?)
  - VladRussian 15y ago
    > If/when you have multiple concrete objects which share the same interface, it's trivial there to switch references from the concrete type to that of the Interface you're a lucky person that it has been trivial for you, your teammates and all the known and unknown clients of your code and components. I can only envy your experience.
    - timclark 15y ago
      Lots of Java development is carried out for internal business applications and like it or not they would typically be integrated with third parties using something like SOAP or a shared database. So in this type of application the choice of a concrete class over an interface probably has little impact on the known or unknown clients of your code. However, as you point out, if you are presenting a Java API to your known and unknown clients you had better think carefully about which abstractions you are going to expose and interfaces are probably going to be very helpful.
  - timclark 15y ago
    But you understand interfaces, you have just given an explanation. The candidates I interviewed didn't explain themselves at all, I think if a language has a feature you should be able to explain when and when not to use it. I think that all Java IDEs make it trivial to introduce an interface when it is required, so unless you are producing an API for consumption by a third party you should only introduce an interface when you have multiple implementations, or a third party can legitimately produce their own implementation, and not because you think you may have multiple implementations at sometime in the future. Also if you have a single implementation naming it InterfaceImpl is just lazy, you almost always have more information that you can use to name it, it might be a InterfaceUsingJdbc or an InterfaceFileBased for example.
devs1010 15y ago
I believe your line of thinking is wrong.. interfaces are meant to act as "interfaces" in the traditional definition of the word, they are for providing an interface between groupings of code (for lack of a better phrase) that are mean to be loosely coupled from one another. They are defining a contract between these groupings so that the one grouping that uses the object implementing the interface doesn't have intimate knowledge of the other grouping of code. For example, if a project uses a 3rd party library, of which only a few features are being used, yet they know they are most likely going to replace this with another 3rd party library at some point, it would make sense to write an interface that wraps around this library. Then, it is easier later on to replace the 3rd party library by simply writing a new implementation wrapper. I can understand that you don't like candidates not going into detail but I have worked on projects where using interfaces, even if there is not more than one implementation is still best practice as otherwise you are just hard-coupling your dependencies.

neeleshs 15y ago

Interfaces are a (or used to be ) huge help with unit tests with mocking etc. With better class mocking libraries now, that advantage has diminished.

VladRussian 15y ago

> In code review if you have an interface and only one implementation I'd make you remove the interface which changes the contract from "this component will accept and work with anything implementing this interface" to "this component will accept and work with anything of this class or inheriting from this class". And without multiple inheritance ... Do you feel the difference?

reddiric 15y ago
If there is only one implementation of an Interface, "anything implementing this Interface" and "anything of this class" are the same thing. Coding to an interface is a good thing - but it's the concept "interface", not necessarily the language feature named "Interface" that's important. If/when you have multiple concrete objects which share the same interface, it's trivial there to switch references from the concrete type to that of the Interface (you were coding to a conceptual interface representing a consistent abstraction of a single responsibility in the beginning so your Interface is interchangeable, correct?)
- VladRussian 15y ago
  > If/when you have multiple concrete objects which share the same interface, it's trivial there to switch references from the concrete type to that of the Interface you're a lucky person that it has been trivial for you, your teammates and all the known and unknown clients of your code and components. I can only envy your experience.
  - timclark 15y ago
    Lots of Java development is carried out for internal business applications and like it or not they would typically be integrated with third parties using something like SOAP or a shared database. So in this type of application the choice of a concrete class over an interface probably has little impact on the known or unknown clients of your code. However, as you point out, if you are presenting a Java API to your known and unknown clients you had better think carefully about which abstractions you are going to expose and interfaces are probably going to be very helpful.
- timclark 15y ago
  But you understand interfaces, you have just given an explanation. The candidates I interviewed didn't explain themselves at all, I think if a language has a feature you should be able to explain when and when not to use it. I think that all Java IDEs make it trivial to introduce an interface when it is required, so unless you are producing an API for consumption by a third party you should only introduce an interface when you have multiple implementations, or a third party can legitimately produce their own implementation, and not because you think you may have multiple implementations at sometime in the future. Also if you have a single implementation naming it InterfaceImpl is just lazy, you almost always have more information that you can use to name it, it might be a InterfaceUsingJdbc or an InterfaceFileBased for example.

devs1010 15y ago

I believe your line of thinking is wrong.. interfaces are meant to act as "interfaces" in the traditional definition of the word, they are for providing an interface between groupings of code (for lack of a better phrase) that are mean to be loosely coupled from one another. They are defining a contract between these groupings so that the one grouping that uses the object implementing the interface doesn't have intimate knowledge of the other grouping of code. For example, if a project uses a 3rd party library, of which only a few features are being used, yet they know they are most likely going to replace this with another 3rd party library at some point, it would make sense to write an interface that wraps around this library. Then, it is easier later on to replace the 3rd party library by simply writing a new implementation wrapper. I can understand that you don't like candidates not going into detail but I have worked on projects where using interfaces, even if there is not more than one implementation is still best practice as otherwise you are just hard-coupling your dependencies.