官术网_书友最值得收藏!

How DI works and makes things easy for development and testing

Let's look at DI pattern implementation in your application. It makes things easy to understand, loosely coupled, and testable across the application. Suppose we have a simple application (something more complex than a Hello World example that you might make in your college classes). Every class is working together to perform some business task and help build business needs and expectations. That means that each class in the application has its measure of responsibility for a business task, together with other collaborating objects (its dependencies). Let's look at the following image. This dependency between the objects can create complexity and tight coupling between the dependent objects:

The TransferService component is traditionally dependent on two other components: TransferRepository and AccountRepository

A typical application system consists of several parts working together to carry out a use case. For example, consider the TransferService class, shown next.

TransferService using direct instantiation:

    package com.packt.chapter1.bankapp.transfer; 
    public class TransferService { 
      private AccountRepository accountRepository; 
      public TransferService () { 
        this.accountRepository = new AccountRepository(); 
      } 
      public void transferMoney(Account a, Account b) { 
        accountRepository.transfer(a, b); 
      } 
    } 

The TransferService object needs an AccountRepository object to make money transfer from account a to account b. Hence, it creates an instance of the AccountRepository object directly and uses it. But direct instantiation increases coupling and scatters the object creation code across the application, making it hard to maintain and difficult to write a unit test for TransferService, because, in this case, whenever you want to test the transferMoney() method of the TransferService class by using the assert to unit test, then the transfer() method of the AccountRepository class is also called unlikely by this test. But the developer is not aware about the dependency of AccountRepository on the TransferService class; at least, the developer is not able to test the transferMoney() method of the TransferService class using unit testing.

In enterprise applications, coupling is very dangerous, and it pushes you to a situation where you will not be able to do any enhancement in the application in the future, where any further changes in such an application can create a lot of bugs, and where fixing these bugs can create new bugs. Tightly coupled components are one of the reasons for major problems in these applications. Unnecessary tightly coupled code makes your application non-maintainable, and as time goes by, its code will not be reused, as it cannot be understood by other developers. But sometimes a certain amount of coupling is required for an enterprise application because completely uncoupled components are not possible in real-world cases. Each component in the application has some responsibility for a role and business requirement, to the extent that all components in the application have to be aware of the responsibility of the other components. That means coupling is necessary sometimes, but we have to manage the coupling between required components very carefully.

主站蜘蛛池模板: 建瓯市| 云林县| 新乡县| 西宁市| 静乐县| 罗田县| 广德县| 安福县| 明溪县| 武陟县| 视频| 沂南县| 新巴尔虎左旗| 吉安县| 教育| 长泰县| 长治市| 高陵县| 凤冈县| 涟水县| 蒲城县| 诏安县| 长宁县| 海安县| 大理市| 锡林郭勒盟| 新晃| 高安市| 会泽县| 梅河口市| 南川市| 平阴县| 南昌县| 长沙县| 澄江县| 息烽县| 子长县| 甘泉县| 湘潭市| 宿州市| 武安市|