Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

StarTutorial.com:
Understanding Design Patterns - Template Method
May 15, 2018 @ 13:07:06

The StarTutorial.com site has continued their series covering common design patterns and their implementation in PHP. In their latest article they cover the Template Method pattern.

[This pattern] defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

In their example, they have two workers that have different schedules but with one difference. Instead of having implementations that differ widely between the two workers (represented by classes) they refactor the main class and allow for a doWork method to be defined in the child. This makes the parent class a sort of "template" for handling the processing with the child filling in the blanks.

tagged: designpattern tutorial template method series

Link: https://www.startutorial.com/articles/view/understanding-design-patterns-template-method

StarTutorial.com:
Understanding Design Patterns - Singleton
Apr 06, 2018 @ 11:28:50

The StarTutorial.com site has continued their introductory look at design patterns and using them in PHP with a new article covering the Singleton pattern.

[The Singleton pattern] ensures a class has only one instance, and provides a global point of access of it.

They use a more real-world example to illustrate the use of a singleton: organizing patients at a doctor's office using a ticketing system. In their example, the system makes use of a "TickerPrinter" object to represent the ticketing system. The issue is that the printer has to check every time to see if it needs more paper or if the ink is out in the first example. They refactor this to use a singleton, creating a getInstance method to return the same instance of a "TicketPrinter" object each time it's called rather than having to create a new one and manage it individually.

tagged: designpattern singleton introduction tutorial ticket printer

Link: https://www.startutorial.com/articles/view/understanding-design-patterns-singleton

StarTutorial.com:
Understanding Design Patterns - Abstract Factory
Mar 19, 2018 @ 13:42:01

The StarTutorial.com site has posted the next in their "Understanding Design Patterns" series of tutorials today. In this latest post they cover the Factory design pattern.

[The Factory design pattern provides] an interface for creating families of related or dependent objects without specifying their concrete classes.

They use the same fictional business as in the previous articles to put the pattern in a more "real world" situation. The goal is to create several "toy factories" that can build "toy" objects based on certain requirements: either cars or helicopters. The post starts with the creation of an abstract factory class and shows the concrete implementations of one for each type of toy. These concrete classes include basic properties about the toy and functionality to build out the basics (ex: a car has four wheels, a helicopter has rotors).

tagged: designpattern factory abstractfactory tutorial introduction toy

Link: https://www.startutorial.com/articles/view/understanding-design-patterns-abstract-factory

Script-Tutorials.com:
Design Patterns in PHP
Mar 06, 2018 @ 11:18:33

On the Script-Tutorials.com site they've posted a lengthy tutorial that covers many common design patterns - 23 of them - and how they could be implemented in PHP.

Today we are going to talk about design patterns in web development, more precisely – in PHP. Experienced developers are probably familiar with this, but this article will be extremely useful for all novice developers. So, what is it – design patterns? Design Patterns aren’t analysis patterns, they are not descriptions of common structures like linked lists, nor are they particular application or framework designs. In fact, design patterns are “descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.” In other words, Design patterns provide a generic reusable solution to the programming problems that we encounter every day.

[...] Design patterns not only make software development faster, but also encapsulate big ideas in a simpler way. Also, be careful not to use them in wrong places in order to avoid unpleasant situations. In addition to the theory, we also give you the most abstract and simple examples of design patterns.

The tutorial starts with a table listing out the category (purpose) of the pattern, the design pattern name and some of the aspects of it that could vary depending on interpretation. The article then goes through each of the 23 patterns and includes the code to implement them. There's not much in the way of description about each but there are one or two sentences about its primary use.

tagged: designpattern implementation example code tutorial

Link: https://www.script-tutorials.com/design-patterns-in-php/

StarTutorial.com:
Understanding Design Patterns - Simple Factory
Feb 19, 2018 @ 12:38:43

On the StarTutorial.com site, they've posted the latest in their article series covering design patterns and their implementation in PHP. In this latest tutorial they cover the simple factory pattern. To help illustrate the point of the pattern they use an example of a toy company with an ever-expanding line of toys.

Dragon Inc. is one of the top toy manufacturers in China. In fact, they're a pioneer in toy manufacturing. They started production at a time when few toys were being produced commercially. Hence, they dominated the market and became the leader in the toy production industry.

The initial version of their produceToy method only had to worry about toy cars and helicopters. As their line expanded, it needed to be updated for "jumping frogs" too. Adding each new toy to the single function would be difficult to maintain but the simple factory pattern came to the rescue. It allowed for the abstraction of the toy object creation out to other handling and other objects, breaking the functionality up in accordance with the Single Responsibility Principle.

tagged: tutorial designpattern simple factory series toy

Link: https://www.startutorial.com/articles/view/understanding-design-patterns-simple-factory

Ross Tuck:
Returning From Command Buses
Jan 22, 2018 @ 09:29:57

On his site Ross Tuck has a post that covers a common design pattern, the Command Bus, how it relates to CQRS and that they shouldn't return anything. In the post he takes some of the most common questions about using a command bus and tries to clarify with the correct answer.

The most common question I get about my command bus library is: “can commands really return nothing?” The second most common question is “Why do you let commands return something, don’t you know that’s Wrong(tm)?”

It’s easy to get hung up on form, not function. That’s a shame because command buses aren’t important. In the grand scheme of things, they’re completely, utterly, totally unimportant. It’s all about where the messages are going, not how they get there.

Still, let’s take a look at some myths about command buses.

The questions he tackles include topics like the relationship between CQRS and command buses, if you should be using them together (dependencies) and some discussion about return values and the "right" way to do things.

tagged: commandbus designpattern cqrs combination myth

Link: http://rosstuck.com/returning-from-command-buses

Asmir Mustafic:
Modular Application Architecture - Considerations
Jan 08, 2018 @ 12:54:36

Asmir Mustafic has continued his series looking at building modular applications with part five looking specifically at some of the considerations and ideas to keep in mind when developing your modular applications.

This is the fifth post from a series of posts that will describe strategies to build modular and extensible applications. In this post we will take a general overview on how some popular design patterns and things to keep in mind when creating plugin based applications.

[...] Anthony Ferrara (alias ircmaxell), in this post blogged about the use of software patterns to implement plugin-based architectures. It is a great article and I suggest everybody to read it. As it is clear from the article, each of this software patterns has a specific use case and the choice of which one to use depends on which the of integration we want allow for the future plugins.

The article starts with a brief recap of some of the more common design patterns including the Observer, Strategy, Decorator and Chain of Responsibility. It then covers some quick uses of these patterns and shares two tips when developing a plugin system for the application and links to good examples for reference.

tagged: modular application architecture series part5 consideration designpattern plugin

Link: https://www.goetas.com/blog/modular-application-architecture-considerations/

Paul Jones:
Solving The “Widget Problem” In ADR
Jan 03, 2018 @ 12:54:43

Paul Jones has a post to his site covering a method he's worked up to solve the "widget" problem in ADR, the Action-Domain-Responder design pattern he worked on defining.

The “widget problem” is when you have several panels or content areas on an HTML page that have different data sources. You might have a main content area, then a calendar off to the side, with perhaps a list of recent news items or blog posts, a todo or reminder widget, and maybe other information panels. The problem is that they each have different data sources, and may not always be displayed in every circumstance — perhaps they are only shown to some users based on their preferences, or under certain conditions.

So how, in Action-Domain-Responder, do we get the “right” data for the set of widgets that are actually going to be displayed?

His answer is pretty simple, basically that the requests are handled the same as everything else but with more kinds of data contained in the "domain" of the response. He walks through a code example of a site that would pull out the set of widgets to show and inject them into the "payload" for passing back to the responder for output handling.

tagged: widget actiondomainresponder designpattern problem domain tutorial

Link: http://paul-m-jones.com/archives/6760

Loïc Faugeron:
PragmatiClean - Command Bus
Sep 20, 2017 @ 09:41:57

Continuing on from the first part of the series Loïc Faugeron has posted the next tutorial in the "PragmatiClean" series covering the use of the Command Bus pattern in your application.

The Command Bus pattern relies on 3 types of classes:

The first one is the Command [...] next is the Command Handler [and] finally there's a Command Bus interface allowing us to build Middlewares.

For each of these parts of the design pattern he covers what the part is and how it fits into the overall structure the pattern defines. He also looks at how it allows for easier adherence to the ideas of both "clean" and "pragmatic" code. The post ends with an example of implementing the Command Bus pattern in a Symfony-based application, building out each part and their integration.

tagged: pragmaticlean commandbus designpattern tutorial series part2

Link: https://gnugat.github.io/2017/09/20/pragmaticlean-command-bus.html

Paul Jones:
Slim and Action-Domain-Responder
Aug 23, 2017 @ 11:04:19

In a post to his site Paul Jones shows how an implementation of his proposed Action-Domain-Responder pattern might look when implemented with Slim, a popular PHP microframework.

I’ve had a warm place in my heart for Slim for a long time, and especially so since recognizing the Action-Domain-Responder pattern. In this post, I’ll show how to refactor the Slim tutorial application to ADR.

One nice thing about Slim (and most other HTTP user interface frameworks) is that they are already “action” oriented. That is, their routers do not presume a controller class with many action methods. Instead, they presume an action closure or a single-action invokable class. So the Action part of Action-Domain-Responder already exists for Slim. All that is needed is to pull extraneous bits out of the Actions, to more clearly separate their behaviors from Domain and the Responder behaviors.

He then works through each piece of the example application, first extracting out the Domain logic then building a Responder to handle the user interface functionality. He combines them to replace the current functionality, pointing out that the responder can now be tested separately from the user interface (templating system).

Now, for a simple case like this, using ADR (or even webbishy MVC) might seem like overkill. But simple cases become complex quickly, and this simple case shows how the ADR separation-of-concerns can be applied as a Slim-based application increases in complexity.
tagged: slim microframework actiondomainresponder designpattern adr tutorial refactor

Link: http://paul-m-jones.com/archives/6639