2015-04-02 16:17:00 +03:00
|
|
|
Introduction
|
|
|
|
============
|
|
|
|
|
2015-08-03 22:36:20 +03:00
|
|
|
Before you have started with *Objects* framework and dependecy injection, there
|
|
|
|
are a couple of introduction notes that might be useful.
|
|
|
|
|
|
|
|
What is DI and why is it needed?
|
|
|
|
--------------------------------
|
|
|
|
|
2015-05-12 16:18:37 +03:00
|
|
|
Python ecosystem consists of a big amount of various libraries that contain
|
|
|
|
different classes and functions that could be used for applications
|
|
|
|
development. Each of them has its own role.
|
2015-04-02 16:17:00 +03:00
|
|
|
|
|
|
|
Modern Python applications are mostly the composition of well-known open
|
2015-05-12 16:18:37 +03:00
|
|
|
source systems / frameworks / libraries and some turnkey functionality.
|
2015-04-02 16:17:00 +03:00
|
|
|
|
2015-05-12 16:18:37 +03:00
|
|
|
When application goes bigger, its complexity and SLOC_ are also increased.
|
|
|
|
Being driven by SOLID_ (for example), developers often start to split
|
2015-08-03 22:36:20 +03:00
|
|
|
application's sources into not so big classes, functions and modules, that are
|
|
|
|
less complex, could be reused several times and so on... It always helps, but
|
|
|
|
there is another problem on the horizon.
|
2015-04-02 16:17:00 +03:00
|
|
|
|
2015-08-03 22:36:20 +03:00
|
|
|
The name of this problem is - "Dependency hell!". It sounds like "I have so
|
|
|
|
many classes and functions! They are great, now I can understand each of them,
|
|
|
|
but it is so hard to see the whole picture! How are they linked with each
|
|
|
|
other? What dependencies does this class have?". And this is a key question:
|
|
|
|
"What dependencies do certain class / function have?". To resolve this issues
|
|
|
|
developers have to go inside with IoC_ principles and implementation patterns.
|
2015-05-12 16:18:37 +03:00
|
|
|
|
|
|
|
One of such IoC_ implementation patterns is called `dependency injection`_.
|
|
|
|
|
2015-08-03 22:36:20 +03:00
|
|
|
Dependency injection in Python
|
|
|
|
------------------------------
|
2015-05-12 16:18:37 +03:00
|
|
|
|
2015-08-03 22:36:20 +03:00
|
|
|
Interesting but, dependency injection is not very popular topic in Python.
|
|
|
|
The things are so because Python is an awesome language. Your eyes are opened
|
|
|
|
and your hands are free while you are using Python. In practice this means that
|
|
|
|
you can do dependency injection in Python in quite an easy way because language
|
|
|
|
itself helps you to do this. At the same time, even the thins are so, you still
|
|
|
|
have to do some work. Another one 'minor' problem is that there are several
|
|
|
|
ways to do dependency injection container.
|
2015-05-12 16:18:37 +03:00
|
|
|
|
2015-08-03 22:36:20 +03:00
|
|
|
Key features
|
|
|
|
------------
|
|
|
|
|
|
|
|
*Objects* is a dependency injection framework for Python projects.
|
|
|
|
It was designed to be unified, developer's friendly tool for managing any kind
|
|
|
|
of Python objects and their dependencies in formal, pretty way.
|
2015-05-12 16:18:37 +03:00
|
|
|
|
2015-08-03 22:36:20 +03:00
|
|
|
Below is a list of some key features and points of *Objects* framework:
|
|
|
|
|
|
|
|
- Easy, smart, pythonic style.
|
|
|
|
- Obvious, clear structure.
|
|
|
|
- Memory efficiency.
|
|
|
|
- Semantic versioning.
|
|
|
|
|
|
|
|
Main idea of *Objects* is to keep dependencies under control.
|
2015-05-12 16:18:37 +03:00
|
|
|
|
2015-08-04 16:13:33 +03:00
|
|
|
Main entities
|
|
|
|
-------------
|
|
|
|
|
|
|
|
Current section describes *Objects* main entities and their interaction with
|
|
|
|
each other.
|
|
|
|
|
|
|
|
.. image:: /images/internals.png
|
|
|
|
:width: 100%
|
|
|
|
:align: center
|
|
|
|
|
|
|
|
There are 3 main entities:
|
|
|
|
|
|
|
|
- Providers. Providers are strategies of accesing objects. For example,
|
|
|
|
``objects.providers.Factory`` creates new instance of provided class every
|
|
|
|
time it is called. ``objects.providers.Singleton`` creates provided instance
|
|
|
|
once and returns it on every next call. Providers could be overridden by
|
|
|
|
another providers. Base class is - ``objects.providers.Provider``.
|
|
|
|
- Injections. Injections are instructions for making dependency injections
|
|
|
|
(there are several ways how they could be done). Injections are used mostly
|
|
|
|
by ``objects.providers.Factory`` and ``objects.providers.Singleton``
|
|
|
|
providers, but these are not only cases. Base class is -
|
|
|
|
``objects.injections.Injection``.
|
|
|
|
- Catalogs. Catalogs are collections of providers. They are used for grouping
|
|
|
|
of providers by some principles. Base class is -
|
|
|
|
``objects.catalog.AbstractCatalog``.
|
|
|
|
|
|
|
|
|
2015-05-12 16:18:37 +03:00
|
|
|
.. _SLOC: http://en.wikipedia.org/wiki/Source_lines_of_code
|
|
|
|
.. _SOLID: http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29
|
|
|
|
.. _IoC: http://en.wikipedia.org/wiki/Inversion_of_control
|
|
|
|
.. _dependency injection: http://en.wikipedia.org/wiki/Dependency_injection
|