It's not a secret anymore!
The moose likes Other Application Frameworks and the fly likes Dependency (Using Spring) in interface? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Dependency (Using Spring) in interface?" Watch "Dependency (Using Spring) in interface?" New topic

Dependency (Using Spring) in interface?

Krishnappan Muthuraman

Joined: Feb 16, 2004
Posts: 22

While designing a buisness interface, I need to get email address, email host server etc. Should I use plain setter methods in an interface?

Or Is there any best approach to tackle this approach? Or just don't expose these configurable parameters in interfaces? But have them in the class which implements that interface?

Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Is there a possibility that the configuration parameters will change at runtime? then having setters makes sense.
Is there a need for the clients of the interface to access these properties? If no then dont add it to the interface. Let the implementation class handle it. If the number of config properties grow, the interface might start to look ugly.
If different configuration parameters would be needed for different implementation of the interface , then let the constructor of the implementation class accept say java.util.Properties. You can use Spring constructor injection and set up the properties instance through Spring config file.

and so on.

You can even have a no-arg constructor that reads all these properties from a .properties file if not supplied through the other constructor.

You can even allow access to the properties instance through say

Properties getConfiguration();

Craig Walls
Ranch Hand

Joined: Sep 19, 2003
Posts: 335
Originally posted by Krishnappan Muthuraman:
While designing a buisness interface, I need to get email address, email host server etc. Should I use plain setter methods in an interface?

Karthik gave a really good answer to this question, but let me reemphasize one point:

Do not put any methods into an interface that will not ultimately be used by the client of that interface. This includes setter methods. Almost invariably, the setter methods are used by the container (Spring) to configure the bean. By the time the client gets the bean, the container should be ready to use and the client has no need to call the setter methods. Moreover, it has no business calling those setter methods.

The setter methods are an implementation detail. The purpose of an interface is to hide implementation details from the client of the bean and only expose those methods that the client needs to use.

One more thought: If you do expose the setter methods in the interface for your bean and your bean is a singleton (the default in Spring), then the client of that bean could change the configuration of that bean for all other clients thereafter. This is probably not the desired effect and could potentially lead to hard-to-find bugs.

Moral of the story: Keep your interfaces as small as possible. (Or, don't give your bean clients any more power than they need.)

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.
I agree. Here's the link:
subject: Dependency (Using Spring) in interface?
jQuery in Action, 3rd edition