Can both sides be right?

Stroustrup & Meyers versus Bloch & Wagner

by Conrad Weisert
August 8, 2013
© 2013 Information Disciplines, Inc.

"Provide as good support for user-defined types as for built-in-types."

Bjarne Stroustrup

"You should always make small value objects, such as PhoneNumber and Complex immutable."

Joshua Bloch

Those two bits of advice appear to be in direct conflict with each other.

Of course Java doesn't support overloaded operator syntax, so Bloch's warning often goes unnoticed by Java programmers, who tend to avoid numeric objects anyway. If you follow Bloch's advice you mustn't even simulate the compound operator with an addSet or addTo method. But then Bill Wagner, writing about C#, a more flexible language than Java, echoes Bloch's advice.

Not a real conflict

Those four OOP experts actually agree, once we clarify the essential distinction that eluded them1:

Bloch's PhoneNumber example is apt. Programs don't do arithmetic on telephone numbers. But his Complex example doesn't fit the purpose or the spirit of numeric objects. He probably just didn't think about it carefully. If we prohibit straightforward code like this:

   Complex x, y;
   x += y;
then we burden our program in two ways:
  1. Unnecessary overhead in allocating and initializing new objects.

  2. Worse, clumsy and repetitive Java-like notation instead of natural and readable arithmetic expressions.

If Bloch and Wagner are more concerned about accidental (or malicious) data modification than about either efficiency or readability, then the object-oriented languages provide other tools they can draw upon. The user program is free to create const or final objects. However, the nature of typical numeric computation renders such concerns unlikely. Why does a Complex or a Money item need more protection against accidental change than a double or a long item?

1—This essential distinction continues to elude most writers on OOP.

Return to Technical articles
IDI Home page

Last modified August 8, 2013