In this post to his site Marc Scholten talks about something that's become a side effect of using the inversion of control design pattern in PHP applications (specifically related to dependency injection): added accidental complexity.

Modern PHP development favors the use of inversion of control to keep software more configurable and flexible. This leads to the problem that one now has to create a big graph of objects to use the application. As a solution to avoid redundant setup code, service containers like the symfony2 dependency injection component are used.

The goal of a service container is to centralize the construction of big object graphs. [...] Simple, right? Actually it’s not. Commonly used service containers are complex solution for simple problems.

He illustrates with an example using the Symfony services container, a piece of the framework that allows the definition of dependency relationships via a YAML formatted file. While this configuration seems simple enough, he points out that more complex dependencies (ones that could easier be set via a "set" method) become more difficult to define when limited by the service container config structure. He also points out that it makes static analysis of the code much more difficult with dependencies being dynamically fetched from the container instead of directly related. He offers an alternative to this complex container setup, however: a simple method (or methods) inside of a factory class that creates the objects, injects the required dependencies. This makes it much easier to call from the service container instance and configuration and even a "create container" call to set all of the dependencies up at once. He ends the post with some advantages of this approach and a takeaway or two to keep in mind when managing your object dependencies.

In a post to his site Mark Ragazzo looks at immutable objects - what they are and how they can be used in a PHP application with some "final" functionality.

In this short article we will see what immutable objects are and why we should consider to use them. Immutable object is an object that does not change its state after it was created. Immutable objects usually are very simple. You may already seen them as enum types or primitives like DateTimeImmutable.

Further in this article you will learn that making simple objects immutable may save significant amount of your time by making impossible to make certain types of mistakes.

He starts with a list of a few things to remember when implementing immutable objects (like using the "final" keyword) and problems that can come without them. He then gets into some examples, showing how to create immutable Address and Money objects and how to use them when you need to update/get values from the object. He also covers some common "accidental mutability" cases like leaking internal object references and inheritance problems.