AnonymousFox

//usr/share/doc/cpanel-php74-horde-injector-2.0.5/Readme.html

<div id="toc"><h2>Table of Contents</h2><ol><li><a href="#toc0"> Introduction</a></li><li><a href="#toc1"> Horde_Injector</a><ol><li><a href="#toc2"> Making classes amenable to dependency injection</a></li><li><a href="#toc3"> Using Horde_Injector</a><ol><li><a href="#toc4"> Default Binders</a></ol></li><li><a href="#toc5"> Preparing a class for Horde_Injector</a><ol><li><a href="#toc6"> Getting rid of singletons?</a></ol></li><li><a href="#toc7"> Dependency Injection Container FAQ</a><ol><li><a href="#toc8"> Where can <tt>Horde_Injector</tt> be used?</a></li><li><a href="#toc9"> How do I provide <tt>Horde_Config</tt> values to my business models?</a></li><li><a href="#toc10"> I have an <tt>array</tt>-typed parameter in my constructor, do I have to use a factory to provide the array of values?</a></ol></li><li><a href="#toc11"> Dependency Injection Container Spec</a><ol><li><a href="#toc12"> Terms</a></li><li><a href="#toc13"> Requirements</a></li><li><a href="#toc14"> Functional Spec</a><ol><li><a href="#toc15"> Goals</a></li><li><a href="#toc16"> Features</a></ol></li><li><a href="#toc17"> Technical Spec</a></li><li><a href="#toc18"> Binders</a><ol><ol><li><a href="#toc19"> Factory binders</a></li><li><a href="#toc20"> Implementation binders</a></li><li><a href="#toc21"> Choosing a binder</a></ol></li><li><a href="#toc22"> Instances</a></li><li><a href="#toc23"> Getting objects</a><ol><li><a href="#toc24"> Creating a new instance</a></li><li><a href="#toc25"> Getting an instance</a></ol></li><li><a href="#toc26"> Scoping with child injectors</a></ol></ol></ol>
</li></ol></div>

<h1 id="toc0"> Introduction</h1>
The dependency injection pattern (<a href="http://en.wikipedia.org/wiki/Dependency_injection" class="external" target="_blank" title="http://en.wikipedia.org/wiki/Dependency_injection">http://en.wikipedia.org/wiki/Dependency_injection</a>) is a useful approach that can help to avoid using global variables or state. If a class depends on a connection to a database then this connection is often pulled into the class using a singleton pattern or by using a global variable.

Instead of providing the class with knowledge about the global state it is often preferable to &quot;inject&quot; the dependency into the class from the outside. This usually happens within the class constructor. To get hold of a database connection a class constructor could for example require an object that implements a database interface instead of using a singleton pattern.

This way the dependencies of a class are immediately visible in the constructor. It is not necessary to search the code of the class for references to the global scope. This usually also helps to decouple 
dependencies between different code modules. Another major benefit of dependency injection is the fact that it facilitates unit testing of complex systems.

<h1 id="toc1"> Horde_Injector</h1>
Horde_Injector provides a &quot;Dependency Injection&quot; framework. For PHP there exist several dependency injection frameworks (e.g. <a href="http://stubbles.net" class="external" target="_blank" title="http://stubbles.net">http://stubbles.net</a>, <a href="http://components.symfony-project.org/dependency-injection" class="external" target="_blank" title="http://components.symfony-project.org/dependency-injection">http://components.symfony-project.org/dependency-injection</a>) with extensive feature lists. So there is hardly any need for another framework with similar capabilities.

The essential part of dependency injection is the structure of classes with dependencies. They need to be amenable for an external management of their dependencies. If that is the case for a given class then most dependency injection frameworks should have no problem handling this class within the framework. The choice of the actual framework should not matter anymore.

Horde_Injector provides only a minimal version of dependency injection. It is somewhere in between the frameworks mentioned above and Twittee (<a href="http://twittee.org/" class="external" target="_blank" title="http://twittee.org/">http://twittee.org/</a>). The primary goal is to drive refactoring of classes with complex dependencies so that their dependencies can be uncoupled and they can be used with a dependency injection framework.

<h2 id="toc2"> Making classes amenable to dependency injection</h2>
As trivial as it may sound: a class can be managed by a dependency injection framework if the class allows the framework to inject its dependencies from the outside. That means that the class may not

<ul>
 <li>pull in a dependency using global state via the singleton pattern:</li>
</ul>

<pre><code>External_Class::singleton();
</code></pre>

<ul>
 <li>create new objects with dependencies:</li>
</ul>

<ul>
 <li>use global variables:</li>
</ul>

<pre><code>global $conf;
$db = new DB($conf['sql');
</code></pre>

In most cases the class should receive dependencies and required parameters within the constructor.

<h2 id="toc3"> Using Horde_Injector</h2>
The Horde_Injector class is a simple container that allows you to fill it with a number of elements that can be retrieved later:

<pre><code>$a = new Horde_Injector(new Horde_Injector_TopLevel());
$a-&gt;setInstance('a', 'a');
echo $a-&gt;getInstance('a');
</code></pre>

<pre><code>string(1) &quot;a&quot;</code></pre>

Here we assigned a concrete instance to the injector. In fact not even an instance but a simple type: a string. Usually you would register an object.

But there might be situations - and in fact these are what dependency injection is about - where you do not want to register a concrete instance. You might not already have all the dependencies for creating an instance in place. So all you want to do is to register the required build instruction for generating an instance.

This is something that you can do by registering a wrapper object that implements the Horde_Injector_Binder interface. This wrapper object needs to be capable of creating the concrete instance:

<pre><code>class Binder implements Horde_Injector_Binder
{
 public function create(Horde_Injector $injector)
 {
 return 'constructed';
 }
 public function equals(Horde_Injector_Binder $binder)
 {
 return false;
 }
}

$a = new Horde_Injector(new Horde_Injector_TopLevel());
$a-&gt;addBinder('constructed', new Binder());
var_dump($a-&gt;getInstance('constructed'));
</code></pre>

<pre><code>string(11) &quot;constructed&quot;</code></pre>

The example above demonstrates this approach by using the dummy Binder class which implements Horde_Injector_Binder. Once getInstance('constructed') is called on the injector object it will 
determine that there is no concrete instance for 'constructed' yet. It then looks for any binders that might be capable of creating 'constructed' and calls the create() function of such a binder.

Here the binder is simple again and does not even return an object but a simple string. It also makes no use of the Horde_Injector instance delivered as argument to the create() function. Usually the provided injector will be used to retrieve any missing dependencies for the instance to be created.

<h3 id="toc4"> Default Binders</h3>
Horde_Injector comes with two default Binder implementations so that you don't have to define your own binders.

Lets look at the factory binder first:

<pre><code>class Greet
{
 public function __construct($somebody)
 {
 $this-&gt;somebody = $somebody;
 }

public function greet()
 {
 print 'Hello ' . $this-&gt;somebody;
 }
}

class Factory
{
 public static function getGreeter(Horde_Injector $injector)
 {
 return new Greet($injector-&gt;getInstance('Person'));
 }
}
 
$a = new Horde_Injector(new Horde_Injector_TopLevel());
$a-&gt;setInstance('Person', 'Bob');
$a-&gt;bindFactory('Greet', 'Factory', 'getGreeter');
$a-&gt;getInstance('Greet')-&gt;greet();
</code></pre>

<pre><code>Hello Bob</code></pre>

This time the Factory in the example above really pulls a dependency: a person. We explicitly registered the string &quot;Bob&quot; with the injector and associated it with the interface name &quot;Person&quot;.

The Horde_Injector_Binder_Factory binder can be registered with the injector using the &quot;bindFactory()&quot; shortcut. It takes the interface name (here it is &quot;Greet&quot;) and requires a class and a method name. This is assumed to be the factory creating the concrete instance.

Once getInstance('Greet') is called the injector refers to the binder (as no concrete instance has been created yet). The binder delegates to the factory to actually create the object.

The whole thing is also possible with a little bit more magic. The second approach implemented by Horde_Injector_Binder_Implementation requires type hinting to work:

<pre><code>interface Person
{
 public function __toString();
}

class World implements Person
{
 public function __toString()
 {
 return 'World';
 }
}

interface Greeter
{
 public function greet();
}

class Hello implements Greeter
{
 public function __construct(Person $somebody)
 {
 $this-&gt;somebody = $somebody;
 }

$a = new Horde_Injector(new Horde_Injector_TopLevel());
$a-&gt;bindImplementation('Person', 'World');
$a-&gt;bindImplementation('Greeter', 'Hello');
$a-&gt;getInstance('Greeter')-&gt;greet();
</code></pre>

<pre><code>Hello World</code></pre>

The crucial part here is that the &quot;Hello&quot; class indicates in its constructor that it requires an object implementing the interface &quot;Person&quot;. Horde_Injector is capable of detecting this via reflection. It will automatically search for the dependency and try to create an instance implementing this interface.

In order for this to work we bind two classes to two interfaces: &quot;World&quot; to &quot;Person&quot; and &quot;Hello&quot; to &quot;Greeter&quot;. Once the injector tries to create the &quot;Greeter&quot;-instance it will be able to fetch the required &quot;Person&quot; dependency by creating a &quot;World&quot; object.

In case you remember that printing the little resulting string can be slightly easier while even using far less code: Dependency injection is meant for complex situations.

Nevertheless the example hopefully demonstrates how to handle different implementation options using dependency injection: You may have different drivers that all fulfill a given interface. The Horde_Injector gives you an easy method to define which drivers you actually want to use without actually instantiating them. The concrete setup will only be build once you really need a concrete instance.

<h2 id="toc5"> Preparing a class for Horde_Injector</h2>
Assume you have the following simple class that represents a common structure found in many of the Horde packages:

<pre><code>class Horde_X
{
 /**
 * Instance object.
 *
 * @var Horde_X
 */
 protected static $_instance;

/**
 * Pointer to a DB instance.
 *
 * @var DB
 */
 protected $_db;

/**
 * Attempts to return a reference to a concrete Horde_X instance.
 *
 * @return Horde_X The concrete Horde_X reference.
 * @throws Horde_Exception
 */
 public static function singleton()
 {
 if (!isset(self::$_instance)) {
 self::$_instance = new Horde_X();
 }

return self::$_instance;
 }

/**
 * Constructor.
 */
 public function __construct()
 {
 global $conf;

$this-&gt;_db = DB::connect($conf['sql']);
 }
}
</code></pre>

The class obviously depends on a database connection. The constructor above does not allow for dependency injection as it constructs the database connection itself. It uses the global variable $conf in order to get the settings for this connection. A constructor allowing dependency injection would look like this:

<pre><code> /**
 * Constructor.
 *
 * @param DB $db A database connection.
 */
 public function __construct(DB $db)
 {
 $this-&gt;_db = $db;
 }</code></pre>

Of course this connection must be provided from somewhere. The application using Horde_X might simply provide it when creating the Horde_X instance. If the application is however using a dependency injection framework then this framework would be required to provide the required database connection.

<h3 id="toc6"> Getting rid of singletons?</h3>
From the viewpoint of dependency injection Horde_X can be used now as it allows external injection of its dependencies. We could throw away the singleton now. However there might be some reasons why we would like to keep the singleton() method. One of the reasons might be backward compatibility as some other classes or applications are bound to use the method. Another reason might be that we want to clarify how to get a functional instance of the class to somebody just looking at the Horde_X class.

We could keep the following singleton method:

<pre><code> public static function singleton()
 {
 if (!isset(self::$_instance)) {
 global $conf;

$db = DB::connect($conf['sql']);
 self::$_instance = Horde_X($db);
 }

return self::$_instance;
 }
</code></pre>

The final result that can be used with a dependency injection framework and still provides a backward compatible singleton method:

/**
 * Attempts to return a reference to a concrete Horde_X instance.
 *
 * @return Horde_X The concrete Horde_X reference.
 */
 public static function singleton()
 {
 if (!isset(self::$_instance)) {
 global $conf;

return self::$_instance;
 }

/**
 * Constructor.
 *
 * @param DB $db A database connection.
 */
 public function __construct(DB $db)
 {
 $this-&gt;_db = $db;
 }
}
</code></pre>

<h2 id="toc7"> Dependency Injection Container FAQ</h2>

<h3 id="toc8"> Where can <tt>Horde_Injector</tt> be used?</h3>
In the application layer only. If you use this in your business models I will find you and beat you to death with a shoe.

<h3 id="toc9"> How do I provide <tt>Horde_Config</tt> values to my business models?</h3>
Factories.

class FactoryX {
 public function create(Horde_Injector $injector) {
 $setting = $injector-&gt;getInstance('Horde_Config')-&gt;get('main', 'setting');
 return new X($setting);
 }
}
</code></pre>

<h3 id="toc10"> I have an <tt>array</tt>-typed parameter in my constructor, do I have to use a factory to provide the array of values?</h3>
Maybe. It depends on which you believe is easier. Consider this example where a more specific <a class="newpage" href="/ArrayObject?referrer=Doc%2FDev%2FInjector">ArrayObject</a> is used. Does this array get reused? If so it may be worth creating a special extension of <a class="newpage" href="/ArrayObject?referrer=Doc%2FDev%2FInjector">ArrayObject</a>.

class Dictionary {
 public function __construct(Dictionary_Sources $sources) {
 ...
 }
}

class Dictionary_Sources extends ArrayObject{}

class Dictionary_Sources_Factory {
 public function create(Horde_Injector $injector) {
 return new Dictionary_Sources(array(
 $injector-&gt;getInstance('Dictionary_Source_Cache'),
 $injector-&gt;getInstance('Dictionary_Source_Db'),
 $injector-&gt;getInstance('Dictionary_Source_Json')
 ));
 }
}
</code></pre>

You're probably thinking that you could just create a factory to build your Dictionary object since you need to write a factory anyways. The real benefit is when you decide that Dictionary needs a new collaborator, say a <tt>Logger</tt>. If you have defined a factory for your <tt>Dictionary</tt> object, then you must edit that factory and create a <tt>Logger</tt> and pass it to your <tt>Dictionary</tt>. With the method above, you would simply need to edit your constructor, and the <tt>Logger</tt> will be provided for you. This gives you much greater flexibility, especially if you have objects that can operate on the same array of objects, but need slightly different configuration.

<h2 id="toc11"> Dependency Injection Container Spec</h2>
<hr />

<h3 id="toc12"> Terms</h3>
<ul>
 <li>Dependency Injection - DI</li>
 <li>Dependency Injection Container - DIC</li>
</ul>

<hr />

<h3 id="toc13"> Requirements</h3>
Switching business layer implementations across an application is expensive.

DI decouples our business layer classes from other business layer classes but doesn't solve the problem of decoupling our application layer classes from our business layer classes. Without functionality to tackle this issue, business layer class configuration is duplicated throughout the application.

As expense is the primary concern, any solution to the problem must not simply move the expense to initial application layer implementation.

<hr />

<h3 id="toc14"> Functional Spec</h3>

<h4 id="toc15"> Goals</h4>
<ul>
 <li>Decouple application layer (controller) from business layer (model)</li>
 <li>Allow easy use of models which are decoupled from their dependencies using DI</li>
 <li>Favor code over configuration</li>
 <li>Simple, testable design</li>
</ul>

<h4 id="toc16"> Features</h4>
A DIC allows you to make typically difficult configuration changes, like changing an entire application from using one service implementation to another, with simple modifications in one localized place.

A DIC manages the way your objects are wired together. It makes the wiring entirely configurable per-application, per-module, and all the way down to per single object instantiation. Needing configuration to make lots of individual objects is inefficient and hard to maintain which is why its reserved for only special cases. In reality most classes rely on only a few service objects (configuration, database connection, cache, etc.) and these object most often will have identical configurations in the entire application with a few per-module exceptions.

DICs don't require configuration for every object you want them to create. In most cases class dependencies will be detectable and the DIC will be able to provide those dependencies automatically.

Using a DIC for all application-level object creation makes your application unit-testable. Dependencies can easily be swapped out with mock objects because all dependencies are provided to the application using a DIC.

<hr />

<h3 id="toc17"> Technical Spec</h3>
The name of our DIC implementation is <tt>Horde_Injector</tt>. <tt>Horde_Injector</tt> can be told how to create objects using factories or it can try to create them itself using reflection. It can also be told to return an already-instantiated object when an interface is requested. Finally, if the requested interface has not been bound to a factory, implementation, or instance the injector will attempt to create the object using an implementation binder. For this to be successful the interface must actually be a concrete class.

<h3 id="toc18"> Binders</h3>
The way we tell <tt>Horde_Injector</tt> how to create objects is using &quot;binders&quot; (which implement <tt>Horde_Injector_Binder</tt>). <tt>Horde_Injector</tt> maintains references to binders. References can be added in two ways:

<pre><code>$binder = new Horde_Injector_Binder_X($param1);
$injector-&gt;addBinder($interface, $binder)
</code></pre>

<pre><code>$injector-&gt;bindX($interface, $param1);
</code></pre>

<h5 id="toc19"> Factory binders</h5>
[Factories|<a href="http://en.wikipedia.org/wiki/Factory_method_pattern" class="external" target="_blank" title="http://en.wikipedia.org/wiki/Factory_method_pattern">http://en.wikipedia.org/wiki/Factory_method_pattern</a>] are classes with methods which instantiate and return objects. In the following example an interface is bound to a factory. If <tt><a class="newpage" href="/DataSourceX?referrer=Doc%2FDev%2FInjector">DataSourceX</a></tt> had dependencies it could instantiate them itself or ask <tt>$injector</tt> for those dependencies.

class DataSourceFactory {
 public function create(Horde_Injector $injector) {
 return new DataSourceX();
 }
}
</code></pre>

Factory method names can be whatever you want but they must only require one parameter and it must be a <tt>Horde_Injector</tt> object.

<h5 id="toc20"> Implementation binders</h5>
Reflection allows us to programmatically inspect the structure of the class that is to be instantiated. By reading the interface types of the class constructor's parameters and then asking the injector to create those objects as well we try to provide the requested class's constructor with all its dependencies.

<pre><code>$injector-&gt;bindImplementation('DataSourceInteface', 'DataSourceX');

class DataSourceX {
 public function __construct(DependencyY $dependencyY) {
 ...
 }
}
</code></pre>

<h5 id="toc21"> Choosing a binder</h5>
Use a factory binder if:

<ul>
 <li>The class you are instantiating has any untyped parameters</li>
 <li>You wish to create an instance of a class, that needs to have 2 objects of the same interface, but configured differently. [See FAQ|Dependency Injection Container FAQ]</li>
</ul>

Use an implementation binder if:

<ul>
 <li>The class you are instantiating has only typed parameters</li>
</ul>

<h4 id="toc22"> Instances</h4>
<tt>Horde_Injector</tt> maintains an array of object instances which are bound to interfaces. Instance binding happens two different ways: setting the instance binding manually, or by asking the injector to give you an instance (if it doesn't have one, then one is created and a reference to the internal instances array is added.)

<pre><code>$instance = new X();
$injector-&gt;setInstance('X', $instance);
</code></pre>

<h4 id="toc23"> Getting objects</h4>
For requested objects to be returned the injector must already have all the information present it needs to create the object.

<h5 id="toc24"> Creating a new instance</h5>
To get a guaranteed new object use createInstance. References to instances retrieved in this manner are not stored. They will not be available to other objects unless you use <tt>setInstance</tt> to store the instance on the Injector.

<pre><code>$injector-&gt;createInstance('X');
</code></pre>

Although the returned object will be new, its dependencies may not be. The injector will search its internal instances array for an instance matching the dependency's interface and if a match if found it will be used. If for some reason you need to guarantee that all dependencies are new, then you should consider using a factory binder.

<h5 id="toc25"> Getting an instance</h5>
As previously mentioned instances are pooled by the injector, so getInstance() gives developers the opportunity to reuse objects. If an instance exists for the requested interface it will be returned, otherwise it will be created, added to the injectors internal instances array, and returned.

<pre><code>$injector-&gt;getInstance('X');
</code></pre>

<h4 id="toc26"> Scoping with child injectors</h4>
<tt>Horde_Injector</tt> implements the [Chain of Responsibility|<a href="http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern" class="external" target="_blank" title="http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern">http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern</a>] design pattern with bindings and instances. What this means is that injectors will try to give you a binder or instance but if it doesn't have it it will ask its parent injector for them and try returning that to you.

<pre><code>$injector-&gt;bindFactory('InterfaceX', 'FactoryX', 'create');
$childInjector = $injector-&gt;createChildInjector();
$x = $childInjector-&gt;createInstance('InterfaceX'); // success!!!
</code></pre>

<pre><code>$childInjector = $injector-&gt;createChildInjector();
$childInjector-&gt;bindFactory('InterfaceY', 'FactoryY', 'create');
$y = $injector-&gt;createInstance('InterfaceY'); // failure!!!
</code></pre>

<pre><code>$x = $injector-&gt;getInstance('X');
$childInjector = $injector-&gt;createChildInjector();
$x === $childInjector-&gt;getInstance('X'); // true
</code></pre>

Child Injectors allow you to configure sub-modules of code differently, without leaking any state into the global scope.