On his site Brendt has shared some of his thoughts about why he sees the service locator design pattern as an anti-pattern and harmful to your overall application.

As a Laravel developer, I'm confronted daily with the service locator pattern. Every facade call and several helper functions are built upon it.

[...] During a discussion with my colleagues, I found it difficult to put into words what exactly is wrong with grabbing things out of the container - a service locator - so I decided to write my thoughts down, with an example. [...] I want to highlight three problems with this approach, directly caused by the use of a service locator.

He goes through a list of where he sees the use of the service locator functionality causing problems including:

• getting runtime instead of compile-time errors
• obfuscation of actual functionality
• increased cognitive load

He ends the post with a quick suggestion on how to solve the issue: use actual dependency injection instead of "magic" locators.

On the /r/php subreddit frm Reddit.com, phpdevster proposes an interesting opinion - that an event system, set up with a listener and defined events, has become more of an anti-pattern in its most common implementation.

If events are only meant to be additional functionality that ALWAYS ALWAY ALWAYS should happen after a primary action is taken, how often is code really that absolute? Why are events not implemented in more flexible ways by frameworks? - that is implementing some inversion of control which would allow callers to determine which listeners would be relevant to the given context.

He illustrates his point with an example user registration system that fires a "user-was-registered" event that, in turn, fires off a series of events via a listener. He points out a pretty large flaw, though. While the functionality involved in the event is decoupled (the event itself), the behaviors defined by that event are not. Comments on the post offer some different options and solutions to the same problem including:

• Further decoupling of the eventing process
• Using objects with settable properties rather than just event name strings
• The idea of using an "event store" to handle decoupling rather than more immediate code-based solutions

Have some thoughts of your own on events and decoupling? Go over and share them too.

In a new post to his site David Lundgren wonders when dependency injection becomes an anti-pattern when used in PHP applications. The idea of dependency injection is to provide objects with instances of other objects representing things they'll need to get the job done (goes along with separation of concerns). Unfortunately, if used incorrectly, DICs - dependency injection containers - can become less useful and more of a hinderance than a positive part of the application.

During my tenure as a seasoned, and tenderized, PHP developer I have used many design patterns: adapters, factories, data mappers, facades, etc. The most recent one that I have been working with is Dependency Injection. Inversion of Control is not a new idea, at least not in the programming world, but in the PHP world it seems to have taken us by storm in recent years. Every framework will often have a Dependency Injector built in, or offer it as a component for use. It is the hip thing to do in PHP, but I believe we need to take a step back and evaluate it for what we are really trying to achieve. That is reducing the tight coupling that our objects may have. I view it as removing the new-able’s from our objects code, and handing the object creation over to something else to deal with.

He talks about how dependency injection containers and service locators relate to each other. He also suggests that, at the heart of every dependency injection container, there's a service locator. He gives an example of a project where a large number of dependencies are being injected and how, despite the assumption of flexibility, his dependencies don't change that often, making the DIC and its functionality a bit less important.

Allan MacGregor has posted his latest in his look at design patterns in PHP with this most recent post about the Singleton pattern.

The singleton pattern is used to restrict the instantiation of a class to a single object, which can be useful when only one object is required across the system. Singletons are designed to ensure there is a single (hence the name singleton) class instance and that is global point of access for it, along with this single instance we have global access and lazy initialization.

He provides a basic Singleton implementation in PHP, a "User" class that always returns the same instance of itself no matter how many times the "singleton" method is called. He continues on and touches on one of the pain points around singleton use - many developers consider them an anti-pattern because their results can make it difficult to correctly test. He talks about how they break the Single Responsibility Principle (part of SOLID) and how they can hide dependency injection.

Singletons, Anti-patterns, and patterns in general are not good or bad; what makes a Singleton an Anti-pattern is not the pattern itself but how often is poorly implemented and how easy it is to do so.

In this new post from Lars Strojny, there's a discussion of an "antipattern" - using the constructor for more than it was intended, the "verbose constructor".

Constructors are often used to shortcut dependency injection and parameter passing on instantiation. This is a valid practice and often leads to shorter code. [...] Instead of creating a new instance of "Money" and calling three setter, everything can be done compactly in the constructor. [...] So for the money object this works pretty well. The code is easy to read, but wait, the first argument can be grasped easily, the second too, but the third? It is not too obvious that it is a divisor is passed.

He compares three different ways to get the data into the class - the already-mentioned parameters in the constructor, passing an array into the constructor and using full getters/setters to push the data into the right places (with fluent interfaces even!).

If you've been programming for any length of time, you know the "joy" of working with someone else's code. When taking over a project, the first inclination I've seen with most programmers is to go in and format everything to what they'd like (or duplicate functionality). This is where the problem comes in, the trend that Michael Kimsal talks about in his new blog post - something he wonders about being an "antipattern".

I was discussing things with my brother the other day and I came up with a problem which he helped name. I'm currently maintaining some code, and it's quite a jumble. One of the things I can tell is that one of my predecessors began adding new sections of code to clean up the logic in other areas of the code. However, what never happened was the clean up of the old code, so now there's two places where the same set of data is retrieved in different ways.

He proposes the name "Multi Master Data" for the situation - two different sources, living in the same code, doing the same thing. Of course, he also mentions a situation where this type of problem can cause real issues, especially when trying to track down a bug (a bang your head on the desk moment).

If you've been programming for any length of time, you know the "joy" of working with someone else's code. When taking over a project, the first inclination I've seen with most programmers is to go in and format everything to what they'd like (or duplicate functionality). This is where the problem comes in, the trend that Michael Kimsal talks about in his new blog post - something he wonders about being an "antipattern".

I was discussing things with my brother the other day and I came up with a problem which he helped name. I'm currently maintaining some code, and it's quite a jumble. One of the things I can tell is that one of my predecessors began adding new sections of code to clean up the logic in other areas of the code. However, what never happened was the clean up of the old code, so now there's two places where the same set of data is retrieved in different ways.

He proposes the name "Multi Master Data" for the situation - two different sources, living in the same code, doing the same thing. Of course, he also mentions a situation where this type of problem can cause real issues, especially when trying to track down a bug (a bang your head on the desk moment).