Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Coding to interface

 
Hardik Patel p
Ranch Hand
Posts: 40
Hibernate Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have seen many spring projects but I have noticed one thing common that is 'coding to interface'. I don't know why people are using interface. Please tell me why this is require and what is the benefit. please explain me what are the problem if we are not use 'coding to interface' and how interface overcome this problem.

sample :





for more detail http://www.beingjavaguys.com/2013/03/spring-hibernate-integration-tutorial.html

Thank you all.
 
Bill Gorder
Bartender
Posts: 1682
7
Android IntelliJ IDE Linux Mac OS X Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the 'code to an interface not an implementation' first really gained traction in the extremely popular GOF book on design patterns if I am not mistaken. There are lots of good reasons for it, however this is more of a design discussion than a Spring one, so I am going to add this to our Patterns forum as well.

Are you familiar with the GOF patterns? Understanding them will help you understand the benefits, as many pattern depend on this abstraction.

Here is a discussion on it:
http://www.artima.com/lejava/articles/designprinciples.html
 
Hardik Patel p
Ranch Hand
Posts: 40
Hibernate Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mr. Bill Gorder

There are many design pattern inside Gof. I don't know which method is of coding to interface. Please let me know I want to learn this quickly.

Thank you
Hardik
 
Junilu Lacar
Bartender
Pie
Posts: 7465
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did you read the article that Bill cited?
 
Hardik Patel p
Ranch Hand
Posts: 40
Hibernate Java Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes I read it 3 times, I not understood this point :

An interface distills the collaboration between objects. An interface is free from implementation details, and it defines the vocabulary of the collaboration. Once I understand the interfaces, I understand most of the system. Why? Because once I understand all the interfaces, I should be able to understand the vocabulary of the problem.


If we have good formatting then we can understand all the vocabulary. WHY WE GIVES LOAD TO OUR SERVER BY CREATING INTERFACE.

Please explain me with example

PLEASE, PLEASE, PLEASE help me I am very confuse. This topic is very important for me.

Thank you
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34178
340
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While it is important to have good vocabulary, that's hardly the primary use of an interface. Even in that article, Gamma talks about separating specification from implementation first.

As an example,
interface: BookDao
class: InMemoryBookDao

I can test my code using the BookDao. When the implementation later changes to OracleBookDao, I don't need to change any of the calling code. This makes my code far less brittle.

As far as load, don't worry. The JVM can handle interfaces just fine. They are such a tiny percentage of the load of memory that it isn't worth worrying about.
 
Junilu Lacar
Bartender
Pie
Posts: 7465
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only "load" I can imagine interfaces having on the runtime system is in loading its .class file. This, as Jeanne says, is hardly significant. Do not concern yourself too much with performance up front. Well-factored code is usually easier to performance tune anyway so you should worry about creating a well-factored, coherent design first.
 
Scott Shipp
Ranch Hand
Posts: 191
10
Eclipse IDE IntelliJ IDE Java Scala Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would call this "Interface Segregation Principle" which is the I in SOLID. I like this C2 wiki entry: C2 Wiki - Interface Segregation Principle
 
Junilu Lacar
Bartender
Pie
Posts: 7465
50
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Scott Shipp wrote:I would call this "Interface Segregation Principle" which is the I in SOLID. I like this C2 wiki entry: C2 Wiki - Interface Segregation Principle

Coding to an interface is actually more aligned with the "L", the Liskov Substitution Principle, than the Interface Segregation Principle. Coding to an interface helps make the code more flexible and abstract in that it is not coupled to a particular implementation but rather to the contract that the interface defines. You should be able to substitute one implemention for another without affecting the validity of your code.

The ISP has to do with having small and cohesive APIs rather than large, all-encompassing ones.
 
Jelle Klap
Bartender
Posts: 1951
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Coding to an interface is also an absolute must to achieve proper modularization, by cleanly separating the exposed public API from its implementation details. For instance, in an OSGi environment it's common practice to use separate bundles for each, and us declarative services to provide an implementation at runtime.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic