7:18 a.m.
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>
To: "AeroGear Developer Mailing List" <aerogear-dev(a)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(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