Download the PHP package monomelodies/disclosure without Composer
On this page you can find all versions of the php package monomelodies/disclosure. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download monomelodies/disclosure
More information about monomelodies/disclosure
Files in monomelodies/disclosure
Package disclosure
Short Description PHP5 dependency injection framework
License MIT
Informations about the package disclosure
Disclosure
PHP5 dependency injection and service locator framework. Most existing DI or Inversion of Control (IoC) solutions depend on extensive configuration files to define dependencies. This sucks; Disclosure is better and simpler (we think).
As of version 2.0, Disclosure is fully compatible with the (upcoming) PSR
recommendation for Container objects. A copy of the as-yet unrealeased
PSR\Container
interface is included in the package (until they finally
realease it...).
Installation
Composer (recommended)
Manual installation
- Get or clonse the code;
- Register
/path/to/disclosure/src
for the namespaceDisclosure\\
in your PSR-4 autoloader; - Register
/path/to/disclosure/psr
for the namespacePsr\\Container\\
in your PSR-4 autoloader
Usage
Add your dependencies to a Container
object somewhere. It often makes sense to
do this in a central file (e.g. src/dependencies.php
), but it's also perfectly
fine to do it alongside your class definitions.
The container will now assosiate the foo
key with an object of instance Foo
.
The naming of the key is irrelevant; just remember that they must be unique.
Tell your classes what they should depend on using the inject
method supplied
by the Injector
trait:
inject
accepts a random number of arguments, where each argument is their a
string with a depedency name, or a callable with dependency names as arguments.
Which style you use is up to your own preference.
Whoah! Why not simply do $this->foo = new MyDependency;
?
There's plenty of reasons for using a Container instead of the new
keyword
all over the place, but the main ones are:
- Hard-coding instances makes it hard to inject mocks during unit tests (you
could use
class_alias
for that, but seriously). - It causes tight coupling between classes, which is a Bad Thing(tm).
- It makes it easier to inject objects as a Service locator (i.e., one instance of an object instead of a new one each time).
No, in the above example it doesn't add much, but see the complete documentation for real-world, practical examples of why dependency injection is generally a good idea.