Freek Lijten has a new post to his site today today talking about a concept of good OOP design, separation of concerns, and how the use of events can help make it "even better". In it he converts some code from a decently structure state into something even driven, splitting out the work from the handling code.

At PHP Benelux 2015 I witnessed a talk by Matias Noback about events. It was a great talk so if you have chance to see it yourself somewhere, do so! In a very tiny nutshell he took us from what most would consider already decent code to better code. Lets start with "decent".

His "decent" code handles user management, executing certain business rules once the user is successfully registered. In the first version of is code, the User is passed into the "saveUser" function and several actions are performed (is the username in use? can they be saved?) including the sending of the email as requested once a user registers. This code is primarily procedural, all in one place and Freek updates it using events to make it a bit more well-contained. He extracts the piece sending the email and translates that into an event. This is then pushed into a set of handlers and executed allowing for greater flexibility if additional actions are needed in the future.

In his new post Mathias Verraes talks about the separation of concerns that, in his opinion, should exist between form, command and model and the validation of each.

Many of the frameworks I’ve worked with, promise to separate responsibilities with MVC. In practice, the end up coupling everything to everything. The forms are coupled to the models, and there’s a grand unified validation layer. This may be convenient at first, but it breaks down for larger systems, and creates headaches when having to support multiple clients. My approach is to clearly separate the validation for the form itself, from the Command validation and the model validation.

He talks about each of the different types in turn, starting with Commands. He suggests that the validation should happen in Value Objects in the Commands, validation rules in Models and some client-side validation (backed up by backend checking, of course) via Javascript or HTML5 fields.

The NetTuts.com site has posted part nine in their series sharing helpful hints and methods for refactoring legacy code. In this new post they continue on with their example application and look at where methods should be moved to/created and mocking in their tests.

In this tutorial, we will continue to focus on our business logic. We will evaluate if RunnerFunctions.php belongs to a class and if so, to which class? We will think about concerns and where methods belong. Finally, we will learn a little bit more about the concept of mocking.

They show how to move some of the "Runner" functions from procedural to OOP, integrating them with some of the classes and methods that already exist. Tests are also included showing how it all links together. From there they get into concerns about the placement of functionality and how that relates to the work at hand. They also use Mockery to mock out some of the needed objects in their tests for the new structure.

In a new post to the Zend Developer Zone, Brett Zamir has posted a new tutorial that talks about using the Smarty templating system to create what he calls the HYSOCAMTT templating approach ("Have-Your-Separation-Of-Concerns-And-Mix-Them-Too".

This article aims to highlight a approach which allows one to separate everything from one's business logic to one's design logic, to XHTML from CSS, one's Javascript from the page structure, etc., while at the same time being able to be lazy and include, for example, CSS information within the same document (template) as one's XHTML

The tutorial uses an extension for Smarty called SmartyDocB that makes the documentation side much easier. He works through the templating process and includes some of the code for the .tpl files to get you started.

He also includes some future goals for his idea, a mention of XSL templating, XQuery and the potential for templating across programming languages to make your site even more flexible.