On Mon, Oct 31, 2016 at 3:04 PM, Uvindra Dias Jayasinha <[email protected]> wrote:
> Hi Bhathiya, > > The issue you have highlighted(Avoid fat constructor) is addressed by > Google Guice, so you dont need to have multiple constructors[1] since Guice > will take care of building the object for you. Having an alternative > constructor like the above introduces 3 lines of code that is not unit > testable :) > > Please watch[2] for a demonstration of practical usage. > > [1] https://github.com/google/guice/wiki/GettingStarted > [2] https://www.youtube.com/watch?v=hBVJbzAagfs > > Spring too supports dependency injection (since its first release in early 2000s), anyone knows the differences between Spring and Guice? > On 31 October 2016 at 14:56, Bhathiya Jayasekara <[email protected]> > wrote: > >> Hi Uvindra, >> >> On Mon, Oct 31, 2016 at 1:54 PM, Uvindra Dias Jayasinha <[email protected] >> > wrote: >> >>> +architecture >>> >>> This initially began as an internal APIM discussion for avoiding hard >>> coded dependencies within the code we are writing for C5 to make them more >>> unit testable(Being able to do dependency injection[1]). But as suggested >>> by Akila I think this is a good thing to talk about publicly as all >>> products can benefit. >>> >>> Akila suggested using something like Google Juice[2] for this purpose. >>> Im +1 for using this. Would like to here your thoughts on this. >>> >>> [1] https://www.youtube.com/watch?v=IKD2-MAkXyQ >>> [2] https://github.com/google/guice >>> >>> >>> On 31 October 2016 at 13:06, Uvindra Dias Jayasinha <[email protected]> >>> wrote: >>> >>>> >>>> >>>>> *The solution* >>>>>> Pass an instance of the interface to the heavy weight resource as a >>>>>> constructor parameter to the class that needs to use it. So in this case >>>>>> it >>>>>> should be, >>>>>> >>>>>> public APIConsumerImpl(ApiDAO apiDAO, ApplicationDAO appDAO, >>>>>> APISubscriptionDAO apiSubscriptionDAO) { >>>>>> this.apiDAO = apiDAO; >>>>>> this.appDAO = appDAO; >>>>>> this.apiSubscriptionDAO = apiSubscriptionDAO; >>>>>> } >>>>>> >>>>>> Passing it this way means we can now provide a mock implementation of >>>>>> the DOA interfaces when constructing the Consumer and Provider classes >>>>>> using a library such as mockito[1] and easily write unit tests. >>>>>> >>>>> >> +1 for above constructor to be used in unit tests. But I don't think we >> can use the same for real use. For that, we can have a default constructor >> as well, so that clients don't need to worry about injecting DAO >> dependencies. >> >> public APIConsumerImpl() { >> this.apiDAO = DAOFactory.getApiDAO(); >> this.appDAO = DAOFactory.getAppDAO(); >> this.apiSubscriptionDAO = DAOFactory.getSubscriptionDAO(); >> } >> >> Thanks, >> >> -- >> *Bhathiya Jayasekara* >> *Senior Software Engineer,* >> *WSO2 inc., http://wso2.com <http://wso2.com>* >> >> *Phone: +94715478185 <%2B94715478185>* >> *LinkedIn: http://www.linkedin.com/in/bhathiyaj >> <http://www.linkedin.com/in/bhathiyaj>* >> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* >> *Blog: http://movingaheadblog.blogspot.com >> <http://movingaheadblog.blogspot.com/>* >> > > > > -- > Regards, > Uvindra > > Mobile: 777733962 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sajith Kariyawasam *Associate Tech Lead* *WSO2 Inc.; http://wso2.com <http://wso2.com/>* *Committer and PMC member, Apache Stratos * *AMIE (SL)* *Mobile: 0772269575*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
