This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
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. HOST_NAME=xyz.com EMAILemail@example.com
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
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.)