Hi Uvindra, I am totally for the last explanation. We need not call it "Dependency Injection".
Supplying the other classes via constructors or setters is what we all need to follow. There are many other "Structural and Creational Patterns" we can use for the purpose to "Wire" the objects the way we want. in short yes we need to avoid this "create an instance of *DAO* inside the* Foo *class, to be used within *Foo* class" Cheers, Ruwan On Thu, Nov 3, 2016 at 6:27 PM, Uvindra Dias Jayasinha <[email protected]> wrote: > 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 > > -- *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
