addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1launch-new-window--smalllight-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

Re: [ljc] RFC - Default service implementation structure

From: user 7.
Sent on: Tuesday, March 5, 2013 1:36 PM
Good afternoon!

Another interesting conversation, Wes. Personally defaults are things I leave to the configuration or highest level layer and keep it clear of any API or implementation code. 

I really like Colin's approach of breaking up all-in-one boxes into distinct API's, after all a repository is one unit because it is convenient to keep the methods all together when they share a datasource but this is a fabricated restriction. Also, like Colin, I like the fact long and horrendous names induce you to improve the systems decomposability. 

So for your example I would have an AccountCreator interface which is really simple and just has the single method signature and an AccountService that implements this and possibly other interfaces, but I would be on the constant look out for better ways to decompose and recompose this functionality to minimize irrelevant dependencies and restrictions.

Stuart


On Tue, Mar 5, 2013 at 12:48 PM, 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:

RedisBackedAccountService
MySqlBackedAccountService

etc.

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:

AccountRepository
   -> 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
class.

Sorry, waffled on a bit there!

On Mon, Mar 4, 2013 at 11:25 AM, Wesley Hall <[address removed]> wrote:
> Hello folks,
>
> I have a little issue that I am sure has crossed the minds of a few
> folks here and thought I would open it up for comments.
>
> I am currently working on one of my little toy projects. I usually
> have at least one of these on the go at any given point as it allows
> me to play with new versions of libraries and technologies and also
> lets me develop some of my ideas in terms of structure and layout.
>
> Once again, I am finding myself visiting the age old problem of
> service interfaces with single implementations. There seems to be
> quite a few ideas on how to deal with this. Some say not to use an
> interface at all and just have the implementation class, some say to
> use an interface, and then there are suggestions for the naming of the
> implementation class, <Interface>Impl? Default<Interface>? Try really
> hard to come up with a prefix or suffix that is less generic?
>
> Over the years I have flitted back and forward between these options,
> never really finding an answer that was all that satisfactory to me.
> Not using an interface always seems the tidiest in terms of code
> structure, but I find that I run into issues around things like AOP
> proxies and having to use cglib proxies rather than JDK ones, which
> adds a lot of complexity and seems to outright break some things.
>
> *Impl and Default* seems like a bit of a cop-out, and seem (Impl
> especially) as a bit of a tautology.
>
> Coming up with a more specific name seems OK but I sometimes struggle
> to do this. My services generally use spring, but 'SpringXyzService',
> seems a bit crappy too, other than this there is usually nothing much
> to distinguish them. They are simply the pretty bog-standard
> implementation of the required interface.
>
> On my new project, I have been trying something a little different,
> which I think I quite like but is perhaps a little unconventional.
>
> I have been creating the 'Default' implementation of the interface as
> a package scope inner class within the interface definition itself.
> Like this...
>
> public interface AccountService {
>
>    Account createAccount(String email);
>
>    @Service
>    class Default implements AccountService {
>
>        private Collaborator collaborator;
>
>        Default(Collaborator collaborator) {
>            this.collaborator = collaborator;
>        }
>
>        public Account createAccount(String email) {
>            //Implementation here
>        }
>    }
> }
>
> This kind of thing seems to work functionally, allows for alternative
> implementations either by creating another implementation of the
> AccountService interface or even by extending the default
> implementation and my unit tests have things like this...
>
> AccountService accountService = new AccountService.Default(mockCollaborator);
>
> Which actually looks quite pretty to my eyes.
>
> I appreciate that it is all style really, but I am interested if
> anyone has any thoughts, do you use a standard that I haven't
> mentioned here? Do you have any major objection to my new experimental
> approach (either stylistically or because you happen to know it is
> going to break some feature of some important library)?
>
> Keen to hear any thoughts that anybody has.
>
> Regards
>
> Wes
>
>
>
>
> --
> Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
> http://www.meetup.com/Londonjavacommunity/
> This message was sent by Wesley Hall ([address removed]) from LJC - London Java Community.
> To learn more about Wesley Hall, visit his/her member profile: http://www.meetup.com/Londonjavacommunity/members/15396461/
> Set my mailing list to email me
>
> As they are sent
> http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=1
>
> In one daily email
> http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=2
>
> Don't send me mailing list messages
> http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=0
> Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]
>



--
Maybe she awoke to see the roommate's boyfriend swinging from the
chandelier wearing a boar's head.

Something which you, I, and everyone else would call "Tuesday", of course.




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
http://www.meetup.com/Londonjavacommunity/
This message was sent by Colin Soho Cobra Vipurs ([address removed]) from LJC - London Java Community.
To learn more about Colin Soho Cobra Vipurs, visit his/her member profile: http://www.meetup.com/Londonjavacommunity/members/12529139/
Set my mailing list to email me

As they are sent
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=1

In one daily email
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=2

Don't send me mailing list messages
http://www.meetup.com/Londonjavacommunity/list_prefs/?pref=0
Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]


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