• Post Reply Bookmark Topic Watch Topic
  • New Topic

Implementing an interface from a framework vs simple java interface  RSS feed

 
shivang sarawagi
Ranch Hand
Posts: 159
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This concept is unclear with me.

I have worked on several frameworks for an instance Spring. To implement a feature we always implement some interfaces provided by the framework.

For an instance if I have to create a custom scope in Spring, my class implements a org.springframework.beans.factory.config.Scope interface. Which has some predefined low level functionality which helps in defining a custom scope for a bean.

Whereas in Java I read an interface is just a declaration which classes can implement & define their own functionality. The methods of an interface have no predefined functionality.


The methods here don't have any functionality. They are just declared.

Can anyone explain this discrepancy in the concept? How does the framework put some predefined functionality with interface methods?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
shivang sarawagi wrote:How does the framework put some predefined functionality with interface methods?


You answered your own question:

To implement a feature we always implement some interfaces provided by the framework.


You provide the implementation.

The interface is just a contract that you will provide the functionality.

In some cases, if you fail to provide an implementation, the framework may provide its own using an implementing class of its own as a default.
 
Jayesh A Lalwani
Rancher
Posts: 2762
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An interface at the very basic level is a bunch of methods that a class has to implement. There are many ways to use an interface. By far the most common use of an interface is to define a "contract". It's establishing what a class that implements that interface MUST do. Basically, it's just like a legal contract. It tells whoever is using your class what your class will do without exposing the inner workings of the class.

Now, when you are working with a framework, many times there are
a) interfaces that the framework implements
For example, the ApplicationContext interface itself. This is an interface that the Spring framwork implements. Internally, you have several classes that implement the interface. You as a client don't care about what those classes are or what they do (except during initializing). When you use Spring , you use it through the ApplicationContext interface. This interface establishes in very clear terms what the class that implements the interface can do. It's a contract that Spring provides to you

The advantage of using interfaces like this is that it isolates Spring's inner workings from your code. You need to call Spring, but you don't want to change when the inner workings of Spring changes. So, you call the interface

b) Interfaces that you have to implement
Spring don't have too much of these anymore because it's moving towards everything using annotations. FactoryBean is an example. But you might not be familiar with it. A more familiar example is outside of Spring:- javax.servlet.Servlet. Basically, if you have to iplement a Servlet, you have to implement a Servlet interface, and that's your contract with the web container. You cannot have a servlet unless you implement all the methods defined in the interface.

Here you are isolating your code from the framework. It's the exact same thing as a) but in the opposite direction. Spring/Webcontainer needs to call you but doesn't want to change when your code changes. So, it calls an interface that you have implemented

c) Interfaces that you can implement to extend the functionality of the framework

Scope interface in the OP is an example. Spring provides some functionality, and allows you to extend that functionality by implementing some interfaces. In this case the interface defines what the implementation of the extendion must do so that it can work with Spring.

These are few of the common uses. There are many more, and people are coming up with differrent ways to use interfaces*. Main thing to remember is that the whole concept of an "interface" is very simple, and yet very flexible. It's power lies in it's simplicity and flexibility.

* For example the Spring Data thing that came up recently. That's a completely new use of interface. You are using an interface to tell Spring what code to generate for you. Whoa! I can't even begin to classify it
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!