3

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.

4

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.

7
  • If you are suggesting this design: i.imagebanana.com/img/apv4v2m7/Selection_001.png then this is a Factory Method Design Pattern not an Abstract Factory Design Pattern EVEN if it has an abstract factory class.
    – johnlemon
    Oct 6 '13 at 17:21
  • 1
    @danip: Nope. I never got hung up on official terms and labels and it's been a while since I opened GoF, but now I did pull it out. Factory method pattern defines a method that is responsible for creation of an object. This gives deriving class on option of providing its own implementation to return a different instance type. "method" is the keyword, it would typically sit as part of interface of a class that does more than just object creation. Abstract factory is more than just a method, it defines class hierarchy whose ONLY responsibility is to create/return instances.
    – DXM
    Oct 7 '13 at 0:42
  • ... and apparently, GoF doesn't even have a "Concrete Factory" (or "Simple Factory") pattern
    – DXM
    Oct 7 '13 at 0:43
  • Good catch on the Simple Factory. I understand people don't care to much about terminology but I often wonder what do people think when they say: oh, I used an Abstract Factory. Did you for example think at the Design Pattern or just at the abstract class? My problem with saying I used an Abstract Factory Pattern is that usually this pattern creates MULTIPLE related objects not just ONE. "An abstract factory provides an interface for creating families of related objects without specifying their concrete classes"
    – johnlemon
    Oct 7 '13 at 3:57
  • @danip: I have a feeling that you are reading into GoF as something of a gospel and an absolute truth (you just quoted their introducing intent paragraph as the only purpose/use of an abstract factory). My take: Abstract factory is an abstract class (i.e. an interface), which allows concrete factory class implementation to be swapped out. But just because you don't actually swap it out or don't have more than ONE family of related objects, doesn't make it any less of an abstract class that implements a factory (i.e. only job=make objects) interface. Take away the idea, not the exact phrasing
    – DXM
    Oct 7 '13 at 4:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.