Why?  What are your arguments against an interface + final class?

Making Pipeline non final gets around this (and I can live with as a compromise), but that encourages developers to extend it with their own "features".

Let's say you are a developer using AG.  You have code which calls Pipeline.add(stuff) and you want it to throw an exception.

This is very easy (using Mockito for example):

mockedPipline = mock(Pipeline.class);
doThrow(new IllegalArgumentExcption()).when(mockedPipeline).add(params);

Our add method is never called, their tests for their code are not dependent on our code.

If the developer uses Easymock instead of Mockito (FSM help his sentient meat) he will have to use one  EasyMock class for interfaces and another EasyMock class for the concrete classes.

----- Original Message -----
From: "Daniel Passos" <daniel@passos.me>
To: "AeroGear Developer Mailing List" <aerogear-dev@lists.jboss.org>
Sent: Friday, November 9, 2012 7:31:33 AM
Subject: Re: [aerogear-dev] [Android] Interfaces on Pipeline, Datamanager,      and Authenticator


-1 to interface for Entry Points





On Fri, Nov 9, 2012 at 4:36 AM, Matthias Wessendorf < matzew@apache.org > wrote:



On Fri, Nov 9, 2012 at 5:04 AM, Douglas Campos < qmx@qmx.me > wrote:
>
> On Nov 9, 2012, at 1:46 AM, Summers Pittman wrote:
>
>> (See https://github.com/aerogear/aerogear-android/pull/33)[Yes it isn't coarsely separated, it is just a bunch of proof of concept stuff]
>>
>> Right now in ag-android Pipeline and DataManager are final and concrete. Authenticator is an interface implemented by the final class DefaultAuthenticator. I have coded up a proposal where I've (among other things) split the other classes up.
>>
>> Pros for Interface + final class:
>> Easier mocking for unit tests (thinking about users' unit tests not ours)
> I'm not sure if users really want to test the Pipeline - it probably makes more sense for them to just start testing from the Pipes - which have interfaces already
>

yeah, I was wondering the same . not sure about test for the framework
that I am using...


>> Better practice (is Josh Bloch is to be belived)
> meh, he is right 99% of the time, not always, and I disagree in this case
>
>>
>> Cons:
>> Pipeline et all are entry point classes and we shouldn't encourage our users to write their own
>> We can make Pipeline et all non-final to allow users to mock them for their tests.
> This sounds like the right compromise for me
>
>>
>> Thoughts from the list?
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> -- qmx
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev