The Dependency Inversion Principle states that:
- High level modules should not depend upon low level modules. Both should depend upon abstractions.
- Abstractions should not depend upon details. Details should depend upon abstractions.
The Dependency Inversion principle (DIP) helps us to develop loosely couple code by ensuring that high-level modules depend on abstractions rather than concrete implementations of lower-level modules. The Inversion of Control pattern is an implementation of this principle.
Inversion of Control
Inversion of control is used to increase modularity of the program and make it extensible.
Inversion of Control (IoC) means that objects do not construct other objects on which they rely on. Instead, the application will get these objects from an external framework (an IoC container).
One method which provides these objects to the application is called Dependency Injection (DI).
Inversion of control is the principle where the control flow of a program is inverted: instead of the programmer controlling the flow of a program, the external sources (framework, services, other components) take control of it.
IoC is a generic term meaning rather than having the application call the methods in a framework, the framework calls implementations provided by the application.
DI is a form of IoC, where implementations are passed into an object through constructors/setters/service look-ups, which the object will 'depend' on in order to behave correctly. IoC without using DI, for example would be the Template pattern because the implementation can only be changed through sub-classing.
DI Frameworks are designed to make use of DI and can define interfaces (or Annotations in Java) to make it easy to pass in implementations.
IoC Containers are DI frameworks that can work outside of the programming language. In some you can configure which implementations to use in metadata files (e.g. XML) which are less invasive.
IoC means that objects do not create other objects on which they rely to do their work. Instead, they get the objects that they need from an outside service (for example, xml file or single app service). 2 implementations of IoC are DI and ServiceLocator.
DI means the IoC principle of getting dependent object is done without using concrete objects but abstractions (interfaces). This makes all components chain testable, cause higher level component doesn't depend on lower level component, only from interface.
IoC is also known as dependency injection (DI). It is a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies by using direct construction of classes, or a mechanism such as the Service Locator pattern.
The main tasks performed by IoC container are:
- to instantiate the application class.
- to configure the object.
- to assemble the dependencies between the objects.
IOC can be achieved by either of the following (Implementation techniques):
1. Using a dependency injection
3 types of DI
- Constructor Injection
- Setter Injection
- Interface Injection
2. Using a service locator pattern
3. Using a factory pattern
Inversion of control :- It’s a generic term and implemented in several ways (events, delegates etc).
Dependency injection :- DI is a subtype of IOC and is implemented by constructor injection, setter injection or method injection.
DI is a software design pattern that allow us to develop loosely coupled code. DI is a great way to reduce tight coupling between software components. DI also enables us to better manage future changes and other complexity in our software. The purpose of DI is to make code maintainable.