Matthias Noback has continued his series about "mocking the edges" in your unit testing with this new post. In it, he talks about mocking "the network", those places where your application reaches out to external services to access data or perform other operations.

In this series, we've discussed several topics already. We talked about persistence and time, the filesystem and randomness. The conclusion for all these areas: whenever you want to "mock" these things, you may look for a solution at the level of programming tools used (use database or filesystem abstraction library, replace built-in PHP functions, etc.). But the better solution is always: add your own abstraction.

[...] The same really is true for the network. You don't want your unit tests to rely on a network connection, or a specific web service to be up and running. [...] The smarter solution again is to introduce your own interface, with its own implementation, and its own integration test. [...] Though this solution would be quite far from traditional mocking I thought it would be interesting to write a bit more about it, since there's also a lot to say.

In his example he shows the use of a file_get_contents call to fetch stock information. He introduces a ExchangeRateService interface with a getFor method to provide structure for the "wrapper" around the network call. He then covers the idea of an "anti-corruption layer" to change up the interface to use models instead of just a string value (code included). He ends the post talking about the inversion of the dependency - the option to have a job pull the value out-of-band and then have the application use that value.

The MyBuilder.com Tech blog has a tutorial posted showing you how to work with binary trees in PHP, specifically how to perform insertion, removal and inversion operations on their data.

Recently Max Howell (creator of Homebrew) posted an interesting tweet in regard to Google's interview process. In this tweet he mentioned how one of the proposed questions was to white-board a solution to invert a binary tree. Over the past couple of years I have been interested in exploring fundamental Computer Science data-structures and algorithms. As a result, I thought it would be interesting to explore this structure and associated operations in more depth - using immutable and mutable PHP implementations to clearly highlight the benefits garnered from each approach.

He starts with a brief definition of what a binary search tree is just to be sure everyone is on the same page. He then gets into the code to represent a Node, a simple class that has a value and "left" and "right" variables to contain each of the possible two child nodes. He then goes through each of the operations (insertion, removal and inversion) showing code examples for both mutable and immutable methods.

The Laravel News site has a post today linking to five handy resources you can use to learn about the Laravel IoC (inversion of control, dependency injection) container.

The Laravel IoC container is a powerful tool for managing class dependencies. It is widely used in Laravel and an important tool for your arsenal. The community has created several tutorials for this and here are five resources that will teach you all about it. [...] By reading these tutorials you’ll be up to speed in no time on the Laravel IoC container and also improve your code by implementing it in your application.

As a "bonus" there's also a link to a video narrated by Laravel creator Taylor Otwell himself about the IoC container and its use.

Matthias Noback has a new post today responding to a recent post talking about virtual packages with Composer (using "provide") and some of his own thoughts of how it relates to dependency inversion.

This is a response to Peter Petermann's article Composer and virtual packages. First, let's make this totally clear: I don't want to start an Internet war about this, I'm just pointing out some design issues that may arise from using Composer's provide option in your package's composer.json file. [...] Yes, if a user wants to run the code in your library, they need to have some class that implements [the "provides" requirement]. But no, this shouldn't be reflected in the dependencies of the library. Let me explain this by taking a look at the Dependency inversion principle.

He gives an example of using a specific package for logging (the Zend logger) and how that hard-coded dependency can be refactored out using one of two methods: either a custom interface or one described elsewhere. Getting back to "provide", he lists some reasons why he thinks that defining the interface itself in the Composer configuration is a good idea. These include:

• Strictly speaking (as in, would the code compile), the code from the library itself [...] just needs the LoggerInterface (which happens to be in the psr/log package).
• By depending on an implementation package, you basically undo any effort you made to depend on abstractions and not on concretions.
• Some day, someone may decide to introduce another virtual package, called the-real-psr/log-implementation.
• The notion of an "implementation package" is really vague. What does it mean for a package to be an implementation package.

Each of the reasons has a bit of description to go along with it. He also points out an interesting example where the package actually knows about existing virtual package, the DoctrinePHPCRBundle and its use of "jackalope" and "phpcr".

NetTuts.com has posted the next part in their series (the looking at the SOLID development principles discussing the Dependency Inversion Principle, the final letter in the "SOLID" acronym.

It would be unjust to tell you that any one of the SOLID principles is more important than another. However, probably none of the others have such an immediate and profound effect on your code than the Dependency Inversion Principle, or DIP in short. If you find the other principles hard to grasp or apply, start with this one and apply the rest on code that already respects DIP.

They start off with a basic definition of the dependency inversion principle and an example of it in a more real world situation. They use it to separate out the handling of reading and rendering PDFs and eBooks. It's just some basic code, no real functionality, but it gives you an idea of how to architect the application.

Brandon Savage has a new post to his site that tries to clear up a misconception about the SOLID set of principles for software development. He points out that, despite some comments to the contrary, the "D" doesn't stand for "Dependency Injection".

You’ve probably heard of the acronym SOLID by now, which is an object oriented programming paradigm consisting of five basic (but interrelated principles) of object oriented development. And you’ve probably heard once or twice that the D in SOLID stands for Dependency Injection. Actually, if you’re lucky you’ve also heard what it really stands for, which is the Dependency Inversion Principle. But, in PHP, this is often conflated with dependency injection. I’m here to tell you today that dependency injection is only one piece of the overall puzzle in understanding this crucial principle.

He talks about the actual definition of the "D", dependency inversion, and how it relates to the concept of "dependency on abstractions." He includes some sample code to help make his point - one showing classes with dependencies on one type of object, another showing a dependency on an interface instead.

Freek Lijten has posted the last article in his series looking at the SOLID development principles, this time looking at "D", the Dependency Inversion Principle.

The DIP deals with avoiding mixing different levels of abstraction in your code. In this article we will explore the last of these principles in depth. [...] I want to show you how depending on abstractions makes our lives easier in a larger example. Since we're going to be loading, updating and storing bikes a lot in our application I would like an Api for that. It would not be such a good idea to write the same queries or perform the same validation over and over.

He includes two examples - one a bit simplistic involving bike storage and another more complex that uses interfaces to define structure and object injection rather than passing data around. He also tries to help clear up some of the confusion that might happen around dependency inversion and dependency injection.

Continuing on in their series looking at the SOLID development principles, Alejandro Gervasio picks back up and looks at the "D" in the set - the dependency inversion principle.

While some central concepts in the realm of object-oriented design are generally harder to digest at first, such as separation of concerns and implementation switching, more intuitive and untangled paradigms on the other hand are simpler, like programming to interfaces. Unfortunately, the DIP’s formal definition is surrounded by a double-edged curse/blessing that often makes programmers gloss over it, as in many cases there’s an implicit assumption that the principle is nothing but a fancy expression for the aforementioned “programming to interfaces” commandment.

He talks about how decoupling your code and working against interfaces is only part of the equation. The other half is the actual "inversion" part of the process - the ownership that the high-level modules must have over the abstractions. He illustrates with an example, a storage module that is highly dependent on a Serializer. Using the DIP principle, he turns this around and refactors his storage class to take in an Encoder object as a part of its construction. Complete source for both versions is included.

In a recent post to his blog Devis Lucato introduces the "Inversion of Control" design pattern and shares an implementation he's created as an illustration - a Service Locator called Select.

[In a Service Locator] all the dependencies are provided by a builder, which serves as a registry of dependencies and/or service definitions. The service locator knows how to instantiate each dependency. Such service exposes methods like 'getMailer()', 'getLogger()' etc. A service locator centralises the configuration detailing classes and parameters involved on objects instantiations.

He includes some sample code showing the structure of a Select implementation using a "Mailer" identifier and definitions of the classes to load for it. He also includes a bit of documentation of the (simple) API you can use to work with the tool - setting namespaces, replacing class definitions, creating definitions and finding the resource associated with a definition (to name a few).