The Adapter Pattern
TutsPlus has a great primer on the Adapter Pattern:
This particular pattern can be used when your code is dependent on some external API, or any other class that is prone to change frequently. This pattern falls under the category of “structural patterns” because it teaches us how our code and our classes should be structured in order to manage and/or extend them easily.
Basically, you’re wrapping the functionality of something else, so that if it changes, you just have to change your Adapter class, and all of your code that relies on it is automatically updated with it!
Read more at TutsPlus
MVC – a Problem or a Solution?
A great debate was started on Sitepoint regarding the MVC design pattern. Is it over-used and overkill for smaller projects?
But MVC is heavily abused, and here is why:
Somewhere down the road, someone decided that this was the best approach for everything written in PHP and accessible with a browser. Then came along the rule that a Model should have a 1-on-1 relation to a row in a database, Controllers should be thin and views have to be written in a templating language that compiles to PHP.
Personally, I say go with what you know. If the fastest way to create a simple site is to install a full-stack framework, that’s fine!
Continue the debate at Sitepoint
Understanding the Command Design Pattern
Sitepoint has a quick article about the Command design pattern:
The Command Pattern (also sometimes called the Action Pattern or Transaction Pattern) is a design pattern that describes how to encapsulate a request as an object so that you can queue or log clients with different requests. To demonstrate how the Command Pattern works, let’s use the simple example of a message queue.
Continue reading at Sitepoint
Better Understanding Controllers Through Basic Patterns
Matthew Weier O’Phinney has a nice post about the Action-Domain-Responder (ADR) pattern, which is an alternative/extension of the MVC pattern, and how controllers can be understood in terms of the Facade pattern:
I think characterizing Controllers and Actions as Facades has some huge benefits. In both PHP and Rails, we’ve witnessed the problems that arise from so-called “Fat Controllers” — controllers that do a ton of work, making them untestable, unreadable, non-reusable nightmares. If we think of them as Facades, specifically for the three items noted above, we focus on the specific purpose they fulfill within the system…
Read the full article at Matthew’s blog
Action-Domain-Responder and the “Domain Payload” Pattern
Paul M. Jones has written a piece about the Domain Payload pattern, used in conjunction with the Action-Domain-Responder pattern:
In Action-Domain-Responder the Action passes input to the Domain layer, which then returns some data for the Action to pass to the Responder. In simple scenarios, it might be enough for the Responder to inspect the data to determine how it should present that data. In more complex scenarios, though, it would make more sense for the Domain to pass back the data in a way that indicates the status of the data. Instead of the Responder inspecting the Domain results, the Domain should tell us what kind of results they are.
Continue reading at Paul’s blog
What is the Repository Design Pattern?
Over at Sitepoint, Amit Gupta has a great article introducing the Repository design pattern:
To put it simply, it is an implementation of a brokering layer between the application and a data source. Neither party needs to be be aware of the other to perform their respective jobs which allows us to have a decoupled architecture which in turn helps in the scaling of the application in the big leagues without having hard dependencies.
Continue reading over at SitePoint