diapyr 30

Constructor injection for Python

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.