2

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)

so that, 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?

Improve this question
14
  • "I've a service that has [...] only one implementation" and "other modules need the contract to build proxys" are contradictory. Your case doesn't seem strong enough to warrant using Impl, but since you haven't provided any information on what the implementation does, no one can suggest anything worthwhile.
    – Vincent Savard
    Jan 14, 2019 at 14:46
  • @VincentSavard I've edited the question. The "proxy" is a remote invoker automatically build from the interface. There will not be another "real" implementation. The stock-service is only an example. We can assume that it only has one method getProductStock(productId) that makes a query to a database.
    – Tobías
    Jan 14, 2019 at 15:12
  • Then you got your name. You have a PostgresStockService, or whatever your DBMS is. You have an implementation which is tied to a particular service or a particular technology, therefore it makes sense to name it as such.
    – Vincent Savard
    Jan 14, 2019 at 15:24
  • arent there namespaces for this kimd of problem?
    – Ewan
    Jan 14, 2019 at 15:55
  • @VincentSavard I will think about it. Thinking about tied technology or architecture, probably I can find a discriminator.
    – Tobías
    Jan 14, 2019 at 16:00

1 Answer 1

Reset to default
4

Even if your service has only one implementation in the foreseeable future, think of some alternative way to implement it, to help you identify something special about your actual implementation. Then, use that special "something" to name it.

Failing that, use "stock-service" for the interface and "standard-stock-service" or "default-stock-service" for the implementation.

Improve this answer
2
  • Other options are 'Basic' or 'Simple' for general use case implementations. 'Implementation' or 'Impl' describes any concrete class.
    – JimmyJames
    Jan 14, 2019 at 15:30
  • Personally, this just feels like a workaround to avoid suffixing Impl. Prefixing Standard or Default does not describe in any way how the interface may behave or may be implemented. I'm sure there are some situations where it makes sense, but to me, it feels like a last resort option.
    – Vincent Savard
    Jan 14, 2019 at 15:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.