(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)

Better practice (is Josh Bloch is to be belived)

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.

Thoughts from the list? _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Fri, Nov 9, 2012 at 5:04 AM, Douglas Campos <qmx(a)qmx.me&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- qmx > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

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(a)passos.me&gt; To: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; 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(a)apache.org > wrote: On Fri, Nov 9, 2012 at 5:04 AM, Douglas Campos < qmx(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- qmx > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev