Object-oriented programming is a good thing, but it’s important not to get carried away. Some programmers believe more classes == more abstraction, and say things like “better wrap that in a class so it’s more abstract”. That’s a sure tip-off that someone’s been drinking too much OO Kool-Aid.

The concept of abstraction – building higher-level components out of lower-level ones – is the most important thing in programming. But lately I’ve been running across code like this:

public class ProductHelper {

    private Product _product = null;

    public ProductHelper () {
        _product = null;
    }

    public ProductHelper (Product product) {
        _product = product;
    }

    public void setProduct (Product product) {
        _product = product;
    }

    public Product getProduct () {
        return _product;
    }
}

That’s not really abstraction, since ProductHelper is at the same abstraction level as the underlying Product class. It’s like building a kitchen table out of, well, another kitchen table.

It’s also not encapsulation. If all the instance variables in a class have getters and setters, you’re not really “hiding” anything.

Some programmers argue that it’s good to create Helper or Wrapper classes when you need to access classes not under your control – for example if the underlying classes are generated Web Service stubs. But that argument is misguided. Unless the Helper or Wrapper classes are truly at a higher level of abstraction (i.e. provide a simpler interface to the underlying functionality), any changes to the underlying classes will still require you to update the client code, plus you’ll have to update the Helper classes as well.

A good tipoff that a piece of code has too many non-abstract abstractions is when many of the classes (or namespaces) are called things like “Helper”, “Wrapper”, “Manager”, “Engine”, or other names that don’t really correspond to domain objects. That’s when it’s time to dump the Kool-Aid and start simplifying the class hierarchy.