-1 to interface for Entry Points<div><div><br></div><div><div><div class="gmail_quote">On Fri, Nov 9, 2012 at 4:36 AM, Matthias Wessendorf <span dir="ltr"><<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">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>
</div>yeah, I was wondering the same . not sure about test for the framework<br>
that I am using...<br>
<div class="im HOEnZb"><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>
</div><span class="HOEnZb"><font color="#888888">--<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>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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></div></div>