PHPackages                             stellarwp/container - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility & Helpers](/categories/utility)
4. /
5. stellarwp/container

ActiveLibrary[Utility & Helpers](/categories/utility)

stellarwp/container
===================

A PSR-11 Dependency Injection (DI) container for use in WordPress codebases

v0.1.1(4y ago)919.8k1[2 PRs](https://github.com/stellarwp/container/pulls)MITPHPPHP ^5.6 | ^7.0 | ^8.0

Since Feb 22Pushed 1y ago11 watchersCompare

[ Source](https://github.com/stellarwp/container)[ Packagist](https://packagist.org/packages/stellarwp/container)[ RSS](/packages/stellarwp-container/feed)WikiDiscussions develop Synced 1mo ago

READMEChangelog (2)Dependencies (5)Versions (5)Used By (0)

StellarWP Dependency Injection (DI) Container
=============================================

[](#stellarwp-dependency-injection-di-container)

[![CI Pipeline](https://github.com/stellarwp/container/actions/workflows/continuous-integration.yml/badge.svg)](https://github.com/stellarwp/container/actions/workflows/continuous-integration.yml)

This library contains [a PSR-11-compatible Dependency Injection (DI) container](https://www.php-fig.org/psr/psr-11/) to aid in resolving dependencies as needed throughout various applications.

What is Dependency Injection?
-----------------------------

[](#what-is-dependency-injection)

In its simplest terms, Dependency Injection is providing dependencies to an object rather than making the object try to create/retrieve them.

For instance, imagine that we're building a plugin that contains different "modules", each of which might receive a global `Settings` object.

With dependency injection, our module definition might look like this:

```
namespace Acme\SomePlugin;

class SomeModule extends Module
{

  /**
   * @var Settings
   */
  protected $settings;

  /**
   * @param Settings $settings
   */
  public function __construct(Settings $settings)
  {
    $this->settings = $settings;
  }
}
```

By injecting the `Settings` object, we're able to create a single instance of the object and more-easily inject [test doubles](https://phpunit.readthedocs.io/en/9.5/test-doubles.html) in our tests.

Now, compare this to a version of the same class that *doesn't* use dependency injection:

```
namespace Acme\SomePlugin;

class SomeModule extends Module
{

  /**
   * @var Settings
   */
  protected $settings;

  public function __construct()
  {
    $this->settings = new Settings();
  }
}
```

Under this model, each instance of the module will be responsible for instantiating their own instance of the `Settings` object, and we lack the ability to inject test doubles.

Furthermore, if the `Settings` class changes its constructor method signature, we'd have to update calls to `new Settings()` throughout the application.

This is one of the major benefits of a DI container: we can define how an object gets constructed in one place, and then recursively resolve dependencies.

### Dependency Injection vs Service Location

[](#dependency-injection-vs-service-location)

It's worth mentioning that the container is designed to be used for Dependency Injection, **not** as a Service Locater.

What's a Service Locater? Imagine instead of injecting the `Settings` object into our integrations, we instead injected the entire `Container` object. Instead of giving the class the tools it needs to do its job, we're instead throwing the entire application at it and saying "here, you figure it out."

[The PSR-11 meta documentation has a good breakdown of these patterns](https://www.php-fig.org/psr/psr-11/meta/#4-recommended-usage-container-psr-and-the-service-locator).

Installation
------------

[](#installation)

It's recommended that you install the DI container as a project dependency via [Composer](https://getcomposer.org):

```
$ composer require stellarwp/container
```

Next, create a new class within your project that extends the `StellarWP\Container\Container` class:

```