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: Wesley H.
Sent on: Tuesday, March 5, 2013 11:47 PM
Great thoughts so far folks, keep them coming. 

Neil, not to worry, this would not be the first time I have been accused of creating an 'abomination', you should see the results when I try to whip something up in the kitchen....

The issue of interfaces in the form of an SPI is something that Robert mentioned too, and leads me down an interesting train of thought related to different types of interface definition. In the case where I would be expecting third parties to implement these interfaces then, for sure, I would be splitting interface and implementations into distinct modules. There are concepts within build tools (Ivy's configuration springs to mind) that deal specifically with pulling in different implementation jars as dependencies etc...

In my case, the interfaces are there exclusively to support JDK AOP proxies, were it not for this restriction, I would likely not have them at all, access modifiers seem entirely suitable for differentiating between the public interface of the service and it's internals, and I can see absolutely no need to create, or even support, multiple implementations beyond mocking. 

Recently, I have found myself using (named) inner classes much more often, and I suspect this is because I have been playing around with scala which loosens (and even requires in the case of companion objects), more than one type definition per file. I have also being doing things (perhaps also abominations), like creating custom exceptions as static inner classes. It seems reasonable to consider custom exception types as a part of the interface. 

The end result of this flight of fancy is a somewhat larger file than we might ordinarily be used to in Java land, which contains all of the components related to a particular 'service'. The top level file being the service interface definition, and then a set of named inner classes of varying visibility defining custom exceptions, and other classes that relate specifically to the service itself. 

The AccountService becomes almost a package, but a functional package in the sense that at it's top level contains an interface description. 

All this said, I tend to float back and forward on this stuff and things that seemed like a good idea at one point, later seem a bit of a mess. With my professional projects I stick to pretty standard conventions, but all the more reason to play around with unconventional ideas in my off hours ;). 

For the 'growing object oriented software' people, yeah, I have read it and should have remembered that section actually. A company that I worked for previously had Steve Freeman come in and do a session on TDD with us, and I was my usual argumentative self, questioning everything. Fortunately, Steve is a patient man :). 

More fine grained interfaces actually seem like the right solution in consideration. I am going to continue to toy around though.... it's fun :)

Wes

On Tue, Mar 5, 2013 at 9:56 PM, Colin Soho Cobra Vipurs <[address removed]> wrote:
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).

Dan


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:

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.





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




--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
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

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'

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