Tag Archives: simple

The quest for a c++ Dependency Injection Container library. Part 2, some Sauce

Introduction

In Part 1 I have started with a list of C++ dependency injection libraries, and sketched an example problem, solved and tested with the help of Wallaroo. For the second part, Hypodermic should have been in focus, but unfortunately, no version compiled out of the box on MacOS with Clang [1. To do in 2014]. Hence, the article is about sauce, an inspiration from google-guice.

Dependency Injection using sauce

A little repetition, the example problem contains of 3 interfaces with a linear dependency graph of the implementations. Not to repeat the implementations, and not change the structure of the existing code, simple factories for the default implementations have been exposed, but not the concrete types in the headers, i.e. for the default renderer implementation:

std::shared_ptr< IRender > NewKeyRenderer(std::shared_ptr< IGetKeyValue > model) {
	return std::make_shared<KeyRenderer>(model);
};

Implementations

Simplified, the sauce solution looks as follows. Unlike in Wallaroo, in sauce, the implementations do not need to derive from a common “dependency” class. Any type can be bound to any derived class. The implementation of a renderer for the sauce example just adds a delegation to the original implementation [2. Efficiency and overhead are not considered in the first place.]:

class SauceKeyRenderer : public IRender {
public:
	SauceKeyRenderer(std::shared_ptr< IGetKeyValue > m) :
	pimpl ( NewKeyRenderer(m) )
	{ }

public:
	virtual std::string Render() {
		//...
		return pimpl->Render();
	}

private:
 	std::shared_ptr< IRender > pimpl;
};

Modules

Modules are containers of bindings of interfaces to their implementations. The easiest way to define a module is to provide a function with the signature void (* module)(sauce::Binder &).

Here’s the self-explaining module:

void render_module(sauce::Binder& b) {
	b.bind<IRender>().to<SauceKeyRenderer(IGetKeyValue&)>();
}

Once again, obviously, the type doesn’t have to leak outside the module due to inversion of control.

Note that the IGetKeyValue dependency of SauceKeyRenderer is injected via the constructor parameter, enabling automatic dependency resolution at later time.

Injectors

Instances of the bound interfaces are obtainable from injectors, which can be constructed from a collection of modules:

sauce::shared_ptr<Injector> injector = Modules()
	.add(render_module)
	.add(decoder_module)
	.add(model_module)
	.createInjector()
;

Resolving the dependencies

The hello-world example of resolving the dependencies is one simple line:

sauce::shared_ptr<IRender> renderer = injector->get<IRender>();

In this case, SauceKeyRenderer will get resolved and two other dependencies will be automatically instantiated and injected (see test_sauce.cpp).

Mocking and singletons

Sauce allows for different lifetime models of the interface instances. Singletons are possible with the concept of scoped injectors, in which, the instances are shared.

For googlemock getting the resolved instance is crucial, since the expectations are bound to an instance of the mocked class. With automatic dependency resolution and no hacks, the interface IModel would resolve to a new instance in the test. Hence, unless a way to use the shared instance lifetime inside the test is found, the mock is implemented trivially without googlemock.

Summary

This article is once again a short intro into the paradigm of another Dependency Injection library sauce. A more elaborate intro can be read in sauce’s tutorial test suite.

Source: https://github.com/d-led/test-ioc-cpp

More to come…

The quest for a c++ Dependency Injection Container library. Part 1, Wallaroo Introduction

Introduction

Given the static nature of the C++ type system, the lack of reflection and a platform-independent ABI in native C++, dependency injection doesn’t seem to have fallen into fashion in C++ projects [1. Alternative areas: COM & .NET ]. It might be that using the right tool for the right job diminishes the need for dependency injection containers for C++. Nonetheless, I find it worth digging into today’s offer of different libraries. Along the way, several other technologies will shine.

Structure

The resulting code will be constantly updated at https://github.com/d-led/test-ioc-cpp.

The project is expected to compile and run on many desktop platforms with a c++11 compiler. Hence, the makefiles are made with premake and a small helper library.

Mocks are useful when you use dependency inversion, hence the googlemock library will be used for demonstration purposes. Currently, the whole project is a single googletest executable, which is run after each compile.

Some makefiles and a Visual Studio solution are checked in, but can be generated from the premake script anytime.

The plan

The plan is to introduce each DI library superficially at first, and then to dig for feature differences, common patterns and perhaps applicability suggestions. The quest over the available libraries might take some time. The first intent is to give hello world examples of C++ DI libraries in action.

Linux builds and test runs will be performed automatically at https://travis-ci.org/d-led/test-ioc-cpp.

The libraries

A note on memory management

The Single Responsibility Principle is ingrained in all of the Dependency Injection libraries, as the instances are managed via smart pointers, which take up the responsibility of memory management.

Example architecture

An artificial, simple, decoupled architecture is used in the example. The interfaces are as follows:

struct IRender {
	virtual std::string Render() = 0;
	virtual ~IRender() {}
};

struct IGetKeyValue {
	virtual size_t Count() = 0;
	virtual std::string GetKey(size_t pos) = 0;
	virtual std::string GetValue(std::string const& key) = 0;
	virtual ~IGetKeyValue() {}
};

struct IModel {
	virtual std::string Get() = 0;
	virtual ~IModel() {}
};

The names might change during the quest. The expected dependencies are as follows: the renderer needs a model, which is a key-value pair collection, which might be decoded from some kind of data_source, which is here simply a string.

Wallaroo

To start with the quest, let’s look at Wallaroo. This has been the first library that I’ve considered using, and have already written a little walkthrough: lul.

The library has a rather exotic DSL for a DI library, however, it seems to be very well suited for communicating the concepts.

The objects (components) are created within a so-called catalog and have string IDs. When all the necessary objects have been created, they can be wired together with a DSL in the form:

within the catalog, use component_1 as dependency_1 of component_2.

Components == Parts

Let’s see how the components that are usable within Wallaroo are defined. A drawback of Wallaroo can be seen from the start, namely that the components have to be defined intrusively – they have to derive from wallaroo::Part:

class WallarooKeyRenderer :  public wallaroo::Part , public IRender { ... };

The drawback can be somewhat overcome by using the Bridge pattern with composition when refactored. The first implementation here is fully dependent on wallaroo::Part.

The library allows static registration, hence there is no need to expose the type or even a manually written factory of WallarooKeyRenderer:

WALLAROO_REGISTER( WallarooKeyRenderer );

is the registration macro.

Dependencies

Dependencies are called wallaroo::Collaborators. These can be private members:

wallaroo::Collaborator< IGetKeyValue > model;

and must be initialised in the constructor:

WallarooKeyRenderer():
		model( "model", RegistrationToken() )  { }

Then, if wiring the objects succeeds, the collaborators are usable as smart-pointers:

... model->GetKey(pos);

A nice feature in Wallaroo is that it supports constructor parameters. Another one – an initial support for loading plugins from DLLs exists. The configuration of catalogs: instances of objects and their wirings can be loaded from XML or JSON.

Full source: wallaroo_render.cpp

Instantiating objects

There are two implementations of the interfaces: a JSON decoder (using the lightweight single-header picojson library) and a renderer described above. The model can be simply mocked using GMock.

Inside the test (test_wallaroo.cpp) the model can be instantiated as follows.

Given the mock implementation:

class MockModel : public IModel, public wallaroo::Part {
public:
	MOCK_CONST_METHOD0(Get, std::string());
};
WALLAROO_REGISTER( MockModel );

one can now instantiate the mock inside the test and set expectations using the GMock DSL:

catalog.Create("mock model","MockModel");
std::shared_ptr<MockModel> mock_model = catalog["mock model"];
ASSERT_TRUE( mock_model.get() );
EXPECT_CALL(*mock_model, Get())
	.Times(AtLeast(1))
	.WillRepeatedly(Return("{ \"a\" : 1 , \"b\" : 2 }"));

The other objects are instantiated in the fixture:

catalog.Create("renderer", "WallarooKeyRenderer");

and

CreateDecoder("decoder",catalog);

using an example of a factory with inverted control, in case one doesn’t want to let out strings that represent types, but cannot be checked at runtime:

void CreateDecoder(std::string const& name,wallaroo::Catalog& catalog)
{
	catalog.Create(name, WallarooJsonDecoder);
}

That way you neither leak the implementation type, neither its typename string.

Wiring dependencies

Now that the objects are instantiated, they can be wired in code:

wallaroo_within(catalog)
{
	use("decoder").as("model").of("renderer");
	use("mock model").as("data_source").of("decoder");
}

A feature I enjoy in Wallaroo is that you can rewire the dependencies at runtime without creating new objects. That might get you some weird runtime dependencies if your code becomes messy, but if you take care of the quality, that feature might get handy.

When everything is wired up, the test is concluded with

ASSERT_EQ( "a,b", renderer->Render() );

Summary

Wallaroo is an easy to use header-only library, resembling in its use the Multiton Pattern. If instances of the dependencies can be given unique ids, there may be multiple implementations of the same interface, and if the dependencies should be rewired at runtime, wallaroo is a perfect choice.

Updates

05.11.2014: new wallaroo metaphors, +di, +infectorpp

More to come…

yet quicker start for a c++ project

The simplest way to try out some c++ concepts on your machine is the built-in build support of some ‘smart’ text editors, such as Sublime Text or SciTE. However, if you want to start quickly, but be able to grow the project from that one small seed, you’d probably want to have SCM set up.

To start cross-platform c++ projects I usually use git and premake. For premake I’ve set up a couple of quickstart scripts that implement some code organization conventions I usually follow. That project still requires one to set up a git directory, add a submodule, edit a premake4.lua file, write the first code file. How about automating these tasks as well. Every developer writes own support shell scripts, here’s one: new_cpp.sh that doesn’t do much – just what is described above. Considering, you have copied it somewhere where it’s executable globally, here are the steps:

  1. new_cpp.sh project_name → make the directory, init a git repo, add the premake submodule, the first source file and the premake4 build meta-configuration.
  2. cd project_name
  3. premake4 gmake → generate, makefiles, could be vs*, xcode*, too.
  4. make -C Build → build to see if everything is set up.

You can now start growing your code from project_name.cpp.