Fundamentals of dependency injection
Any module that relies on an underlying technology or platform is less reusable and makes changes to software complex and expensive. With proper decomposing of the complex problem, that is being addressed by a software module, into smaller components enables defining dependency components. Then when the time comes to replace a component, it is less disruptive to the larger component, therefore, more reusable.
The Dependency Injection pattern based on the "inversion of control" (IoC) principle. This relates to the way in which an object obtains references to its dependencies - the object is passed its dependencies through constructor arguments or after construction through setter methods or interface methods. It is called dependency injection since the dependencies of an object are 'injected' into it, the term dependency is a little misleading here, since it is not a new 'dependency' which is injected but rather a 'provider' of that particular capability. For example, passing a database connection as an argument to a constructor instead of creating one internal would be categorized as dependency injection. The pattern seeks to establish a level of abstraction via a public interface and to remove dependencies on components by supplying a 'plugin' architecture. This means that the individual components are tied together by the architecture rather than being linked together themselves. The responsibility for object creation and linking is removed from the objects themselves and moved to a factory.
There are 3 forms of dependency injection: setter-, constructor- and interface-based injection.
When developing - for example - a business service, that service is implemented to work with an interface of the Data Access Object. If you then want to use that module with a certain DAO - for example a DAO to access your mySQL database - you somehow have to tell the service to use exactly that object. This, however, would create a dependency between the service and the DAO. With the IoC pattern, as implemented in Spring, the developer defines which DAO (in this case the mySQL DAO) in an external configuration file (in our example: beans.xml). At runtime, the information from the configuration file are parsed and the dependency is injected into the service.
Use the dependency injection pattern when:
- the coupling between components needs to be reduced
- you are expecting to run controlled unit tests.
- With dependency injection, testing can begin very early in the development cycle
- you want to save time in that you don't have to write boilerplate factory creation code over and over again
What is dependency injection?
Classes often require references to other classes. For example, a Car class might need a reference to an Engine class. These required classes are called dependencies, and in this example the Car class is dependent on having an instance of the Engine class to run.
There are three ways for a class to get an object it needs:
The class constructs the dependency it needs. In the example above, Car would create and initialize its own instance of Engine. Grab it from somewhere else. Some Android APIs, such as Context getters and getSystemService(), work this way. Have it supplied as a parameter. The app can provide these dependencies when the class is constructed or pass them in to the functions that need each dependency. In the example above, the Car constructor would receive Engine as a parameter. The third option is dependency injection! With this approach you take the dependencies of a class and provide them rather than having the class instance obtain them itself.
References
No comments:
Post a Comment