Like for every library, you should first evaluate if the costs and benefit of integrating [a dependency injection container] are worth it. The alternative is to write your own factory classes, methods and closures: this article explains one of the patterns for building dynamic Factory objects, and as such lowers the cost of the second option. What you know how to do has a lower cost than what you still have to learn, considering risk and implementation time.

He talks about the "old way" of making your own factories to create objects and how the collaborators mapping can replace that. The collaboration mapping is passed in when the object is created and a "create" method is called when the objects (or sub-objects) are needed. He also mentions some of the "easy" and "hard" changes you could make to this setup to expand its functionality.

From a programmer's perspective, the process of designing easily consumable APIs while still keeping a decent level of decoupling between the involved classes is always a tricky trade-off, as the more expressive the dependencies are, the harder the work is that needs to be done behind the scenes for wiring up the collaborators in their proper sequence.

In this two-part series I'll be doing a quick roundup of some of the most common methodologies that can be employed for managing class dependencies in modern application development, ranging from using service locators and injectable factories, to sinking your teeth into plain vanilla Dependency Injection, and even implementing a naive Dependency Injection Container.

He talks about the "plague of the 'new' operators" and how, through the use of an injected factory object, they could be easily replaced. Code samples are included showing the initial state and the end result, refactored to inject his "SerializerFactoryInterface" into the "FileStorage" class.

If you've read the About This Site page, you'll know that instead of pursuing my passion for computers, I got sidetracked into the arts in college. So when it came time for me to learn and explain the Factory Pattern, I thought it might be fun to express it as an allegory...

His example involves cars, axles and wood to illustrate how the Factory pattern lets you generate objects of different types automatically without having to worry about how they're created. He includes a code example in the form of an interface and a class that implements it (the "Axle" class).

To help better explain each of the three aspects of DI I discussed in the previous article I'll be going over each more thoroughly and with those code examples requested. I'll be going through each point one at a time as the explanations will likely be of some length compared to the original post.

He starts with the "villain" of the story - the Singleton design pattern, a difficult to test method that lulls you into thinking you're not in the global scope. He talks about the problem of using this approach and how the Factory design pattern can be used to create an alternative. He changes up the example to create a "DbTableFactory" class that can be used to create the objects needed - in this case a "UserTable" object with the connection injected into it at construct time.

The Factory Method pattern is a design pattern used to define a runtime interface for creating an object. It's called a factory because it creates various types of objects without necessarily knowing what kind of object it creates or how to create it.

Code is included showing how to make creating "Product_*" classes as simple as calling a "build()" method with the type. A slightly more complex situation is also included - building factories inside of factory methods. For more about the Factory design pattern, check out its Wikipedia page (that includes some common uses and some pitfalls to watch out for).

This is just a short follow up to a recent tweet of mine. I have seen this repeatedly happen, even to top notch and usually very careful developers (*). I am not sure why this mistake happens so frequently, but quite often you see code that changes the parameter order for custom Exception constructors. I guess it's mostly because in these cases the developer wants to pass some magic parameters that contain the message (and potentially also the code).

He recommends that, if you really do need to change something like the order of the parameters, use something like a factory to handle the reorganization for you.

To be clear, I think Design Patterns have their place. When used properly, they can make our lives easier and our code better. When they're misused - "If the only tool you have is a hammer.." - then they can become the bane of our existence. Unfortunately, some Design Patterns seem more susceptible to this than others. So maybe this is less "design patterns I hate" and more of "design patterns that have been abused beyond all sense of reason"... I'll let you decide.

He has three of the most commonly misused design patterns in his list. Anyone who has looked into using patterns in their applications will recognize them:

• Active Record
• Factory
• Singleton

For each, he describes some of the bad implementations he's seen and notes that, while these are commonly abused, they can still be redeemed by being used appropriately.

In this article you will learn how to use the factory pattern design in your PHP application to construct different objects for interrogating a database (books) and displaying the records from a table (bookstore) [...] The essence of the factory method pattern is to "define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses."

He illustrates with a few sample scripts - one that displays a series of messages on factoried instances of a class, another that randomizes a display of images and another that handles book data and outputs the results.

A design pattern is a template used by software engineers as a guideline of how to solve a particular problem. [...] In this series of articles I plan to explore some of the design patterns that i have found most useful in my time as a PHP developer, providing examples and notes. So, this being the first, we'll take a look at the Factory Method Pattern.

He defines the pattern - an interface to a class without the caller having to know what type of class it is - and a code example showing an abstract class with a "Factory" method that pulls information from either a jpeg or png class based on the extension of the file name given.

Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most - if not all - languages, depending on the capabilities of the language.

They introduce a few of the more widely used patterns including the strategy pattern, adapter pattern, factory methods, decorator and singleton patterns. Each comes with a bit of code showing how it would work and a "where would I use this?" section with a better example.