Login

Introducing Mediator Classes in PHP 5

The mediator design pattern can help you achieve and maintain synchronization between a group of PHP classes. In this first of a two-part series, you’ll be introduced to the mediator pattern, how it functions, and how it can help you with your application development.

Introduction

As you’ll possibly agree with me, at some point in your productive life as PHP developer, you’ve had to build web applications comprised of different, highly independent modules, which naturally perform well-differentiated tasks. Besides, it’s normal to see that these modules very often establish a carefully planned interaction with each other, by means of a centralized mechanism, to stay in synchronization with the rest of the application.

Database interfaces and data validation systems, among other applications, are clear examples of using a unique, centralized programming module to keep all the different components that integrate a PHP application synchronized. You should be quite familiar with this concept.

The previous schema of interaction between the diverse modules of a given application seems to be pretty straightforward to implement during the development period; however, it should be admitted that this model isn’t too easy to apply, particularly when it comes to using a set of predefined PHP classes.

The creation of a specific class, which has to be capable of keeping the interaction of other classes centralized (and synchronized) sounds hard to achieve, at least without using the benefits offered by pattern-based programming. So what’s the point in utilizing this approach, after all?

Well, in this case, the synchronization between a group of PHP classes can be made by implementing a useful pattern widely known as “mediator.” In short, when the mediator pattern is applied, there’s a single class that implements the logic required to keep all the other classes completely synchronized with each other. This means that not only will all the modifications introduced by one class be reflected in the others, but that those changes will be performed via the interface of the mediator class.

Of course, it’s quite possible that you find the above definition rather hard to grasp, therefore in this two-part series, I’m going to show you how a mediator class can be defined, and logically how it can be put to work as well, by employing numerous instructive examples.

So, are you ready to learn more about how to implement this handy design pattern with PHP 5? Okay, let’s get started now!

{mospagebreak title=Creating a simple mediator class}

Since the main objective of this series is to demonstrate how the mediator pattern works, the first thing that I’m going to do is build a mediator class. As you’ll see shortly, this class will be capable of handling the interaction between two file data handling objects in such a way that if one of them changes the case of the data it manipulates, then this modification will be reflected on the other as well, and vice versa.

Now that I have explained how this mediator class is going to work, please pay attention to its corresponding signature, which is shown below:

As you can see, the “FileHandlerMediator” class defined above performs a few interesting tasks which deserve a closer look. First, the mediator accepts two incoming parameters called “$numericData” and “$alphabeticData,” which are inputted directly into the respective constructors that belong to the data file handling objects that I mentioned a few lines above.

In addition, an instance of the mediator is also passed to these objects; the reason for doing this will be clear when you see their corresponding signatures. For the moment, I’d like you to focus your attention on the definition of the “modifyFileData()” method, which obviously is the mediator’s workhorse.

As you saw previously, the aforementioned method first takes up a data file handling object as its unique input parameter, and then checks to see whether the case of the data manipulated by the appropriate handler object has changed. If it has, then this modification is extended to the other data file handler too, in this way demonstrating how a mediator can keep at least two classes completely synchronized. Quite good, right?

All right, now that you have hopefully grasped the programming logic that stands behind the mediator class that you learned a few lines above, it’s time to move forward and show the signatures that correspond to the pair of data file handler objects used by the mediator in question. As you’ll see in a few moments, learning the definition of these new objects is a crucial step to understanding more clearly how the mediator pattern works.

To see how these file data handlers will be created, please click on the link that appears below and keep reading.

{mospagebreak title=Building a pair of data file handling classes}

After showing the pertinent structure of the mediator class that I built in the preceding section, the next step consists of creating the two additional data file classes that you learned previously. As you’ll certainly recall, these classes will be kept completely synchronized by the corresponding mediator, a fact that was demonstrated when I showed you its signature.

And speaking of signatures, here are the ones that correspond to the pair of data file handlers used by the mediator class. Have a look at them, please:

As shown above, after defining an abstract file handler class on top of the corresponding hierarchy, I derived two subclasses from it, to have at our disposal a couple of objects which are capable of handling numeric and alphabetic data respectively.

Of course, despite the nature of the data handled by each of these child classes, you should notice that both of them accept the mediator as part of their incoming parameters, which is also used by the respective “uppercaseFileData()” and “lowercaseFileData()” methods that belong to the classes in question. Quite simple to understand, isn’t it?

At this moment, the programmatic model dictated by the mediator pattern should be pretty clear to you, since in the previous chapter you learned how a mediator object can be capable of maintaining at least two additional classes in perfect synchronization, while in this section you saw how these classes use the mentioned methods as a centralized mechanism for performing all their tasks.

So far, so good. Now that you hopefully grasped how all the previously defined classes work, it’s a good time to leap forward and see how these classes can be integrated into an instructive hands-on example, which will help you understand more accurately how the mediator pattern does its business.

Want to learn how this educational example will be developed? Jump into the upcoming section and keep reading, please.

{mospagebreak title=Building a practical example}

As I stated at the end of the previous section, I want to finish this tutorial by showing you an instructive example where all the classes that were built previously are put to work in conjunction. Doing so, I’m sure that you’ll have a much better idea of how the mediator pattern works.

Now, assuming that there are two sample text files called “data1.txt” and “data2.txt,” where the first one contains only the trivial numeric value 12345, and the second one holds the string “This is alphabetic data,” here’s the sample code that illustrates how any change introduced by one data file handler will also be updated on the other one, via the respective mediator.

As you can see, the example shown above demonstrates clearly the principle that drives the mediator pattern. In all the cases where one file handler changes the case of its data, this modification is also introduced by the other handler via the mediator object. Now do you see how a mediator class can be used to keep a group of classes synchronized? I bet you do!

As usual, feel free to modify the source code of all the classes shown here. In this way you can develop your own hands-on examples, and eventually acquire a more complete understanding of how the mediator pattern works.

Final thoughts

In this first part of the series, I walked you through the basics of implementing the mediator pattern with PHP 5. Nonetheless, this journey has another chapter. In the last article I’m going to expand the original file handler mediator class that you learned here to demonstrate how it can be used to synchronize three classes simultaneously. I don’t think you’ll want to miss it!