Brandon Savage has a tutorial posted to his site covering the use of setter injection, some of the issues that can come with using it and how to avoid it.

PHP more or less has two kinds of dependency injection available: constructor injection, and setter injection. Constructor injection is the process of injecting dependencies through the constructor arguments. The dependencies are injected via the constructor, on object creation, and the object has them from the very beginning.

Setter injection is different; instead of providing the dependencies at construction time, the dependencies are provided via setter methods, once the object has been constructed. This allows the flexibility to configure the object during the runtime, rather than at construction.

He goes on to point out two flaws with setter injection: "half-baked" objects and the injection of potentially unused objects/resources. He spends the remainder of the post covering each of these topics more specifically and wraps it up with a recommendation to avoid it if possible and opt for useful, "fully baked" objects injected via the constructor instead.

On the TutsPlus.com site today they've posted a tutorial sharing some examples of dependency injection using the Symfony DependencyInjection component.

In this article, we'll look at some examples of using the Symfony DependencyInjection component. You'll learn the basics of dependency injection, which allows cleaner and more modular code, and you'll see how to use it in your PHP application with the Symfony component.

The tutorial starts by introducing the component and what kind of functionality it includes to help register and fetch services on demand. It then walks through the installation (via Composer) and the installation of other optional related packages. It then dives into the code, showing how to put the package to use to register a new service and pull it back out to use. The article then moves on and shows a more "real world" example with services that have dependencies and configuring it in a YAML configuration file.

Rob Allen has continued his series of posts covering the use of PHP on the OpenWhisk platform. In his latest tutorial he shows how to use dependency injection for use in "non-trivial PHP applications".

Any non-trivial PHP applications use various components to do its work, from PDO though to classes from Packagist. It’s fairly common in a standard PHP application to use Dependency Injection to configure and load these classes when necessary. How do we do this in a serverless environment such as OpenWhisk?

This question comes up because we do not have a single entry point into our application, instead we have one entry point per action. If we’re using Serverless to write an API, then we probably

He uses a common connection type - PDO to a database - to illustrate a method for injecting dependencies in a serverless application. In his example, he starts with a simple script that returns a set of "todo" items from the database (with the PDO connection code embedded in it). Using dependency injection is a better way to manage that PDO connection so he shows how to update it to use the Pimple DI container and inject it via the constructor to make it available to the rest of the application.

Tomas Vortuba has continued his series looking at building command line tools with PHP and the Symfony Console component. In this latest post he shows how to create an application using dependency injection in just four files.

Series about PHP CLI Apps continues with 3rd part about writing Symfony Console Application with Dependency Injection in the first place. Not last, not second, but the first. Luckily, is easy to start using it.

He starts with a bit of information about how Symfony has evolved from the previous method of using controllers as services to create CLI tools. Now commands can be used as services and be pushed into/pulled from a dependency injection container. He then walks through the three steps to adding a command as a service:

1. updating the services.yml file to include linking for the console application class.
2. updating the Kernel to load the yml configuration.
3. creating the bin file to execute the application.

With this structure in place, he then shows how to share functionality between services using a CompilerPass.

In a new post to his site, Tomas Votruba has a post sharing his thoughts about why you should combine Symfony Console and dependency injection and how it can help tp resolve issues with the overuse of static methods and functions.

I saw 2 links to SymfonyConsole in today's Week of Symfony (what a time reference, huh?). There are plenty of such posts out there, even in Pehapkari community blog: Best Practice for Symfony Console in Nette or Symfony Console from the Scratch. But nobody seems to write about the greatest bottleneck of Console applications - static cancer. Why is that?

He starts with some examples of the current status in PHP console applications including PHP_CodeSniffer, PHP CS Fixer and PHPStan. Each of these load commands to add functionality to the application which, as the application grows and changes, could be difficult to maintain in the future. Instead he recommends making use of dependency injection. He then talks about how containers are already a part of the console applications mentioned and finishes up focusing on the combination of the SymfonyConsole and SymfonyDependencyInjection components.

Tomas Votruba has a new post to his site showing how to "turn your Symfony project to legacy" through the use of action injection for mapping controllers and methods to request handling.

The other day I saw the question on Reddit about Symfony's controller action dependency injection. More people around me are hyped about this new feature in Symfony 3.3 that allows to autowire services via action argument typehints. It's new, it's cool and no one has a bad experience with it. The ideal candidate for any code you write today.

Since Nette and Laravel introduced a similar feature in 2014, there are empirical data that we learn from.

Today I'll share the experience I have from consulting few Nette applications with dangerous overuse of this pattern and how this one thing turned the code to complete mess.

He starts off with some example code, asking where the issue is showing a call to a service handler to process the an argument. This would be used when a controller is registered as a service to help reduce the amount of work to define routes and add more "magic" for request handling. While the idea sounds good, he points out some of the issues with the approach including dependency injection problems and how, if it expands outside of controllers, it can lead to a poorly written application.

In a previous post to his site Andrew Embler provided a "concrete guide to dependency injection", a method to help make code easier to test and more flexible/maintainable. In this latest post he continues the series and moves to the next topic: dependency injection containers.

I recently posted about dependency injection, a guide that I hope was easy to read and understand. It's a topic that's confusing, due in no small part to its name. As I mention there, the same term defines the simple process of externally providing instance variables to a class as it does to the Container object's magical auto-instantiation of object (which also "injects dependencies.")

I'd like to talk a bit more about that. Now that we understand the term "Dependency Injection" (which is simply providing classes to classes through a constructor or a setter), let's talk about how we might make this a little less onerous.

He starts with an example from the concrete5 project where a class would require three object instances each time it would be created. Fortunately the software includes a make command that does some of this work for you. It makes use of a dependency injection container behind the scenes to get the instances it needs. He then covers cascading dependencies, some special logic for class creation and how to "get fancy with it" by defining custom logic when an instance is created.

In a new post to his site Andrew Embler provides a concrete guide to dependency injection, a look at some of the foundational principles behind dependency injection, some problems and how they could be resolved.

As we develop concrete5, we are very conscious about keeping the code base modern, so that we don't have to go through a massive, painful rewrite like we did with version 5.7. This means that we're frequently deep in the weeds, applying new concepts and functionality to new and old code alike.

[...] Here, we're going to talk about Dependency Injection. There are numerous tutorials, blog posts and Stack Overflow questions, regarding Dependency Injection – but there's always room for some more.

He starts with a look at the "old days" where dependencies were created inside of the class methods as needed and not shared. He then covers some of the problems with this approach and how a move to dependency injection (DI) can help. In his example a database object instance is created inside of the method each time it's' needed. The move to DI helps to resolve those issues by passing in the database instance instead. He finishes the post trying to clear up some of the terminology confusions around DI and briefly mentions containers (dependency injection containers) and the role they play.

In a post to his site Nikola Poša looks at a method that can be used to provide a slightly different object from a dependency injection container based on other criteria: making use of a factory as a service.

Dependency Injection Containers are a great invention - when used the right way, they allow us to keep our factories and assembly logic of services outside the core business logic of our application.

By default, a service created is shared, meaning that exactly the same instance will be returned whenever service is retrieved from a container. This is a desired behaviour in most of the cases. [...] Yet certain use cases may require services to be created conditionally during runtime, such as for example based on the value of a parameter resolved from the current request.

He first covers some of the anti-patterns that could be used to resolve this issue: a setter method on the returned object, using a service manager or creating a static factory instead. He offers a solution to the problem that makes use of a factory inside of the DI container. This factory then uses configuration values from the container to set up the object and return it.

In a new post to his site Nikola Poša looks at dependency injection containers and shares what he thinks is the right way to use them in your applications.

DIC stands for Dependency Injection Container, which is a tool that manages the construction and wiring up of application services. It closely relates to the letter "D" of a SOLID acronym - Dependency Inversion Principle and is employed to facilitate adhering to the principle.

By their nature, DI Containers are also Service Locator implementations, design pattern that is the exact opposite to Dependency Injection. Because of that, DI Container is a double-edged sword which can mislead you if not used wisely, and ironically bring your code into a state in which there is no dependency injection at all.

He starts off by talking about two kinds of code in an application: core versus assembly. In this case "core" code is the piece of the application that are then used by "assembly" code to make things happen. He suggests that the DIC shouldn't leak into the core and should be put behind a separation between the core code and assembly code. He includes some sample code illustrating what he means and the idea of splitting out the DIC configuration to help that layer clean.