[aerogear-dev] [Android] Interfaces on Pipeline, Datamanager, and Authenticator

[Summers Pittman]

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 at passos.me>
To: "AeroGear Developer Mailing List" <aerogear-dev at 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 at apache.org > wrote: 



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


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