Constructor injection for Python
Project description
diapyr
Constructor injection for Python
Overview
- Automatic wiring between application objects
- Declare what collaborator types you want in your constructor using an @types decorator, they correspond with params
- You can decorate a (factory) function in the same way, in which case the return type must also be declared using 'this' kwarg
- Surround a type in square brackets if you want a list of all matching objects, normally diapyr provides a unique match
- Add such classes/factories to a DI instance
- You can also add objects, for example an application config object
- Request a type from the DI instance and diapyr will attempt to make it for you, along with the rest of the object graph
- Instances are cached in the DI object
- On exit from 'with' clause, dispose is called on any created instances that have it
Motivation
- Manual wiring is messy and tedious especially when an app gets big
- Constructor injection avoids spaghetti code
- It's trivial to depend on an object anywhere in the graph as long as you don't create a reference cycle e.g. most objects will depend on the same config instance
- No need to resort to globals, which come with a big risk of leaking state between unit tests
- Unit testing is easy when an object only interacts with what was passed into its constructor
Convention
- When depending on a config object the constructor should first extract what it needs and assign those values to fields
- Collaborators should also be assigned to fields, and ideally the constructor won't do anything else
Advanced
- Parameter defaults are honoured, this can be used to depend on module log object in real life and pass in a mock in unit tests
- Decorating an instance method (without 'this' kwarg) will make it behave as an additional constructor
- Take advantage of name mangling (start with double underscore e.g. __init) to avoid having to call super
- Decorating an instance method with 'this' kwarg will make it behave as a factory function
- Adding a class to DI will implicity add all such methods it has as factories
- You can play fast and loose with types, diapyr doesn't care whether a factoried object satisfies the declared type
API
diapyr
DI
Convenience import.
types
Convenience import.
diapyr.diapyr
types
def types(*deptypes, **kwargs)
Declare that the decorated function or method expects args of the given types. Use square brackets to request all instances of a type as a list. Use this
kwarg to declare the type of result returned by a factory.
DI Objects
class DI()
add
def add(obj)
Register the given class, factory or instance.
all
def all(type)
Return all objects of the given type, instantiating them and collaborators if necessary.
__call__
def __call__(clazz)
Return unique object of the given type, instantiating it and its collaborators if necessary.
__exit__
def __exit__(*exc_info)
Discard all instances created by this container, calling dispose
if they have it.
diapyr.start
diapyr.util
innerclass
def innerclass(cls)
An instance of the decorated class may access its enclosing instance via self
.
singleton
def singleton(t)
The decorated class is replaced with a no-arg instance.
invokeall
def invokeall(callables)
Invoke every callable, even if one or more of them fail. This is mostly useful for synchronising with futures. If all succeeded return their return values as a list, otherwise raise all exceptions thrown as a chain.
setuphacks
getsetupkwargs
def getsetupkwargs(setuppath, fields)
Extract the kwargs passed to setup
at the given path (typically some setup.py) that have names in the given fields
.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.