Segregated interfaces aren't anything new in PHP. Simply put,a segregated interface is a regular interface whose contract provides implementers with the functionality to perform one or more specific tasks. In this second part of a series, we will be using them to create a registry system.
Segregating a monolithic interface in a set of more granulated contracts permits us to build classes that stick more efficiently to the “separation of concerns” paradigm, and additionally makes it easy to develop applications that can be easily extended by means of Composition, rather than with Inheritance.
To demonstrate how to utilize segregated interfaces, in the introductory installment of this series I developed a typical array collection class, which utilized three segregated interfaces (namely the native ones Countable, Iterator and ArrayAccess) in order to implement a structure capable of traversing arrays, as well as counting and manipulating their elements.
Segregated interfaces can be used in many scenarios and situations, apart from the one mentioned above. In this second tutorial of the series I’m going to show you how to utilize a pair of custom segregated interface in the construction of a flexible registry system. Thanks to the utilization of these interfaces along with the “Plug-in” pattern, the registry will have the ability to store/fetch/remove elements through plain arrays and via PHP sessions as well.
Taking the first step: creating a couple of segregated interfaces
I’m going to develop a simple –yet functional- dynamic registry, pretty similar to the one that I created here (http://www.devshed.com/c/a/PHP/Building-a-service-Locator-in-PHP/). As stated in the introduction, though, there will be a subtle difference, as client code consuming the registry will be able to swap between an array-based registry and one that uses PHP sessions.
(RegistrableInterface.php)
<?php
interface RegistrableInterface { public function set($key, $value);
public function get($key);
public function clear(); }
If I had to say something about the above “RegistrableInterface” interface, it would be that the contract that it defines is a very narrowed one. After all, it only declares three methods which, when concretely implemented, will allow us to save, retrieve and clear data in a storage/registry system. But why should it be more generous, if this is only the functionality that its implementers will need?
Now, since I want the different registry classes to dump the store data, I’m going to define a separate contract for performing this task. This contract, not surprisingly is established by another segregated interface called “DumpableInterface” (sorry for the name, seriously). Here it is:
(DumpableInterface.php)
<?php
interface DumpableInterface { public function dump(); }
Due to its simplicity, I think that this new interface doesn’t bear any further analysis. It’s worth noting, however, that at this point I managed to create a flexible API, thanks to the existence of a couple of segregated interfaces.
So, with the previous contracts properly defined, the next thing that must be done is to define the classes implementing the pertinent interfaces, which will handle data using different back-ends.
