On PHPMaster.com today there's a new post about using a design pattern in your application, specifically the usefulness of the Adapter pattern. This pattern makes it simpler to work with existing tools by providing a layer that allows unified access to the libraries from one interface.

Software development is improved every day by new concepts, methodologies, and high quality libraries and frameworks. But even with all these improvements, we cannot prevent change in software development. You may think that your system is designed perfectly to cater to all of its requirements, but there will always be a change request that ruins your perfect design. We have to be prepared for all possible changes as developers. The Adapter pattern is a design pattern which is commonly used to manage changes in development. Throughout this article we'll be looking at the usage and benefits of the patterns using real world applications.

He uses an illustration of email access via a mobile device and using it as an "interface" (via a SMS message) to the web to send an email. He then looks at a more practical code-based example, a set of adapters that let you subscribe/unsubscribe from various email services. He shows a wrong way to implement it as well as a good way - using it to work with Twitter to send tweets via a similar interface.

PHPMaster.com has posted the second part of their MVC series, introducing you to the Model/View/Controller design pattern. If you want to catch up, part one is here.

Welcome to part 2 of this two-part series discussing MVC and PHP, where we'll discuss some of the considerations one must make when using an MVC architecture. If you've come straight to this article without reading part 1 first, I encourage you to head back and have careful read as this one will assume that you've read and understand everything it discussed.

He talks about some of the things more involved in making a MVC framework including routing and URL formats and working with templates. Sample code is included for the route handling, model/controller relationship and view classes for the templates.

If you're new to the world of PHP frameworks, there's one acronym that might confuse you if you don't understand the structure - MVC. In this new tutorial on PHPMaster.com today introduces you to the MVC (Model/View/Controller) design pattern and how it's commonly implemented in PHP.

The Model-View-Control (MVC) pattern, originally formulated in the late 1970s, is a software architecture pattern built on the basis of keeping the presentation of data separate from the methods that interact with the data. In theory, a well-developed MVC system should allow a front-end developer and a back-end developer to work on the same system without interfering, sharing, or editing files either party is working on. [...] In this article, I will go the basic principles of MVC, a run through the definition of the pattern and a quick example of MVC in PHP. This is definitely a read for anyone who has never coding with MVC before or those wanting to brush up on previous MVC development skills.

He starts with an introduction of the overall structure of the pattern, how each part talks with the others. He then talks about each piece in a bit more detail and provides some code examples for some very basic MVC classes. There's no routing or anything connected to them like there would be in a framework - it's just the classes taking the others in as parameters.

On his site today Anthony Ferrara has posted the latest video in his "Programming with Anthony" series. This time, it covers the basics of design patterns with guest host Larry Garfield.

Today we are joined by open source contributor Larry Garfield. Larry introduces us to design patterns through his own unique style: Cooking With Crell. He introduces the concept of Design Patterns, goes through a few basic patterns and closes out with some pretty solid justification for why we should care.

You can watch this latest episode either on Anthony's site or over on YouTube. There's several other videos in his series, so be sure to check out the playlist for other great videos.

On PHPMaster.com Patrick Mulvey has written up a new tutorial looking at using the PSR-3 logging structure to make a basic logger for your application.

Logging is one of the most ubiquitous tasks encountered in PHP. We use logs to track error messages, record important events, and debug problems with our code. In any PHP project, the code is likely to be full of calls to a logging library which handles these actions for us. [...] To promote compatibility between logging libraries, the PHP-FIG group recently released PRS-3, a common interface for logger objects. In this article, I'll discuss how the logger interface defined by PSR-3 allows us to write reusable code that isn't dependent on any particular logging implementation.

He includes a quick introduction to the PSR-3 format, how to get the files you'll need to use it (via Composer). He includes some sample code showing how to make the basic email class with a logger injected for use. Since the Monolog logging project follows the PSR-3 format, it's an easy drop-in option. He also talks about using PSR-3 to avoid having logger dependencies with the "LoggerInterface". There's also a bit at the end of the tutorial showing you how to use the Adapter design pattern to "proxy" the logging calls to the class via a PSR-3 interface.

Anthony Ferrara has posted his latest "Programming with Anthony" video episode today pattern is more of a behavioral structure, defining how objects interact with each other.

The Mediator Pattern is an extremely flexible and useful tool to help decouple your code and provide added flexibility in your applications. We'll explore the basic concept of a Mediator, some places you've used it and some things that you can do to improve upon the basic concept.

You can watch the video either in the post or over on YouTube. If you enjoy the episode, you should also consider the rest of the videos in the series, all available from this playlist.

On DZone.com Giorgio Sironi has a new tutorial looking at the Factory design pattern, specifically the use of a "collaborators map" to create them inside of a dependency injection container.

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.

Constantin Bosneaga has a recent post to his site that the CodeIgniter users out there could find helpful. It's an example of using the Layout pattern in a CI app to make a more flexible layout thanks to a library (source included in the post).

CodeIgniter is great framework by its simplicity. But when I moved from CakePHP, I really missed layout pattern. CodeIgniter documentations offers this way to include non-changing site header and footer. For sure it isn't flexible and does not show page structure in a clear way. For many years I use layout pattern. Layout describes whole page as a template with blocks for header, menu, content, etc.

He uses this library to handle the data for your layout, including the header items (like CSS, Javascript) and the definition of a global template. It also allows you to do template inheritance, making it simpler to reuse partial templates ("blocks").

The this recent post to his blog Reese Wilson looks at using one of the modules of the Zend Framework v2, the ServiceManager, as an inversion of control container in your app.

In Zend Framework 1, it was difficult to follow best practices when it came to writing testable code. Sure, you could make testable models, but once you need those models in a controller, what do you do? Zend Framework 2 makes it much easier. In this post, I'll cover the basics of injecting a model into a controller. The main goal here is to be able to wire up and configure your application from the highest level possible. Constructor injection + inversion of control makes it easy to determine which classes are dependent on other classes.

He creates a "Building" module and a "BuildingController" inside of it. This controller takes in an instance of a "Building" model as a dependency. He also shows how to define this dependency in the "getControllerConfig" method of your module to make it work automatically. He makes the "Building" model itself with no dependencies and sets it up as an "invokable" in that same "getControllerConfig" method.

On PHPMaster.com there's a new tutorial posted talking about the Template Method Pattern to help make some sense (and make easier to use) your implementation of the Strategy pattern.

This bring us back to the question whether it's feasible to eliminate duplicated strategy logic via Inheritance rather than switching over to plain Composition. Indeed it is, and the clean up process can be conducted through an ubiquitous pattern known as Template Method. [...] Simply put, there's a base class (usually an abstract one), which declares a concrete method (a.k.a. the template) responsible for outlining the steps or hooks of a certain algorithm. Most of the time the base type provides boilerplate implementation for some of those steps and the remaining ones are delegated to subclasses.

The subtypes then override the base's functionality and extend it with their own. They show an example of this by making a jQuery image slider (using this plugin) , an "AbstractCycleSlider" class and two subclasses for two other types - "FadeSlider" and "ScrollSlider", each outputting their own HTML. It also shows how to implement a slider using a different plugin and output both in the same script.