What Is Inversion of Control?

Inversion of Control ( IoC for short) is a design principle in object-oriented programming that can be used to reduce the coupling between computer codes. The most common method is called Dependency Injection ( DI ), and there is another method called Dependency Lookup. Through the inversion of control, when an object is created, the external entities of all objects in a regulatory system pass references to the objects it depends on. It can also be said that dependencies are injected into objects.

Back in 2004,

An object b of Class B is used in Class A. Generally, an object of B needs to be explicitly created in the code of A.

After using dependency injection technology, the code of A only needs to define a private B object, and does not need to directly new to get this object. Instead, the B object is externally new and injected into the A class through the relevant container control program. Citing. The specific acquisition method and the state when the object is acquired are specified by a configuration file (such as XML). ^[1]

IoC can be considered as a brand-new design pattern , but the theory and time mature relatively late and are not included in

Existing frameworks actually use the following three basic technology frameworks to perform binding between services and components:

1. Type 1 (interface-based): Serviceable objects need to implement a special interface, which provides an object that can be reused to find dependencies (other services). Earlier containers Excalibur used this model.

2. Type 2 (setter-based): Specify services for serviceable objects through JavaBean properties (setter methods). HiveMind and Spring use this approach.

3. Type 3 (based on

   IoC is a big concept and can be implemented in different ways. There are two main forms:

   • Dependency lookup: The container provides callback interfaces and contextual conditions to components. Both EJB and Apache Avalon use this approach. In this way, the component must use the API provided by the container to find resources and collaboration objects. The only inversion of control is only reflected in those callback methods (that is, type 1 mentioned above): the container will call these callback methods, So that the application code can get relevant resources.

   • Dependency injection: The component does not perform positioning queries, but only provides ordinary Java methods for the container to determine dependencies. The container is solely responsible for the assembly of the component. It will pass the objects that conform to the dependencies through JavaBean properties or

     Implementing the data access layer

     The data access layer has two goals. The first is to abstract the database engine from the application so that the database can be changed at any timefor example, from Microsoft SQL to Oracle. However, this is rarely done in practice, and there is not enough reason and ability to refactor existing applications by using the implementation data access layer.

     The second goal is to abstract the data model from the database implementation. This makes the database or code open source change as needed, while only affecting a small part of the main application-the data access layer. This goal is worthwhile, and refactoring is necessary to achieve it in existing systems.

     Module and interface refactoring

     A core idea behind dependency injection is the single responsibility principle. The principle states that each object should have a specific purpose, and that different parts of the application that need to take advantage of this purpose should use the appropriate object. This means that these objects can be reused anywhere in the system. But this is not always the case in existing systems.

     Add unit tests at any time

     Encapsulating functionality into the entire object can make automatic testing difficult or impossible. Isolate modules and interfaces from specific objects, and refactor in this way to perform more advanced unit tests. It's tempting to continue refactoring modules as you add more tests later, but this is wrong.

     Use service locator instead of construction injection

     There is more than one way to achieve control inversion. The most common approach is to use construction injection, which requires providing all software dependencies when the object is first created. However, construction injection assumes that the entire system uses this pattern, which means that the entire system must be refactored at the same time. This is difficult, risky, and time-consuming. ^[3]