align-toparrow-leftarrow-rightbackbellblockcalendarcamerachatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-crosscrosseditfacebookglobegoogleimagesinstagramlocation-pinmagnifying-glassmailmoremuplabelShape 3 + Rectangle 1outlookpersonplusImported LayersImported LayersImported Layersshieldstartwitteryahoo

Re: [ljc] RFC - Default service implementation structure

From: James S.
Sent on: Tuesday, March 5, 2013 10:49 PM
On 5 March[masked]:56, Neil Bartlett <[address removed]> wrote:
My answer is biased by my experience in OSGi and preference for the service-oriented style that OSGi encourages.

Interfaces must be kept separate from implementations: at the very least in separate packages, and perhaps in separate modules. This is because interfaces -- which are APIs or contracts -- evolve at a very different rate from implementations. APIs can only be evolved in agreement with other consumers or providers of those APIs, so changing them is something you do very cautiously. On the other hand implementations change all the time, e.g. with every bugfix. Coupling them together forces you to frequently re-release APIs that haven't actually changed. Though if you have disciplined, granular versioning then this isn't necessarily a problem.
I don't tend to go this far, but I do like to make implementation classes package-private.  I use a static factory method that returns the interface to obtain a reference to the implementation without exposing any implementation details.

Implementation class names are irrelevant. They are private inside my module, nobody will ever see them, so who cares?
They should be irrelevant to the consumer of the API, but I'd hope that /you/ care, and anyone else that has to read your implementation code cares :-)

It's rare to come across a service interface where you cannot imagine alternative implementations existing. If there really is only one way to implement something, then what you have is a utility rather than a service, and in this case I would just make it a simple concrete class. Arguably you might want to take a copy of that class into each module that uses it, in order to avoid cross-module dependencies on implementation code.

For these reasons -- and additionally for aesthetic reasons that I acknowledge are purely aesthetic -- I think that your idea of nesting a default implementation inside the interface is an utter abomination.
The only time I do this is for noop implementations.

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

  • Craft Rebellion

    Your choice of fresh craft beer, delivered. For 10% off use ‘LJC'

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy