Putting all of the pieces together: seeing the previous cache classes in action
If you’re anything like me and want to see how to put the earlier caching system to work, below I created a couple of scripts that will hopefully be of help in this case. Here’s the first one, which uses the “ApcCache” backend to cache in RAM some information about a fictional user:
<?php
// example using the ApcCache class
// include the autoloader require_once 'Autoloader.php'; Autoloader::getInstance();
// create an instance of the Cache class $cache = new Cache(new ApcCache);
// save some data in the cache $cache->set('fname', 'Julie') ->set('lname', 'Wilson') ->set('email', 'julie@domain.com');
// get the data from the cache echo ' First Name: ' . $cache->get('fname') . ' Last Name: ' . $cache->get('lname') . ' Email: ' . $cache->get('email');
To keep things shorter and uncluttered, I omitted the definition of the corresponding autoloader; the above script is self-explanatory, so you shouldn’t have a hard time understanding how it works.
Finally, here’s the second script, which caches the data about our friend Julie Wilson, but this time using the “FileCache” class. Check it out:
<?php
// example using the FileCache class
// include the autoloader require_once 'Autoloader.php'; Autoloader::getInstance();
// create an instance of the Cache class $cache = new Cache(new FileCache);
// save some data in the cache $cache->set('fname', 'Julie') ->set('lname', 'Wilson') ->set('email', 'julie@domain.com');
// get the data from the cache echo ' First Name: ' . $cache->get('fname') . ' Last Name: ' . $cache->get('lname') . ' Email: ' . $cache->get('email');
Mission accomplished. Even when this couple of examples are somewhat basic, they come in handy for demonstrating how the usage of a single segregated interface may be an invaluable resource in the development of an extendable caching system.
And speaking of extending things, there’s plenty of room to enhance the functionality of this sample system. So, if you have some time off and want to do something productive with it, go ahead and add to the system a whole new cache backend. All that you’ll have to do is create an implementer of the “CacheableInterface” interface. It’s that simple, indeed.
Final thoughts
Over this third episode of the series, I recreated yet another scenario where the use of segregated interfaces can be of great help in the development of truly “pluggable” systems. In this particular case, I appealed to a single interface to create from scratch a simple caching library, but logically it’s feasible to extend this concept to others fields with the same ease.
Considering that I have already at disposal two cache back-ends ready to be put in action, it’d be really a shame not to reuse them. To prevent this from happening, in the coming tutorial I’m going to develop a customizable user model, which not only will make use of the pertinent back-ends, but it’ll utilize a MySQL abstraction class to access the underlying storage mechanism.
