Bertrand Mansion [2013-05-13 19:47 UTC]Hi,
I only looked quickly at the code.
I think that there is room for improvements. The 'one class does it all' concept is bad here because it reduces your code reusability, extendability, flexibility and creates maintenance problems. It makes it painful to add a new backend (redis, apcu, tokyotyrant, mongodb, ...) or modify an existing one.
You could improve it by looking at the current Cache_Lite or Cache packages, and investigating design patterns like Bridge and maybe Chain of responsability in case you want to keep the possibility to have multiple backends.
You could allow backends to register themselves as available upon loading. You seem to have defined your own order of priority for backends, this should maybe left as a parameter for the user.
You use static functions for set/get. This is also wrong because it doesn't allow to have more than one cache. You should provide a factory method instead, maybe a singleton method if necessary. See the Log package, it is a good example of an API you could use.
In conclusion, your code probably works fine, but it is poor design.
Michael Gauthier [2013-05-13 21:06 UTC]After looking at the code, I agree with Bertand. This class is doing too much. For example, emailing error messages does not belong in a cache library.
There is definitely room in PEAR for a cache library, but the code needs to be split into multiple reusable classes rather than one monolithic static class.
Serializing cache data is potentially a security issue as a vulnerability in any backend now has the potential to execute code on the server.
Khoa Bui [2013-05-13 21:12 UTC]hi guys, I'm Khoa.
I agree with Bertrand Massion too, my code need improve design.
I just created new plan for next version.
I just looked at other classes, and I see I have to learn more from them on patterns design.
Right now, my code is work good, but it is painful to add a new backend or modify an existing one.
Thanks for all advises,
I will propose my next version on couple months soon.