To inject or to new?

Question

With regards to using class objects within another class what is the best practice? To pass the class objects in the class _construct statement or create a new class object?

Example 1:

class Foo {
    private $bar;

    public function __construct($bar){
       $this->bar = $bar;
   }
}

Or Example 2 :

class Foo {

    private $bar;

    public function __construct(){
        $this->bar= NEW bar;
    }    
}

I'm aware that obviously it's taken for granted that the class file must already be included somewhere else, and in the first instance a class object of this type would need to exist already, but I want to know what the advantages are each method are, as I have a lot of classes I need to code that use a database object and I need the best way to pass this into the classes. Is there a third option that's better than these two?

From what I can understand, the advantage of the first one could be a few less lines of coding and in the case of a DB, not having a new connection created. The second one might be better however because it's more self contained? Anyhow I thought I'd ask the experts.

Answer 1

The first. (This approach is called Dependency Injection).

The constructor asks for whatever the object in questions needs in order to work. This way, it's pretty clear from the methods alone (what they need, and what they return), what it does. Without even looking at the source code.

A way to improve your code would be to introduce type hinting into your method:

class Foo {
    private $bar;

    public function __construct(Bar $bar){
       $this->bar = $bar;
   }
}

So that only Bar objects may be passed in.

---

Advantages of Dependency Injection

• Very readable.
• Ability to tell the method's dependencies without viewing the source code.
• Makes Unit Testing possible.
• ^*Saves kittens from God's wrath.

_{* Disclaimer: No kittens were harmed during the manifestation of this answer}

Answer 2

You should go for option 1, as this is the simplest form of dependency injection.

In option 1:

• classes are independent of each other
• classes can be tested independent, using a mock for the bar class

Answer 3

In general, I'd chime in with the DI crowd for reasons outlined in How to Think About the “new” Operator with Respect to Unit Testing:

But the reason why Dependency Injection is so important is that within unit-tests you want to test a small subset of your application. The requirement is that you can construct that small subset of the application independently of the whole system. If you mix application logic with graph construction (the new operator) unit-testing becomes impossible for anything but the leaf nodes in your application.

Separating your code into creator graphs and collaborator graphs will help to keep your code maintainable and testable. Even better, code against interfaces and it will be very easy to swap out concrete implementations against other ones. This makes changing your code simple, because you don't have to wade through your code hunting for hardcoded dependencies.

For instance, assuming your Bar requires a Logger, you'd do

class Foo
{
    private $logger;

    public function __construct(LogInterface $logger)
    {
        $this->logger = $logger;
    }
}

And then you pass in any concrete implementation implementing that LogInterface, like a Database Logger or a StdOutLogger or maybe a Composite Logger holding both of these. Another example would be a Database object. You can create that once in your bootstrap and then pass it to the objects making use of it.

When in doubt, go with Dependency Injection.

However, you don't always have to inject stuff. It depends whether the object (your Bar) is an Injectable or a Newable. To quote Misko Hevery:

An Injectable class can ask for other Injectables in its constructor. […] Injectables tend to have interfaces since chances are we may have to replace them with an implementation friendly to testing. However, Injectable can never ask for a non-Injectable (Newable) in its constructor. This is because DI framework does not know how to produce a Newable. […] Some examples of Newables are: Email, MailMessage, User, CreditCard, Song. If you keep this distinctions your code will be easy to test and work with. If you break this rule your code will be hard to test.

In a nutshell, when you have something that cannot be reasonably injected, because it is based on user-supplied or runtime information, you can new it. This is especially true for Value Objects and Data Types:

class Foo
{
    private $storage;

    public function __construct()
    {
        $this->storage = new SplObjectStorage;
    }
}

There is no point in injecting SplObjectStorage. It's just a data type.

Answer 4

Others have already answered your question - definitely go with the first approach, which uses Dependency Injection.

I just wanted to chip in with another popular alternative you may not be aware of: using a Dependency Injection Container.

A great, simple example of this is Pimple; developed by Fabien Potencier, the man behind the Symfony frameworks.

Example 3:

# In a bootstrap file...
require_once '/path/to/Pimple.php';

$container = new Pimple();
$container['bar'] = function ($c) {
    return new Bar(/** If bar has dependencies, put them here **/);
};

$container['foo'] = function ($c) {
    return new Foo($c['bar']);
};

# You'd still inject the service using DI, because it's not good 
# practice for your objects to rely directly on the container

class Foo {
    private $bar;

    public function __construct($bar){
       $this->bar = $bar;
   }
}

# The difference would be how you call Foo...
$foo = $container['foo'];

# So now your code doesn't need to know about the dependencies, and it's easy 
# to change them at any time by making a single change in your configuration

Symfony2 uses a more robust Container, which is also available as a standalone compenent. But Pimple is probably your best bet unless you're developing a large-scale application.

Answer 5

I'd say use the 1st option. While doing so, I'd say programming to abstractions is a better idea than programming to an implementation.

Your first option is a form of aggregation while the second is that of composition. The benefit you would get with abstractions is that your client class that uses class FOO will be able to get FOO to do some activity based on a particular implementation of the interface it decides to send into the constructor..

A C# example below

    class Foo {
    private IBar bar;

    public Foo(IBar obj){
       this.bar = obj;
   }

   public void myFooMethod()
   {
      bar.ExecuteMethod();
   }
}

The class calling FOO

    public class MyCallingClass
    {

       public void CallFooMethod()
       {
          IBar bar1Obj = new BAR1();
          Foo fooObject = new Foo(bar1Obj);
          fooObject.ExecuteMethod();
//or
          IBar bar2Obj = new BAR2();
          fooObject = new Foo(bar2Obj);
          fooObject.ExecuteMethod();
//or
          IBar bar3Obj = new BAR3();
          fooObject = new Foo(bar3Obj);
          fooObject.ExecuteMethod();

       }

    }

Now my calling class can pass any implementation of IBar to the FOO class.

Hope this helped.

Answer 6

Ok, Dependency Injection is wonderful, and helpful and saves kittens, so I'm not going to discuss it in detail.

Instead, I'm going to suggest you implement both solutions:

class Foo {
    private $bar;

    public function __construct($bar = null){
       $this->bar = isset($bar) ? $bar : new Bar();
   }
}

That way, you can use the default class by default, and if you need to change the functionality, you can do that too.