DevShed: Effects of Wrapping Code in Class Constructs
DevShed has a new tutorial posted today looking to help you counteract the bad practice of wrapping procedural code in "class" constructs and provide some useful suggestions of how to avoid it.
Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.
To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.