File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Other Application Frameworks and the fly likes Cost of programming to interfaces. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Cost of programming to interfaces." Watch "Cost of programming to interfaces." New topic

Cost of programming to interfaces.

Reghu Ram Thanumalayan
Ranch Hand

Joined: Oct 21, 2003
Posts: 193
Hello authors,
The following text is from the chapter 1 of your book.

If you are relying on EJBs to provide your application services, your components do not just depend on the EJB business interface. They are also responsible for retrieving these EJB objects from a directory, which entails a Java Naming and Directory Interface (JNDI) lookup and communicating with the bean�s EJBHome interface. This is not creating a decoupled application. This is tightly coupling your application to a specific implementation, namely EJB.
With Spring, your beans depend on collaborators through interfaces. Since there are no implementation-specific dependencies, Spring applications are very decoupled, testable, and easier to maintain. And because the Spring container is responsible for resolving the dependencies, the active service lookup that is involved in EJB is now out of the picture and the cost of programming to interfaces is minimized.

I had know that programming to interfaces is a good practice. But the last line says that, cost of programming to interfaces is minimized ? I am wondering what does that mean ? Why would we want to minimize the cost of programming to interfaces ?
[ April 15, 2005: Message edited by: Reghu Ram T ]

Cheers,<br />Reghu Ram T<br /> <br />SCJP 1.4 - 98 %, SCBCD 1.3 - 94 %, SCMAD 1.0 - 92 %
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
As you must be aware, all business interfaces must extend javax.ejb.EJBObject for remote interfaces and
javax.ejb.EJBLocalObject for local interfaces.

But in addition to specifying your business behaviour, your remote interface ends up inheriting other EJBObject methods and hence tightly coupled to EJB implementation. So this interface does not make sense outside EJB enviroment. I guess it is that disadvantage they are referring to.

In Spring , your interface would be having only your business methods and hence usable in every context.
Rudy Harianto
Ranch Hand

Joined: Dec 01, 2003
Posts: 94
In Spring , your interface would be having only your business methods and hence usable in every context.

is that means that no container callback methods, like create(), activate(), and so on?
so, how can we get the notification about what happened (listener-like mehtods) ?

what about bean life cycle in spring?

SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJA<br /> <br />blog: <a href="" target="_blank" rel="nofollow"></a>
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8927

Originally posted by Rudy Harianto:

what about bean life cycle in spring?

Craig Walls
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
Just to repeat what others have said...

In EJB, the interfaces you're programming to extend javax.ejb.* interfaces, coupling your code with the EJB framework. Also your EJB implementation class must extend javax.ejb.* classes. This forces you to write implementations of EJB lifecycle methods. Maybe these methods are useful to you, but in my experience they are left as empty implementations most of the time. But you still have to implement them because the spec says so.

What's worse is that the interfaces you write (home and remote/local) aren't even implemented by your implementation class! You write these interfaces to describe the methods your bean will provide, but then you write the implementation class and don't even get to implement those interfaces. That's always been a peculiar piece of the EJB spec to me.

In Spring your interfaces are just POJI (plain-old Java interfaces). You aren't forced to extend any other interface. And your implementation classes are just POJOs (no need to extend anything special, except in the case of the subframeworks--MVC, AOP, etc). No need to implement special lifecycle methods.

But, if you would like, you may still implement lifecycle methods. All you need to do is implement the BeanPostProcessor and/or BeanFactoryPostProcessor interfaces. And if you'd like access to your container, you just implement either BeanFactoryAware and/or ApplicationContextAware. Sure, at this point you're implementing Spring-specific interfaces--but it's a choice, not a mandate from the framework.

Spring in Action - Unleash POJO power in your applications!
Modular Java - Discover the secret weapon to modularity on the Java platform!
XDoclet in Action - Your complete guide to code generation with XDoclet.
Ryan Breidenbach

Joined: Jan 06, 2004
Posts: 18
I always saw the "reducing the cost of programming to interfaces" benefit in a different light. As the OP said, programming to interfaces is a good thing - it helps create decoupled applications. However, these interface dependencies have to be resolved to a concrete class somehow.

It is this "somehow" that has always been the problem for me. For non-EJB applications, I would typically create a custom factory that my objects would query to obtain the appropriate implementation of a given interface. This meant two things:

1. I had to actively look up my dependencies. I don't really like this approach. To me, it cluters up my classes with dependency look-ups that aren't really relevant to the specific duting of that class (enforcing business rules, persisting data, etc). Instead, I have junk like:


2. I had to figure out a way to configure my factory so it would know what the appropriate implementation class is for a given interface. Again, something I don't want to spend a lot of effort on - creating customizable factories.

Spring solves both of these issues. Its IoC approach elimates the need for active dependency resolution. Instead, my objects are *given* their dependant objects at run time. Cool!

More importantly, Spring already comes with a full-featured means to configure my "factory" - in this case the Spring container itself. No longer do I have to create custom factories, I just need to configure Spring with an XML file that is quite clear and intuitive.

In a nutshell, programming to interfaces *is* a good thing and Spring makes it easy to do this.
I agree. Here's the link:
subject: Cost of programming to interfaces.
It's not a secret anymore!