Here you have it. This is the fourth part of the series “Caching result sets in PHP.” Through the previous article, we went a long way, by developing an extensible result set caching class, which is aimed specifically at reducing one of the most common workloads often associated with database-driven websites: repetitive query execution.

We arranged that, after performing regular SELECT statements, the obtained result set is stored in a simple cache file for faster retrieval. While the logic involved in caching result sets has been utilized for quite a long time, the different approximations for tackling this issue are certainly numerous.

However, when we’re working on large projects, an object-oriented solution probably is best for managing all of the problems that arise, due mainly to the huge size of applications. And definitely, a caching system is yet another piece within the development environment that can be easily addressed through the object-oriented paradigm.

According to this concept, I’ve hopefully demonstrated that a caching class may be created without the need to get too deep into complex programming definitions. Although following the practical approach may lead quickly to developing simple applications, I firmly recommend being armed with the proper theory and then using it to deploy well-structured projects.

It seems that we’re not very close to working directly with a caching class. Well, I don’t think so. If we step back to the previous article, certainly we’ve developed such a class. However, it’s rather conceived as a programming object that interacts with at least two additional objects, and not as a standalone class.

Therefore, we need to complete the scenario, not only showing how the class may be correctly implemented, but how the additional classes interact with each other.

Are you feeling inclined to work with aggregation and composition? All right, let’s get started.