These are my thoughts after having read the first two articles about Design Patterns and Java 8 on Voxxed, because I need to reflect about the shadows of the new approach.


Mario Fusco, the author of the aforementioned articles, is publishing a series of articles about Design Pattern revisited from the point of view of Java 8: the new way is more concise and highlights what the source code does, but it seems to me that in some ways it has lost some degree of structure, organization, and meaning.

I would like to tell that I’m quite fond of the new possibilities brought by Java 8: streams, lambda expressions, declarative programming, Optional type, …
But I’m not sure about the tradeoff between pros and cons of such a complete rewrite of Design Patterns.

I believe we should keep in mind that the ideas expressed by GoF’s book and Fusco’s articles are possible solution of common programming problems: they serve as starting points, described in a simplified context, to learn new possible solutions and their implications in real contexts.

Thanks to Fusco, we’ve added a new weapon to our arsenal for defeating programmin problems: we have to understand when and where it will be best used.

Hierarchical organization

Not always “less code” means “less work”: let’s start with an example that is indipendent from Java 8 technologies.

In the “revisited Command Design Pattern” section of the original article, the custom Command interface is replaced with the JDK’s Runnable interface: so we save one entity, but at what cost?
We may imagine a programmer that works on a real world project with dozens or hundred of entities: at some point, he would use one of the already implemented commands, so he could ask his IDE to show them (how often we hit ctrl-space or ctrl-T in Eclipse?).
Depending on which interface we used (custom Command or standard Runnable), we will get a list of our Command-implementing classes or a full list of every Runnable defined in JDK and in our project. I haven’t tried, but the latter list will be so huge that it is too hard to find a useful class in it in a short time.
Maybe a good tradeoff between type hierarchy and repeated code avoidance, could be the use of a “marker interface“:

interface Command extends Runnable {}

Stir the code

With Java 8’s features, we may replace Command (and Strategy and Template) implementations with a bunch of static methods. In every case, the responsible programmer should write a well organized program: we may create a container class for every set of Command/Strategy/… static methods (for example, FileSystemCommands, CloudCommands, …, TextFileStrategy, ImageFileStrategy, …); or think of some other smart organization.
But the IDE and the other programmers are not aware of any of those methodologies.

Moreover, as the project grows, the basic implementations (i.e. the classes containing static methods) may end up in libraries, and new implementations will be created in client modules. The latter implementations unrelated with the former.
Will we or our IDE be able to find all and only methods of one type? For example, at some point we will need one of the already defined Command methods, so we could find ourselves looking for every static method accepting a single String parameter.


As a final note, I didn’t like Fusco’s attitude to put “old OOP style” in a bad light: three examples of incoherences introduced during the pattern reimplementation process.

As said before, in the Command pattern review, the Command interface is suppressed: it could already be done in the classic pattern, if desired.

During the discussion of the Strategy pattern, the revisited implementation is actually a replacement of *two* traditional strategies, not of a single one with two methods: it is natural that the new way seems more elastic than the previous.

The Template pattern is rewritten with a single method istead of three. (Yes, they are very simple methods indeed: I believe they are there in the GoF’s implementation for illustrative purposes)

My two cents

Apparently, I don’t like nouns as Mario Fusco does. đŸ™‚
Actually, I don’t like (and already didn’t like) a structure that doesn’t help me to understand the software architecture or that mixes parts with etherogeneous meanings and aims (that judgement is very personal, of course).
Infact I believe I will continue to prefer a class to a lambda expression except for very trivial tasks (in the same way I have tried to avoid anonymous classes and static utility method in the past).

An update with links to the so far published articles:

  1. Gang of Four Patterns in a Functional Light: Part 1
  2. Gang of Four Patterns in a Functional Light: Part 2
  3. Gang of Four Patterns in a Functional Light: Part 3
  4. Gang of Four Patterns in a Functional Light: Part 4