Should Uncle Bob's example be refactored to an AbstractFactory or a SimpleFactory?

Question

In the book "Clean Code" Robert Martin makes a statement regarding the following code:

public Money calculatePay(Employee e) throws InvalidEmployeeType {   switch (e.type) {
    case COMMISSIONED:
      return calculateCommissionedPay(e);
    case HOURLY:
      return calculateHourlyPay(e);
    case SALARIED:
      return calculateSalariedPay(e);
    default:
      throw new InvalidEmployeeType(e.type);   } }

Statement: The solution to this problem (see Listing 3-5) is to bury the switch statement in the basement of an ABSTRACT FACTORY,9 and never let anyone see it.

What I don't understand is why does he call it an Abstract Factory? If the solution is to create 3 Employee subclasses each implementing it's own CalculatePay method then the logic is moved up to let's say the controller. But then we have to create a "Simple Factory (Idiom)" not an Abstract Factory as presented in the original book from the GOF.

The Abstract Factory has the intent to: "Provide an interface for creating families of related or dependent objects without specifying their concrete classes." but this is clearly not the case.

Answer 1

In that specific example, he could have used a Simple Factory to get the point about the switch statement across.

But one of his other points is that you should be looking for ways to minimize dependencies. If you have client code that uses the factory to create employee objects and that code refers to a concrete (i.e. simple) factory class, that would be a much tighter coupling than if you refer to an EmployeeFactory interface. This way if for whatever reason, later down the road you decide current implementation of EmployeeFactoryImpl isn't good enough for you, you will be able to simply define a new factory class implementation that implements the same EmployeeFactory interface.

Because you are already using abstract factory, all the code that stores and passes around EmployeeFactory interface will not need to be touched, which is going back to OCP principle, write code as much as possible so that it is closed to constant modifications, because every time you modify something, there's a risk that you will break it.

So the only thing that Uncle Bob didn't illustrate in that example is that you could have created "class EmployeeFactoryImpl2 implements EmployeeFactory" with a completely different implementation of the body of makeEmployee() method and that would complete GoF's example, but it would add more moving parts to the example that is intended to illustrate something completely different.

The other take away from Clean Code (which IMO is an awesome book, so keep reading it), is that patterns is something to keep in the back of your mind, not something to introduce left and right just because you read GoF. So more importantly what Uncle Bob is illustrating, and that's a perfect example, is that you can make small, incremental refactorings to the code to make it easier to read and maintain and while you are doing it, keep the patterns in the back of your mind because there's no sense of reinventing what's already been done.

In this case he went straight to abstract factory because the difference was typing "public class EmployeeFactory" (simple) vs. "public class EmployeeFactoryImpl implements EmployeeFactory" (abstract). Abstract factory gives you much better position for the future and YANGI isn't a good argument here because this better positioning only cost you a handful of keystrokes without any extra complexity.