Re: [ljc] RFC - Default service implementation structure

From: Robert F.
Sent on: Tuesday, March 5, 2013 10:28 AM
Hi 

I assume that your interface defines some API which could be modified in the future or enhanced by new implementations. 

If you decide to implement this API in new way you will receive as bonus one additional implementation which you don't want to use any more. This implementation cannot be removed by excluding some impl jar, because it is part of api jar (another assumption). I'm not sure, but it is possible that this inner class leave some footprint in memory even if you don't use this inner class.

In my opinion you have less possibilities to control your implementation. In most cases I create interface and its default implementation in separate packages. I think it is disadvantage in this approach of writing services, but it give some flexibility in case of some changes.

Regards
Firek






2013/3/4 Wesley Hall <[address removed]>
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]


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 12/13 Jun 14

  • SkillsMatter

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

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

  • Packt Publishing

    A publishing company specializing on specific technologies and solutions

  • 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