stubbles / ioc
Dependency injection.
Installs: 1 976
Dependents: 3
Suggesters: 0
Security: 0
Stars: 2
Watchers: 3
Forks: 0
Open Issues: 1
Requires
- php: ^8.2
- stubbles/reflect: ^10.0
- stubbles/sequence: ^10.1
- stubbles/values: ^11.0
Requires (Dev)
- bovigo/assert: ^8.0
- bovigo/callmap: ^8.0
- mikey179/vfsstream: ^1.6.11
- phpunit/phpunit: ^10.5
- stubbles/streams: ^10.0
- dev-main / 11.0.x-dev
- v11.0.0
- v10.2.0
- v10.1.0
- v10.0.0
- v9.0.0
- v8.0.1
- v8.0.0
- v7.1.1
- v7.1.0
- v7.0.0
- v6.3.0
- v6.2.0
- v6.1.0
- v6.0.0
- v5.5.1
- v5.5.0
- v5.4.1
- v5.4.0
- v5.3.2
- v5.3.1
- v5.3.0
- v5.2.0
- v5.1.2
- v5.1.1
- v5.1.0
- v5.0.1
- v5.0.0
- v4.1.4
- v4.1.3
- v4.1.2
- v4.1.1
- v4.1.0
- v4.0.2
- v4.0.1
- v4.0.0
- v3.5.3
- v3.5.2
- v3.5.1
- v3.5.0
- v3.4.4
- v3.4.3
- v3.4.2
- v3.4.1
- v3.4.0
- v3.3.1
- v3.3.0
- v3.2.0
- v3.1.2
- v3.1.1
- v3.1.0
- v3.0.0
- v2.1.3
- v2.1.2
- v2.1.1
- v2.1.0
- v2.0.0
- v2.0.0-beta8
- 2.0.0-beta7
- 2.0.0-beta6
- 2.0.0-beta5
- 2.0.0-beta4
- 2.0.0-beta2
- 2.0.0-beta1
- dev-dependabot/composer/phpunit/phpunit-10.5.24
This package is auto-updated.
Last update: 2024-10-31 00:20:16 UTC
README
Dependency injection.
Build status
Installation
stubbles/ioc is distributed as Composer package. To install it as a dependency of your package use the following command:
composer require "stubbles/ioc": "^11.0"
Requirements
stubbles/ioc requires at least PHP 8.2.
Inversion of Control
stubbles/ioc provides a very simple-to-use but still powerful inversion of control container, which supports constructor and setter based dependency injection. The IoC container of stubbles/ioc is modeled after Google Guice and makes use of type hinting annotations. If you've never heard of type hinting or annotations, you should at first read the sections on these two topics:
- Section on 'type hinting' in the PHP manual
- Annotations Section on annotations in the stubbles/reflect.
The example code
Imagine, you are building a car configurator. To follow the rules of good design, you define interfaces for all components of a car and provide several classes that implement these components.
The interfaces in you application include:
interface Car { public function moveForward($miles); } interface Person { public function sayHello(); } interface Tire { public function rotate(); } interface Engine { public function start(); }
The implementations are:
class BMW implements Car { private $driver; private $engine; private $tire; public function __construct(Engine $engine, Tire $tire, Person $driver) { $this->engine = $engine; $this->tire = $tire; $this->driver = $driver; } public function moveForward($miles) { $this->driver->sayHello(); $this->engine->start(); $this->tire->rotate(); } } class Schst implements Person { public function sayHello() { echo "My name is Stephan\n"; } } class Goodyear implements Tire { public function rotate() { echo "Rotating Goodyear tire\n"; } } class TwoLitresEngine implements Engine { public function start() { echo "Starting 2l engine\n"; } }
Without the dependency injection framework
To create a new instance of an implementation of Car
the following code is
required:
$tire = new Goodyear(); $engine = new TwoLitresEngine(); $schst = new Schst(); $bmw = new BMW($engine, $tire, $schst); $bmw->moveForward(50);
Creating objects manually like this has several drawbacks:
- Your application is bound to the concrete implementations instead of the interfaces
- Changing the implementation means changing existing code, which might break it
- The creation of objects is scattered throughout your application
Of course, real applications have a lot more classes, so things only get worse then.
Enter 'Inversion of Control'
stubbles/ioc tries to solve these problems by providing functionality to handle all dependency injections for you. This keeps your application clean of boilerplate code.
Furthermore, it allows you to centralize and/or modularize the definition of the concrete implementations for your interfaces or abstract types.
A simple example
To define the concrete implementations is done using an instance of stubbles\ioc\Binder
:
$binder = new \stubbles\ioc\Binder(); $binder->bind('Car')->to('BMW'); $binder->bind('Tire')->to('Goodyear'); $binder->bind('Person')->to('Schst'); $binder->bind('Engine')->to('TwoLitresEngine');
In this short code snippet, you bound the interfaces from the example above to their concrete implementations.
If you now need an instance of the engine, you use the binder to create a
stubbles\ioc\Injector
, which can be used to create the desired Engine
:
$injector = $binder->getInjector(); $engine = $injector->getInstance('Engine'); var_dump($engine);
This code snippet will now display:
object(TwoLitresEngine)#48 (0) {
}
As desired, it created an instance of the concrete implementation, that you bound to the interface.
Next, you probably want to get an instance of Car
using the same approach:
$injector = $binder->getInjector(); $car = $injector->getInstance('Car'); var_dump($car);
object(BMW)#33 (3) {
["driver:private"]=>
NULL
["engine:private"]=>
object(TwoLitresEngine)#37 (0) {
}
["tire:private"]=>
object(Goodyear)#40 (0) {
}
}
stubbles/ioc created a new instance of BMW
, as you bound it to Car
, and as
the constructor of BMW
requires a Tire
and an Engine
instance, it created
these instances as well. To determine the concrete classes to use, stubbles/ioc
used the bindings you defined in the stubbles\ioc\Binder
instance.
What you also can see is, that Stubbles did not inject an object into the
$driver
property, although you specified a binding for Person
. stubbles/ioc
will never inject any dependencies via setter methods.