Question

Background:

I found this article on JavaWorld, where Allen Holub explains an alternative to Getters/Setters that maintains the principle that the implementation of an object should be hidden (his example code can also be found below).

It is explained that the classes Name/EmployeeId/Money should have a constructor taking a single string – the reasoning is that if you type it as an int, and later need to change it to a long, you will have to modify all the uses of the class, and with this pattern you don’t have to.

Question 1:

I was wondering: doesn’t this simply move the problem to the parsing of the String parameters being tossed about? For example, if all the code using the EmployeeId (received from the Exporter) parses the String into an int, and suddenly you start exporting long values, you need to modify exactly as many uses… and if you start out parsing it as a long it might well have to change to a double (even though that makes no sense for id’s)… and if you can’t be sure what to parse the String into, you can’t implement anything.

Question 2:

Besides this question, I have another: I realise that the article is over seven years old, so could anyone point me to some recent overviews concerning OO-design, and specifically to ideas concerning the getter/setter and implementation hiding debate?

Listing 1. Employee: The Builder Context

---

  public class Employee
  {   private Name        name;
      private EmployeeId  id;
      private Money       salary;

      public interface Exporter
      {   void addName    ( String name   );
          void addID      ( String id     );
          void addSalary  ( String salary );
      }

      public interface Importer
      {   String provideName();
          String provideID();
          String provideSalary();
          void   open();
          void   close();
      }

      public Employee( Importer builder )
      {   builder.open();
          this.name   = new Name      ( builder.provideName()     );
          this.id     = new EmployeeId( builder.provideID()       );
          this.salary = new Money     ( builder.provideSalary(),
                                    new Locale("en", "US") );
          builder.close();
      }

      public void export( Exporter builder )
      {   builder.addName  ( name.toString()   );
          builder.addID    ( id.toString()     );
          builder.addSalary( salary.toString() );
      }

      //...
  }

Answer 1

Question 1:
String parsing seems strange. IMHO you can only do so much to anticipate future enhancements. Either you use a long parameter right from the start to be sure, or consider adding additional constructors later. Alternatively you can introduce an extensible parameter class. See below.

Question 2:
There are several scenarios in which the builder pattern can be useful.

• Complex Object creation

  When you are dealing with very complex object that have lots of properties
  that you would preferably only set once at object creation, doing this with
  regular constructors can become hard to read, because the constructor will
  have a long list of parameters. Publishing this as an API is not good style
  because everyone will have to read the documentation carefully and make sure
  they do not confuse parameters.

  Instead when you offer a builder, only you have to cope with the (private)
  constructor taking all the arguments, but the consumers of your class can
  use much more readable individual methods.

  Setters are not the same thing, because they would allow you to change object
  properties after its creation.

• Extensible API

  When you only publish a multi-parameter constructor for your class and later
  decide you need to add a new (optional) property (say in a later version of your software)
  you have to create a second constructor that is identical to the first one, but
  takes one more parameter. Otherwise – if you were to just add it to the existing
  constructor – you would break compatibility with existing code.

  With a builder, you simply add a new method for the new property, with all existing
  code still being compatible.

• Immutability

  Software development is strongly trending towards parallel execution of
  multiple threads. In such scenarios it is best to use objects that cannot
  be modified after they have been created (immutable objects), because these
  cannot cause problems with concurrent updates from multiple threads. This is
  why setters are not an option.

  Now, if you want to avoid the problems of the multi-parameter public constructors,
  that leaves builders as a very convenient alternative.

• Readability (“Fluent API”)

  Builder based APIs can be very easy to read, if the methods of the builder are
  named cleverly, you can come out with code that reads almost like English sentences.

In general, builders are a useful pattern, and depending on the language you are using, they are either really easy to use (e. g. Groovy) or a little more tedious (e. g. in Java) for the provider of an API. For the consumers, however, they can be just as easy.