Ok lets forget about the term "DI"(seems to have negative connotations)
Lets speak in terms of OOP principles. Example: Class *Foo* needs to make decisions on retrieved data. Class *DAO* retrieves the data from the database. In the end *Foo* will use *DAO* to get the data it needs. If I create an instance of *DAO* inside the* Foo *class, I cannot unit test *Foo* without configuring a real database. I'm concerned about unit testing *Foo* and not *DAO*. But having *DAO* as a direct "dependency" in my code has meant that now I need to do an integration test to achieve what I could have done through a unit test. But if *Foo* class uses an Interface to the *DAO* class instead(via *Foo*'s constructor), I can mock the *DAOface* Interface and write a unit test for *Foo* without configuring a real database. *Foo* does not need to know the implementation details of the *DAOface* Interface(Encapsulation) and it acts as an abstraction layer for the real concrete implementation *DAO* class. At runtime a factory class can construct *Foo* by passing the *DAO* class(the implementation of the *DAOface* Interface) as its constructor parameter(injecting). So we have used good Encapsulation and Abstraction principles to help us do testing more easily, that's all there is to it really. On 3 November 2016 at 17:15, Ruwan Abeykoon <[email protected]> wrote: > Hi Manu, > Could you please provide a reference as Google used DI for platform > development (not an app or feature development). > > >>We should use DI, it makes code more understandable and testable. > No, we need only follow few OOP concepts correctly to make code more > understandable and testable. Let me know a concrete example of non testable > code which follow the first four OOP principles correctly. > > > Cheers, > Ruwan > > On Thu, Nov 3, 2016 at 1:39 PM, Uvindra Dias Jayasinha <[email protected]> > wrote: > >> HI Ruwan, >> >> The source you mentioned above supports what I'm proposing, the main >> reason to use DI is to make testing practically possible. We suffered >> previously because we couldn't do this. >> >> I did do some research on both Spring and Guice and as you said there are >> some practical issues with using these sometime(not unlike issues we face >> with OSGi). So maybe there is an argument for not using a particular >> framework/library for this purpose due to the cons that might be introduced. >> >> But to be clear, using this as a design pattern is a must. I doesn't >> matter what you call it, DI or something else. Designing classes to have >> hard dependencies is the way to ensure that unit testing is not a viable >> option. All DI proposes is that you don't do this. I have personally used >> this pattern in other languages without the help of any framework and have >> benefited greatly in being able to test code more thoroughly. >> >> >> On 3 November 2016 at 13:01, Ruwan Abeykoon <[email protected]> wrote: >> >>> Hi Uvindra, >>> DI is good for rapid development of specific applications, by taking >>> various readymade components. IMO DI pattern was popularized due to .Net >>> way of doing things. >>> There are many practical issues with DI, and as a platform provider, we >>> should not use DI on our platform. We can be a DI container for our >>> extensions, and it is a different story. >>> >>> Please see [1], [2] for not using DI. Having used Spring extensively >>> couple of years back, I would recommend steer away from DI while building >>> our platforms. >>> >>> [1] http://www.tonymarston.net/php-mysql/dependency-injectio >>> n-is-evil.html >>> [2] http://www.yegor256.com/2014/10/03/di-containers-are-evil.html >>> >>> Cheers, >>> Ruwan >>> >>> On Thu, Nov 3, 2016 at 12:01 PM, Uvindra Dias Jayasinha < >>> [email protected]> wrote: >>> >>>> I think there is a misunderstanding on what I have meant by DI in this >>>> case. >>>> >>>> OSGi addresses runtime wiring of components. What I mean by DI here is >>>> its application as a design pattern[1]. This is not about unit testing the >>>> DAO itself. Its about unit testing other components that use the DAO. >>>> >>>> You dont need any frameworks for doing DI actually because its a design >>>> pattern. We are currently doing it by hand. A framework would just make it >>>> slightly easier to manage but its not essential. If we are serious about >>>> testing we need to take DI into consideration when designing our classes. >>>> >>>> [1] http://martinfowler.com/articles/dipInTheWild.html >>>> >>>> On 1 November 2016 at 18:42, Ruwan Abeykoon <[email protected]> wrote: >>>> >>>>> Hi All, >>>>> If this is about unit testing on DAO, we are also experimenting with >>>>> simple JDBC approach[1]. No Dependency Injection. >>>>> We could test the DAO, the SQL correctness etc. because there is no >>>>> Mock objects. >>>>> >>>>> I am not in favor of DI on developing a platform as we have no control >>>>> over which get wired at the runtime. OSGI is already a kind of "dependency >>>>> injection" and we have more than enough issues with that. >>>>> >>>>> [1] https://github.com/wso2/carbon-identity-providers/blob/m >>>>> aster/components/identity-provider/org.wso2.carbon.identity. >>>>> provider/src/test/java/org/wso2/carbon/identity/provider/dao >>>>> /IdentityProviderDAOTest.java >>>>> >>>>> Cheers, >>>>> Ruwan >>>>> >>>>> >>>>> On Tue, Nov 1, 2016 at 4:10 PM, Manuranga Perera <[email protected]> >>>>> wrote: >>>>> >>>>>> I like Guice as well, but since we already have OSGi, (if we do have >>>>>> OSGi) shouldn't we leverage that ? >>>>>> >>>>>> On Tue, Nov 1, 2016 at 5:37 AM, Uvindra Dias Jayasinha < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>>> Spring too supports dependency injection (since its first release >>>>>>>> in early 2000s), anyone knows the differences between Spring and Guice? >>>>>>>> >>>>>>>> >>>>>>>> I checked up on this, mainly Spring was the alternative to the >>>>>>> bloated JavaEE. So its a fully featured framework with lots of stuff >>>>>>> including the ability to do dependency injection. >>>>>>> >>>>>>> Guice is a light weight library that only focuses on DI. So if you >>>>>>> want just DI, Guice is nice and simple as opposed to a heavier framework >>>>>>> like Spring that has a lot more in it. >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Uvindra >>>>>>> >>>>>>> Mobile: 777733962 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> With regards, >>>>>> *Manu*ranga Perera. >>>>>> >>>>>> phone : 071 7 70 20 50 >>>>>> mail : [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Uvindra >>>> >>>> Mobile: 777733962 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Ruwan Abeykoon* > *Associate Director/Architect**,* > *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * > *lean.enterprise.middleware.* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
