mirror of
https://github.com/ets-labs/python-dependency-injector.git
synced 2024-11-25 19:14:00 +03:00
Updating README
This commit is contained in:
parent
f98b3aae01
commit
fae322fc7f
36
README.rst
36
README.rst
|
@ -29,34 +29,16 @@ Dependency injection framework for Python projects.
|
||||||
| | :alt: Coverage Status |
|
| | :alt: Coverage Status |
|
||||||
+---------------------------------------+-------------------------------------------------------------------+
|
+---------------------------------------+-------------------------------------------------------------------+
|
||||||
|
|
||||||
Introduction
|
*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.
|
||||||
|
|
||||||
Python ecosystem consists of a big amount of various libraries that contain
|
Below is a list of some key features and points of *Objects* framework:
|
||||||
different classes and functions that could be used for applications
|
|
||||||
development. Each of them has its own role.
|
|
||||||
|
|
||||||
Modern Python applications are mostly the composition of well-known open
|
- Easy, smart, pythonic style.
|
||||||
source systems / frameworks / libraries and some turnkey functionality.
|
- Obvious, clear structure.
|
||||||
|
- Memory efficiency.
|
||||||
When application goes bigger, its complexity and SLOC_ are also increased.
|
- Semantic versioning.
|
||||||
Being driven by SOLID_ (for example), developers often start to split
|
|
||||||
application's sources into not so big classes, functions and modules. It
|
|
||||||
always helps, but there is another problem on the horizon.
|
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
One of such IoC_ implementation patterns is called `dependency injection`_.
|
|
||||||
|
|
||||||
*Objects* is a dependency injection framework for Python projects.
|
|
||||||
|
|
||||||
It was designed to be developer's friendly tool for managing any kind of
|
|
||||||
Python objects and their dependencies in formal, pretty way.
|
|
||||||
|
|
||||||
Main idea of *Objects* is to keep dependencies under control.
|
Main idea of *Objects* is to keep dependencies under control.
|
||||||
|
|
||||||
|
@ -146,12 +128,12 @@ Examples
|
||||||
@inject(KwArg('b', Catalog.object_b_factory))
|
@inject(KwArg('b', Catalog.object_b_factory))
|
||||||
@inject(KwArg('database', Catalog.database))
|
@inject(KwArg('database', Catalog.database))
|
||||||
def example(a, b, database):
|
def example(a, b, database):
|
||||||
|
"""Example callback."""
|
||||||
assert a.db is b.db is database is Catalog.database()
|
assert a.db is b.db is database is Catalog.database()
|
||||||
|
|
||||||
|
|
||||||
example()
|
example()
|
||||||
|
|
||||||
|
|
||||||
You can get more *Objects* examples in ``/examples`` directory on
|
You can get more *Objects* examples in ``/examples`` directory on
|
||||||
GitHub:
|
GitHub:
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user