Friday, April 3, 2015

Fake Object Oriented (The Doer Anti-Pattern)

Intro


First, I challenge you to find something weird with the designing style below.

Example:


// data classes:

public class CoffeeData {
    public Price price;
    public String brand;
}

// logic classes:
public class CoffeePriceApplier {
    public void applyCoffeePrice(CoffeeData coffee, Price newPrice);
}

public class CoffeeStringConverter {
    public String convertCoffeeToString(CoffeeData coffee);
}

public class CoffeeMiscUtils {
    public Coffee findTheStongestCoffee(CoffeeData[] coffeeItems);
}

I noticed this pattern dominating in several serious software companies already, I googled it and found nothing.
So today I'm happy to introduce you the Doer anti-pattern.
It exists out there, and yet unnamed.

I'm currently considering the following names:
  • The IoC Container Abuse
  • Fake Object Oriented
  • The Doer Anti-Pattern

The Anti-Recipe

  1. Use some IoC container framework. (Windsor Castle, Spring framework, etc...)
  2. Design your code with two kind of classes:
    1. Data classes - only data. no logic except getters and setters.
    2. Doer classes - only logic. no state.
  3. Register all doers in the IoC container as singletons. (because they don't have a state anyway)
  4. Never use the "new" keyword anymore.
    When you need to refer a doer from another doer, get it from the IoC container.

So What's Wrong About It Anyway?


It's not bad. It's just not an Object Oriented design but rather a good old procedural programming in disguise.

In procedural programming (Pascal, C, etc...) you have structs to hold the data, and procedures arranged in modules.

In Object Oriented design, data and methods are mixed together in objects.
The point of this mix is to enable you to build an object model of your world, where each object has a behavior.
The key feature of OOD is modeling.
Let's say it again: you use objects to build a domain model. (Martin Fowler)

Why Does It Happen to the Best of Us?

It's Easier Than Real OOD


Building a domain model isn't an easy task even for an experienced developer.
Writing procedural code, however, is easy: write methods that you need them as you need them, and eventually group them together in files.
In fake OOD, these files are stateless classes.

IoC Containers Trick You


Other reason it happens a lot is that IoC containers are over used and we use them to trick ourselves.
We think that if the doer class is not static, but rather a normal class (but with no state), and we access this class through IoC, then we are doing OOD.
Note that if you register a class with a singleton life style, then in practice, it is static. Dah!

Bad Examples By Legit Design Patterns


There are actually well known design patterns that use the doer pattern, such as:
  • visitor
  • iterator
  • and the worse... command!!!
These patterns are not bad, but they are not part of the domain model but rather tricks that you may use here and there, and yet be considered working OOD.
The command pattern, for instance, is a tool to be used only when you really need to support an "undo" functionality. It has a cost, though. It don't play well with an object model.
Overusing this pattern is always a bad idea.

Avoid by Good Naming


Objects are nouns, not verbs.
Methods are verbs.
So if you take method names, like:
  • MoveBooks
  • LoadItem
  • ClearCache
And force them to be nouns-like by using the "er" or "or" suffix like this:
  • BooksMover
  • ItemLoader
  • CacheClearer
Then you are just fooling yourself.
You should probably have a class named "Book" with method "move" instead.