News Feed

News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way
Design Patterns The Facade Pattern
October 20, 2014 @ 13:17:46 has continued their series covering common design patterns and their implementation in some example PHP scripts today. In their latest post they focus on the Facade pattern, a member of the "structural" family of patterns.

When it comes to design patterns, you may have questions: Why should we use design patterns in programming? Our code can work just fine without it. [...] Code that employs design patterns is easy to understand, easy to maintain, and easy to extend.[...] In this tutorial, we are going to cover the facade design pattern. It falls under the category of structural patterns because it deals with how your code should be structured to make it easily intelligible and keep it well maintained in the long term.

They start with a UML layout of a typical Facade and include a typical problem/solution where it could be used. They get into a code example that creates a simple checkout process. In this process, they use the Facade pattern to create a more maintainable, extensible ordering workflow.

0 comments voice your opinion now!
designpattern facade introduction tutorial uml series


Mathias Verraes:
Resolving Feature Envy in the Domain
August 12, 2014 @ 11:55:24

Mathias Verraes has a new post today about something he calls "feature envy" in the domain, related to this code smell (based on a definition from Martin Fowler).

Benjamin Eberlei did a really nice job of explaining refactoring the Feature Envy code smell on his blog. I wrote a comment because I felt the example could be taken one step further. You should read the original post. Below are Benjamin's code examples (for reference), followed by a repost of my comment.

The "smell" is defined as "a method that seems more interested in a class other than the one it's in". Mathias includes the code examples from the other post showing a datetime calculation and how it could be abstracted out to another class and method. He talks about the migration and how it relates to the "Whole Value" pattern and integrating some of the logic into a factory, generating a "reporting period" instance. He finishes the post with a brief look at an application of domain-driven design concepts to the problem, suggesting that the reporting be even more abstracted from the datetime data and using the "reporting period" object instead.

0 comments voice your opinion now!
feature envy whole value designpattern class object abstraction domaindriven


SitePoint PHP Blog:
MVC - a Problem or a Solution?
July 28, 2014 @ 11:42:36

The SitePoint PHP blog has a new post by Jeroen Meeus that wonders if MVC is a solution or a problem when it comes to developing web applications.

Repositories, Adapters, MVC with all it cousins, SOLID, RTFM… As a (PHP) developer, those words are thrown at you from every corner of the web. And I hate it, I've had enough. Stop telling me what to do and show me those kittens instead. [...] When solving the web-application problem, we are forced to use MVC. The dev community often frowns upon those who don't use it, but seldom lets those they're frowning upon ask why. [...] MVC doesn't solve the Code complexity problem. It doesn't solve the code reuse or no-flexibility problem either. And it doesn't guarantee decoupled code.

He goes on to talk about how design patterns don't "solve problems". Rather they help us as developers by providing a best practice we can follow to get the job done. He suggests, though, that MVC has become "the new Singleton" but it has been used so much in so many different ways, it's boarding on the point of being abused.

Depending on the situation, and the problem at hand, different patterns can help you write robust, secure and understandable code. Just be careful using them - if you catch yourself using the MVC pattern for a 1-pager, ctrl+a del.
0 comments voice your opinion now!
mvc designpattern problem solution abuse

Exploring PHP Design Patterns
June 23, 2014 @ 10:41:50

For those that might be new to development, the concept of "design patterns" could be one you're just approaching. These common practices define some "patterns" of development that have been proven to provide good structure and maintainability to applications...when applied correctly. has an introductory article showing you how to use five of the most common patterns: Factory, Singleton, Observer, Chain of Command and Strategy.

Design patterns provide a generic reusable solution to common problems. A design pattern is not a concrete solution that can be converted in to source code or a machine code rather it is a template which can be used to solve a problem in different situations. Design patterns help in faster development as the templates are proven and from the developer's point, only implementation is required. Design patterns not only make software development faster but also encapsulate big ideas in a simpler way.

For each of the patterns represented a brief description is included and some sample code is given showing it in use. There's not too much depth in this post, so if you're looking for more "meat" on these patterns, I'd suggest checking out some more advanced articles on

0 comments voice your opinion now!
introduction designpattern factory singleton observer chainofcommand strategy


Matthew Weier O'Phinney:
Better Understanding Controllers Through Basic Patterns
June 10, 2014 @ 09:53:21

In his most recent post Matthew Weier O'Phinney shares his own spin on the Action-Domain-Responder pattern (from Paul Jones): how the controllers in the ARD setup could be explained as facades.

Paul M. Jones has started an interesting discussion rethinking the MVC pattern as applied to the web, which he has dubbed Action-Domain-Responder (ADR). If you haven't given it a read yet, click the link and do that; this page will still be sitting here waiting when you return. I agree with a ton of it - heck, I've contributed to it a fair bit via conversations with Paul. But there's been one thing nagging at me for a bit now, and I was finally able to put it into words recently. Controllers - Actions in ADR - can be explained as facades.

Matthew starts off by defining the Facade design pattern with a quote from the infamous "Gang of Four" book: simply put, a simplified interface to a complex system. He provides a basic example of a facade that wraps some common steps for inserting and logging data with this kind of simplified interface. He applies this to the ADR pattern's controllers, pointing out that it handles a few complex steps "behind the scenes" common to marshaling and managing the request.

For me, thinking of Controllers and Actions as Facades has an additional benefit: it describes rather complex architectural patterns in terms of basic design patterns. I find the more I can reduce the complexity of a definition, the more likely I will understand and use it correctly.
0 comments voice your opinion now!
controller designpattern adr action domain responder facade


Paul Jones:
Refactoring To Action-Domain-Responder
June 06, 2014 @ 10:06:15

Paul Jones has a new post to his site today with a more in-depth look at his proposed "Action-Domain-Responder" design pattern and how to refactor an application, based on some with with the Aura framework, to use it.

The v1 version of the Aura framework includes a controller to handle web assets. The idea for this controller was that an Aura package might have images, scripts, and stylesheets that need to be publicly available, but in development you don't necessarily want to copy them to a public document root every time you change them. [...] That v1 version is a mess. The Controller handles the response-building entirely, and there is no Model separation at all. Let's try refactoring it to an Action-Domain-Responder architecture and clean it up some for a v2 version.

Associated code it just linked to, but he does summarize the steps needed to make the transition: extract the domain logic, move responses to a separate class and rename the controller to an action. He also shows how making this separation makes testing easier and links to examples of tests for each. He finishes the post with two final notes about the refactor. One points out that this method isn't the only way to handle this architecture shift and that the action returns a responder, not a response object.

0 comments voice your opinion now!
action domain responder designpattern architecture refactor


SitePoint PHP Blog:
Repository Design Pattern Demystified
June 02, 2014 @ 09:12:40

The SitePoint PHP blog has a new post today that hopes to "demystify" the Repository design pattern with an overview of its structure and ow your code can put it to use.

What is 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.

He includes an example case where the Repository pattern might be used, to "proxy" requests to multiple types of data sources from many different inventory systems. He includes some pros and cons of using the functionality too, like a positive separation of concerns but a negative additional abstraction layer. The remainder of the post includes a code example basing it on a Laravel framework installation. He creates a simple Repository class and shows how to extend it with a layer specific to one city type.

0 comments voice your opinion now!
repository designpattern introduction tutorial laravel class


Paul Jones:
Action-Domain-Response A Tentative MVC Refinement
May 07, 2014 @ 09:49:36

In his latest post Paul Jones has proposed a "tentative MVC refinement" as the structure behind your application. He suggests something called the action-domain-response pattern, focusing on some of the more common practices in web application development today instead of an ideal.

The term MVC has experienced some semantic diffusion from its original meaning, especially in a web context. Because of this diffusion, the Action-Domain-Response pattern description is intended as a web-specific refinement of the MVC pattern. I think ADR more closely fits what we actually do in web development on a daily basis. [...] We generally route and dispatch not to a controller class per se, but to a particular action method within a controller class. It is also partly revealed by the fact that we commonly think of the template as the View, when in a web context it may be more accurate to say that the HTTP response is the View. As such, I think ADR may represent a better separation of concerns than MVC does in a web context.

He goes through the structure he's worked up, showing the interaction between the parts and compares the flow to a typical MVC-based application. He also mentions a few other MVC pattern alternatives including Data-Context-Interaction and Model-View-ViewModel. He then gets into an actual code-based example using a typical blog application. He compares the directory structure and proposes that instead of one controller per file it becomes one action per file (and one response per file accordingly).

0 comments voice your opinion now!
modelviewcontroller mvc actiondomainresponse adr designpattern application


Paul Jones:
Some Rules For Good Naming
April 30, 2014 @ 09:29:42

Paul Jones has a new post to his site today talking about the importance of naming when it comes to the use of different patterns in development. He also makes some recommendations to help clear up some of the confusion around different names for the same things.

[Thoughts in a] Grumpy Programmer mailing-list essay got me thinking. [...] I completely agree with the emphasis on using a common vocabulary. One issue here is that naming things properly is very, very hard. It is one of the only two hard problems in programming. Are there any rules (even rules-of-thumb) that can we use to make it easier to pick good names for the classes and concepts in our projects?

He reminds readers that code is no place for a "novel context", that is that it's not meant to be instructions for humans, but instructions for computers. He points out that patterns are more about behavior than the name you give them and that picking a name that's "close enough" isn't a good idea. He also recommends that you avoid picking a name for a special context the code might be involved in.

0 comments voice your opinion now!
naming rules opinion designpattern behavior context

Are TableGateways Worth it in Zend Framework 2?
November 27, 2013 @ 11:34:28

On his blog Matthew Setter shares his opinion on TableGateways in Zend Framework v2 and wonders if they're "worth it" (as they're not the easiest thing to implement).

Are TableGateways too hard to implement in Zend Framework 2? Are they too hard to justify the effort? That's what I was asked recently during a Twitter conversation. For me, they're not. For me, they're well worth the effort. So I've written this post to show why they're not, and how they bring great flexibility, when implemented correctly. In [this post] I'll set out why they can be a good solution, as well as why not.

He starts from the origins of PHP scripts, back when they were "a collection of files" and not structured under much of a framework. Complexity added the need for this structure, though, including things like design patterns for common tasks. The TableGateway was one of these. He talks briefly about implementing them in Zend Framework v2 (with some gist examples) and some questions to ask helping you determine if they're "too much" for you app.

0 comments voice your opinion now!
tablegateway designpattern zendframework2 implement difficulty


Community Events

Don't see your event here?
Let us know!

series library list package symfony podcast community opinion voicesoftheelephpant interview install framework laravel language api tips deployment introduction release bugfix

All content copyright, 2014 :: - Powered by the Solar PHP Framework