addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcredit-cardcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobe--smallglobegmailgooglegroupshelp-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: Colin V.
Sent on: Tuesday, March 5, 2013 2:06 PM
It's more than likely that's where I got it from as I consider that book to be my current "bible".

If anyone hasn't read it, do so!

On Tue, Mar 5, 2013 at 1:57 PM, Dan Haywood <[address removed]> wrote:
+1 on that.

That's pretty much identical advice to that found in the GOOS ("Growing Object Oriented Software") book (highly recommended if you've not read it).


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

Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Dan Haywood ([address removed]) from LJC - London Java Community.
To learn more about Dan Haywood, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

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.

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