• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why to write an interface for every class? What kind of pattern is it?  RSS feed

 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all, I am working on a project where I see an many user defined interfaces and a classes implementing those interfaces. Why is it like that? Why cant I write the class directly?

Is it something related to some kind of design pattern?

Thank you, good day.
 
Tim Moores
Saloon Keeper
Posts: 4024
94
  • Likes 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Writing an interface for every class would be an anti-pattern. I have never seen (or heard about) anyone do that. You most certainly can write a class that does not implement any interface.

Just because one project is done in a certain way does not mean that that is a good way of doing things. If you're curious why it is done that way on your project, ask the other developers.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
chaitanya karthikk wrote:Hi all, I am working on a project where I see an many user defined interfaces and a classes implementing those interfaces. Why is it like that? Why cant I write the class directly?
Is it something related to some kind of design pattern?

Not specifically, but I suspect it may be somebody taking the advice given by the GoF to "program to an interface, not an implementation" to the nth degree.

As with most pieces of advice, they're generally good rules of thumb; but you're also supposed to use some judgment.

Winston
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
chaitanya karthikk wrote:Hi all, I am working on a project where I see an many user defined interfaces and a classes implementing those interfaces. Why is it like that? Why cant I write the class directly?
Is it something related to some kind of design pattern?

Not specifically, but I suspect it may be somebody taking the advice given by the GoF to "program to an interface, not an implementation" to the nth degree.

As with most pieces of advice, they're generally good rules of thumb; but you're also supposed to use some judgment.

Winston

Actually I am working on a spring application. I saw this approach there. I don't know why they are having interfaces and classes implementing those interfaces. I thought that this thing has nothing to do with spring, and it is purely some pattern, say design or behavior. So I asked.
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I discussed with some friend of mine and he said that if you are going to use an interface and implement it then you have few advantages which I dint understand properly. Let me explain.

Suppose I am a developer working on DAO layer in India and other is working on Service layer in the same project from US. The developer in US does not know what name I am giving for the DAO class so that he can create an instance of it. Since he is not sure he will simply do autowiring and use the methods declared in the interface. This is what he said.

Then I got this doubt, when using autowiring also I have to mention the bean with a DAO class name in my application configuration file. I dint try to argue with him.

Then I got another doubt, and asked him. What if there is no spring framework in the same situation. He simply replied it is only possible using the reflection api. At run time we have to know the DAO class name and initialize the class and use the methods. I again got confused, not with reflection api, but with the approach.

Can anyone please shed some light on this.

Thank you all in advance, good day
 
Junilu Lacar
Sheriff
Posts: 11477
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interfaces come in handy when used between application layers. This promotes loose coupling between the layers. For example, by defining how objects in different layers, e.g. Domain Service objects <--> Infrastructure Service objects (DAOs, for instance, or an object that connects to a Web Service), interact with each other, objects in each layer can be developed in isolation without having to worry about concrete implementations in the other layers. Interfaces make it easy to use mocking frameworks like Mokito to simulate how collaborators would behave in different scenarios, thus making it easier to write unit tests.

As someone mentioned before, you have to use common sense and good judgement. Don't just create interfaces blindly because doing so where there is no real reason or need to do so only adds unnecessary complexity.
 
Niall Loughnane
Ranch Hand
Posts: 209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
of course somebody could create earth given mars but would anybody want to?

A class should have a point in being :) every class can be constructed through rmi but they dont because as the saying goes - keep it simple!
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:Interfaces come in handy when used between application layers. This promotes loose coupling between the layers. For example, by defining how objects in different layers, e.g. Domain Service objects <--> Infrastructure Service objects (DAOs, for instance, or an object that connects to a Web Service), interact with each other, objects in each layer can be developed in isolation without having to worry about concrete implementations in the other layers. Interfaces make it easy to use mocking frameworks like Mokito to simulate how collaborators would behave in different scenarios, thus making it easier to write unit tests.

As someone mentioned before, you have to use common sense and good judgement. Don't just create interfaces blindly because doing so where there is no real reason or need to do so only adds unnecessary complexity.


I am unable to follow you, can you please explain with a small example if you don't mind.

Thank you, good day.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16057
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using interfaces can be a good idea exactly for the reason you mentioned: someone in India builds X, someone in the US builds component Y, and if Y needs to use X then it might be a good idea to specify an interface for component X, so that Y can program against that interface. It could also be useful for testing: to test Y, a mock implementation of interface X could be plugged in instead of the real implementation of X.

What the others are trying to say above is that if you make an interface for every class, without thinking if it has any purpose, then you're doing something wrong. For many classes it's not useful to define a separate interface with all the methods of the class; it just unnecessarily complicates things.
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:Using interfaces can be a good idea exactly for the reason you mentioned: someone in India builds X, someone in the US builds component Y, and if Y needs to use X then it might be a good idea to specify an interface for component X, so that Y can program against that interface. It could also be useful for testing: to test Y, a mock implementation of interface X could be plugged in instead of the real implementation of X.


How can I create a reference then?

InterfaceForX ifx = new ?();
 
John Jai
Rancher
Posts: 1776
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
InterfaceForX ifx = new <Implementation of InterfaceForX>();

Implementation of the interface of X can be Y (developed by someone who needs to use X as Jesper said).
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
John Jai wrote:InterfaceForX ifx = new <Implementation of InterfaceForX>();

Implementation of the interface of X can be Y (developed by someone who needs to use X as Jesper said).


In the example I quoted, someone is developing Service (Y) and someone is developing DAO (X), now in Service I want DAO instance, so in Service what should I write?

InferfaceForX ifx = new ?();

Can you please tell me now?
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
chaitanya karthikk wrote:
John Jai wrote:InterfaceForX ifx = new <Implementation of InterfaceForX>();

Implementation of the interface of X can be Y (developed by someone who needs to use X as Jesper said).


In the example I quoted, someone is developing Service (Y) and someone is developing DAO (X), now in Service I want DAO instance, so in Service what should I write?

InferfaceForX ifx = new ?();

Can you please tell me now?

You don't always have to specify that implementing class and create it using the new operator.
Typically you'll see some inversion of control where the implementing class does not need to be a compile time dependency but is supplied at runtime through a deployment environment configuration.
This allows the same code to be used in different environments where different dependencies are injected.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16057
88
Android IntelliJ IDE Java Scala Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You mentioned the Spring framework in one of your answers. Are you using that in your project?

One of the key features of the Spring framework is that it offers you dependency injection. This means that you don't write code like SomeInterface obj = new SomeImplOfInterface(); directly. Instead, you create for example a class that has a setter, and let the Spring framework call your setter method to inject the appropriate implementation of the interface. Which implementation is actually used is something that you specify in a configuration file for Spring (for example, an application context XML file).

One thing that is useful with this is that for testing ComponentY, some mock implementation of ComponentX can be set instead of the real ComponentX implementation.

For example, ComponentX could be some DAO that ComponentY needs to use. For testing, you could just use a fake DAO, to test if ComponentY calls ComponentX in the expected way.
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:You mentioned the Spring framework in one of your answers. Are you using that in your project?

One of the key features of the Spring framework is that it offers you dependency injection. This means that you don't write code like SomeInterface obj = new SomeImplOfInterface(); directly. Instead, you create for example a class that has a setter, and let the Spring framework call your setter method to inject the appropriate implementation of the interface. Which implementation is actually used is something that you specify in a configuration file for Spring (for example, an application context XML file).

One thing that is useful with this is that for testing ComponentY, some mock implementation of ComponentX can be set instead of the real ComponentX implementation.

For example, ComponentX could be some DAO that ComponentY needs to use. For testing, you could just use a fake DAO, to test if ComponentY calls ComponentX in the expected way.

I understood that when using spring, I need not use new operator. Spring IoC will take care of that.

But what if I don't have spring framework and want to achieve the same thing?
 
Matthew Brown
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, there are other dependency injection frameworks available. But you can use the general principle (the "dependency inversion principle") anyway. You can write your classes in the same way. The point is that if a class has a dependency on another class (like ComponentY has a dependency on ComponentX in Jesper's example) the dependency is passed in from outside, either using a setter method or via the constructor.

Then, if you're not using a framework, it's the responsibility of the code that creates the object to provide the dependency as well.
 
Jaikiran Pai
Sheriff
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To add to what Matthew mentioned, dependency injection doesn't have to be done by Spring. Infact it doesn't even need a framework. You might want to read this JavaRanch journal by Christophe, about dependency injection
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthew Brown wrote:Well, there are other dependency injection frameworks available. But you can use the general principle (the "dependency inversion principle") anyway. You can write your classes in the same way. The point is that if a class has a dependency on another class (like ComponentY has a dependency on ComponentX in Jesper's example) the dependency is passed in from outside, either using a setter method or via the constructor.

Then, if you're not using a framework, it's the responsibility of the code that creates the object to provide the dependency as well.

Do you mean the person who is writing Service Y has to create a dummy DAO X and test the functionality?

InterfaceForX ifx = new DummyImpl();

Do you mean this?
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jaikiran Pai wrote:To add to what Matthew mentioned, dependency injection doesn't have to be done by Spring. Infact it doesn't even need a framework. You might want to read this JavaRanch journal by Christophe, about dependency injection

Okay, I will take a look at it. Thank you Mr. Kiran.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16057
88
Android IntelliJ IDE Java Scala Spring
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
chaitanya karthikk wrote:Do you mean the person who is writing Service Y has to create a dummy DAO X and test the functionality?

Yes. For example, you could make a dummy DAO X which returns some fixed data, and in a unit test you can check if service Y deals with that data correctly.
 
Junilu Lacar
Sheriff
Posts: 11477
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a quick example:

Suppose you have a library system. You would like to have a way to search the entire library system for books based on Author, Subject, or Title. Now suppose you have worldwide, virtual library with multiple catalogs that you can search. To search by Author, you have to go to all available catalogs. Now say that each catalog can be accessed in many different ways: one via a Web Service, another via a database connection, another via XML files, etc. You don't want to worry about how each catalog actually goes about finding books. In fact, you can't possibly cover all the different ways a Catalog can be implemented. Don't worry, you don't have to! All you really need to know is know what methods you can use to do searches on a Catalog. So you define an interface. (Note: this may not be the best way to design this interface but for the sake of simplicity, we'll go with it for now)



Some of the concepts that are coming into play here are: loose coupling, separation of concerns, abstraction.

Now that you have a "contract" for the behavior of a Catalog, you don't have to worry about all those implementation specifics to develop something like this (again, may not be the best design but for simplicity sake, we'll go with it):

So how do you test this without the actual concrete Catalog implementations? Stop worrying about the actual implementations so much! Since you have a contract, you're going to assume the best: that any Catalog implementation you'll have in the end will behave correctly and in accordance with the contract. Now all you have to worry about is whether your search service works as you expect. So you create a few dummy Catalog implementations (Mokito is really good at this) that return some made-up books (your test data). When the real Catalog implementations are provided to you, you simply add them to the AuthorSearch service and it should still work. Dependency Injection and frameworks like Spring come into the picture here. You can inject the list of catalogs via the setCatalogs method using Spring.

This is the separation between layers that I referred to in my other post.

(Edit: <sigh> I wish there was a compiler check for code samples in this editor)
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot Mr. Lacar and all others who helped me understand and thanks again for patience.
 
chaitanya karthikk
Ranch Hand
Posts: 806
Java MySQL Database Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually what is this pattern called as? Is it called "Programming against interfaces" pattern?
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!