addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramlinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [ljc] RFC - Default service implementation structure

From: Ged B.
Sent on: Wednesday, March 6, 2013 9:26 AM
How many of us are using CDI?  Reading this thread it strikes me just what a well put together spec it is.

For example, there is the @Qualifier annotation.  In section 2.3 of the spec it gives the example of a PaymentProcessor interface with an Synchronous and Asynchronous implementations:

class SynchronousPaymentProcessor implements PaymentProcessor {

class SynchronousPaymentProcessor implements PaymentProcessor {

You consume the interface like this:

@Inject @Synchronous PaymentProcessor paymentProcessor;

So you're no longer binding based on the interface name but on the annotations without the need of a separate configuration.  It's built in, you don't need a separate configuration file.

There there are the Producer methods, with these you to defer the implementation used to runtime.  Section 2.3.5 gives this example:

PaymentProcessor getPaymentProcessor(@Synchronous PaymentProcessor sync, @Asynchronous PaymentProcessor async) {
    return isSynchronous() ? sync : async;

If you're not familiar with CDI here are some good tutorials:
The Java tutorial does a good job of showing how, but doesn't really explain why.
I understand that the Spring annotations are similar, although I've never used them.



On 5 March[masked]:48, Colin Soho Cobra Vipurs <[address removed]> wrote:
One thing I've been playing around with lately is trying to make my
implementations *not* use the interface name at all and just describe
what they do, although I admit this can get quite hard.

In general I like my implementation to specify exactly *how* that
implements something, examples might be:



Often I find that if I can't find a good implementation name, it's a
sign that my design is perhaps wrong and maybe this class doesn't have
the responsibility I think it does.

Recently (well, not that recently) I've also not been a fan of
interfaces with names like *Service, *Repository, *Dao etc.  I find
these to lack the level of cohesion I really want and are not making
themselves amenable to use in Lambdas.  So if you were doing a typical
AccountRepository type class instead of:

   -> load
   -> save
   -> delete
   -> update

(or whatever things you use), I'd have 4 interfaces

AccountFetcher, AccountUpdater, AccountDeleter etc.  The
implementation itself can implement all 4 interfaces, but I definitely
like the way it lets me expose only the behaviour required to a using

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.

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