Update description of DI pattern in readme
This commit is contained in:
parent
9a14e8b659
commit
dde52a5d0f
42
README.rst
42
README.rst
|
@ -47,22 +47,36 @@ Dependency injection
|
||||||
|
|
||||||
`Dependency injection`_ is a software design pattern that implements
|
`Dependency injection`_ is a software design pattern that implements
|
||||||
`Inversion of control`_ for resolving dependencies. Formally, if object **A**
|
`Inversion of control`_ for resolving dependencies. Formally, if object **A**
|
||||||
depends on object **B**, object **A** must not create or import object **B**,
|
depends on object **B**, object **A** must not create or import object **B**
|
||||||
but provide a way for injecting object **B** (object **B** could be injected
|
directly. Instead of this object **A** must provide a way for *injecting*
|
||||||
into object **A** in several ways: by passing it as ``__init__`` argument, by
|
object **B**. The responsibilities of objects creation and dependencies
|
||||||
setting it as attribute's value or by passing it as method's argument).
|
injection are delegated to external code - the *dependency injector*.
|
||||||
|
|
||||||
|
Popular terminology of dependency injection pattern:
|
||||||
|
|
||||||
|
+ Object **A**, that is dependant on object **B**, is often called -
|
||||||
|
the *client*.
|
||||||
|
+ Object **B**, that is a dependency, is often called - the *service*.
|
||||||
|
+ External code that is responsible for creation of objects and injection
|
||||||
|
of dependencies is often called - the *dependency injector*.
|
||||||
|
|
||||||
|
There are several ways of how *service* can be injected into the *client*:
|
||||||
|
|
||||||
|
+ by passing it as ``__init__`` argument (constructor / initializer injection)
|
||||||
|
+ by setting it as attribute's value (attribute injection)
|
||||||
|
+ by passing it as method's argument (method injection)
|
||||||
|
|
||||||
Dependency injection pattern has few strict rules that should be followed:
|
Dependency injection pattern has few strict rules that should be followed:
|
||||||
|
|
||||||
+ Object **A** (the client) delegates to external code (the dependency
|
+ The *client* delegates to the *dependency injector* the responsibility
|
||||||
injector) the responsibility of providing its dependencies - object **B**
|
of injecting its dependencies - the *service(s)*.
|
||||||
(the service).
|
+ The *client* doesn't know how to create the *service*, it knows only
|
||||||
+ The client doesn't know how to create the service, it knows only interface
|
interface of the *service*. The *service* doesn't know that it is used by
|
||||||
of service. The service doesn't know that it is used by the client.
|
The *client*.
|
||||||
+ The dependency injector knows how to create the client and the service, it
|
+ The *dependency injector* knows how to create the *client* and
|
||||||
also knows that the client depends on the service, and knows how to inject
|
the *service*, it also knows that the *client* depends on the *service*,
|
||||||
the service into the client.
|
and knows how to inject the *service* into the *client*.
|
||||||
+ The client and the service know nothing about the dependency injector.
|
+ The *client* and the *service* know nothing about the *dependency injector*.
|
||||||
|
|
||||||
Dependency injection pattern provides next advantages:
|
Dependency injection pattern provides next advantages:
|
||||||
|
|
||||||
|
@ -77,7 +91,7 @@ Example of dependency injection
|
||||||
-------------------------------
|
-------------------------------
|
||||||
|
|
||||||
Brief example below demonstrates usage of *Dependency Injector* for creating
|
Brief example below demonstrates usage of *Dependency Injector* for creating
|
||||||
several IoC containers for some microservice system:
|
several IoC containers for some example application:
|
||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue