Here they come the new Adapter Classes
During the week-end I’ve tried to build better adapter classes than the ones I’ve built before. Simply put the ones I had implemented, the ones actually on the GitHub repository, do too many things.
The Globals class wraps superglobals in convenient functions while the Functions class wraps functions defined in the global space, like the one WordPress adds, in class methods.
Since Adapter Classes were built with test-ability in mind it only made sense to implement, in those classes, methods that made testing easier.
It made sense two weeks ago at least.
One thing well
The above motto is hence broken. The simple gotcha that moved me into refactoring a simple plugin that worked, and that is the base for 6 more I wrote for clients, is the failed attempt to describe the class responsibilities in a single sentence
The Functions adapter class wraps functions defined in the global space into class methods and allows the class to put up a façade for testing purposes.
This class, and the Globals one as well, is too smart for me.
Decorators
So I broke the Functions class into two smaller classes and one interface:
The Functions adapter class wraps functions defined in the global space into class methods.
The Decorator interface defines methods a class should implement to be able to decorate a class with a façade for testing purposes.
The FunctionsDecorator class implements the Decorator interface to decorate the Functions class.
I’ve used an interface here in place of a common parent class, I will need a GlobalsDecorator class too, because the method implementations used to decorate the classes vary so much that the lowest common implementation would be just declare them.