In accordance with the concepts that I deployed in the beginning, you'll certainly recall that when the composite pattern is implemented, one specific object, or a set of them, expose an identical behavior across a given application. Even though this definition seems apparently complex, it must be admitted that translating it to functional PHP code is in fact much simpler than you might think.

Therefore, I'm going to explain how this pattern works by building an abstract PHP class, which as you'll see in a few moments, will define the generic behavior for all the child objects created from it. Logically, in accordance with the schema established by the composite pattern, one or a group of objects that belong to this class will behave similarly in the context of a PHP application.

Having said that, here is the basic structure corresponding to the aforementioned abstract class:   

// define abstract 'FileInfoReader' class
abstract class FileInfoReader{
   // get file info
   abstract public function getSelectedFileInfo(
$singleFileReader);
   // get number of files
   abstract public function getNumberOfFileReaders();
   // add new file
   abstract public function addFileReader($singleFileReader);
}

As you can see, all that I did above was define a simple abstract PHP class, which exposes some generic methods for retrieving information on a given file, as well as for getting and adding a few file reader objects.

Also, it's worthwhile to mention here that you shouldn't worry for the moment about how these objects will look, since their corresponding definition will be shown in the next section. Now, and returning to the signature of the previous abstract "FileInfoReader" class, you'll see that it presents a special structure. It has to be the model for creating objects that will behave similarly, whether a particular application uses one or a group of them. Sounds really interesting, right?

But the question that comes up here is: how can this be achieved with PHP? Well, to be frank, the process is quite straightforward and will be limited to deriving two subclasses from the previous parent.

In this case, the first child class will define the structure of one file reader, while the second one will set up the signature for multiple file readers, in this way implementing the schema dictated by the composite design pattern.

Want to see how these brand new subclasses will be defined? Okay, go ahead and read the following section.