<font color="#222222" face="arial, sans-serif">Only to clarify. I'm against interface but not to turn on Entry Point on non final class.</font><br><div><font color="#222222" face="arial, sans-serif"><br></font></div><div>
<font color="#222222" face="arial, sans-serif">I can not imagine the need for interfaces in our entry points. If it's only for testing, I'd better turn on non final.</font></div><div><font color="#222222" face="arial, sans-serif"><br>
</font></div><div><font color="#222222" face="arial, sans-serif">To me that and enough power to create mocks and extends them.</font></div><div><font color="#222222" face="arial, sans-serif"><br></font></div><div><div class="gmail_quote">
On Fri, Nov 9, 2012 at 11:18 AM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why? What are your arguments against an interface + final class?<br>
<br>
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".<br>
<br>
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.<br>
<br>
This is very easy (using Mockito for example):<br>
<br>
mockedPipline = mock(Pipeline.class);<br>
doThrow(new IllegalArgumentExcption()).when(mockedPipeline).add(params);<br>
<br>
Our add method is never called, their tests for their code are not dependent on our code.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
----- Original Message -----<br>
From: "Daniel Passos" <<a href="mailto:daniel@passos.me">daniel@passos.me</a>><br>
To: "AeroGear Developer Mailing List" <<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a>><br>
Sent: Friday, November 9, 2012 7:31:33 AM<br>
Subject: Re: [aerogear-dev] [Android] Interfaces on Pipeline, Datamanager, and Authenticator<br>
<br>
<br>
-1 to interface for Entry Points<br>
<br>
<br>
<br>
<br>
<br>
On Fri, Nov 9, 2012 at 4:36 AM, Matthias Wessendorf < <a href="mailto:matzew@apache.org">matzew@apache.org</a> > wrote:<br>
<br>
<br>
<br>
On Fri, Nov 9, 2012 at 5:04 AM, Douglas Campos < <a href="mailto:qmx@qmx.me">qmx@qmx.me</a> > wrote:<br>
><br>
> On Nov 9, 2012, at 1:46 AM, Summers Pittman wrote:<br>
><br>
>> (See <a href="https://github.com/aerogear/aerogear-android/pull/33)[Yes" target="_blank">https://github.com/aerogear/aerogear-android/pull/33)[Yes</a> it isn't coarsely separated, it is just a bunch of proof of concept stuff]<br>
>><br>
>> 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.<br>
>><br>
>> Pros for Interface + final class:<br>
>> Easier mocking for unit tests (thinking about users' unit tests not ours)<br>
> 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<br>
><br>
<br>
yeah, I was wondering the same . not sure about test for the framework<br>
that I am using...<br>
<br>
<br>
>> Better practice (is Josh Bloch is to be belived)<br>
> meh, he is right 99% of the time, not always, and I disagree in this case<br>
><br>
>><br>
>> Cons:<br>
>> Pipeline et all are entry point classes and we shouldn't encourage our users to write their own<br>
>> We can make Pipeline et all non-final to allow users to mock them for their tests.<br>
> This sounds like the right compromise for me<br>
><br>
>><br>
>> Thoughts from the list?<br>
>> _______________________________________________<br>
>> aerogear-dev mailing list<br>
>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
> -- qmx<br>
><br>
><br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
<br>
--<br>
Matthias Wessendorf<br>
<br>
blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br></div>