When implementing interfaces, as a general rule,
Impl is evil. Ok, but is it evil in the following case?
I've a service that has (and probably will have) only one implementation. In such case, normally I don't need any interface. But, the "contract" must be shared with other modules because the service is exposed using
HttpInvokerServiceExporter. And the client, needs the interface to dynamically buid a proxy to do the remote invocation:
<bean id="stockService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"> <property name="serviceUrl" value="rmi://HOST:1199/StockService"/> <property name="serviceInterface" value="example.StockService"/> <!-- Interface needed here --> </bean>
This is the only reason why the api is shared. To expose the service. The client should not have the implementation classes as dependency.
In such scenario I'm thinking in a project layout like:
- stock-service (project) |- stock-service-api (shared interfaces module) \- stock-service-impl (implementation module)
other-service can have
stock-service-api as dependency.
Should, "-impl" naming also be avoided in this case? If yes, what would be a good alternative?