XPUG Milano, November 30th

Yesterday Uberto Barbini held the second part of his Agile Day presentation at the eXtreme Programming user group in Milan. Here are the topics of the talk and the discussion, that you can also follow on the slide deck.

At the conference (video in Italian), Uberto covered only part of the presentation, so he restarted from the half presentation check:

• many bugs are caused by shared, inconsistene state
• the procedural paradigm doesn't care how you organize state
• OOP encapsulates state inside objects
• functional programming expels state from pure functions.

An example of OOP went wrong was a MyBag object which allows read and write access to any item inside. The Singleton pattern used for no reason and the absence of any form of Dependency Injection are other common pitfalls: just because a piece of code contains many classes and methods it does not mean it is object-oriented.

The Blackboard

An interesting thing came up while this non-OO code was presented to us: we cannot judge a design without knowing which is the underlying problem it solves. While changing class names simplifies a slide, the same Blackboard metaphor can be implemented with wildly different results:

• in the case of a list of actions to perform, it couples the actions in a certain order; the first or second action populates the blackboard for the other ones and cannot be moved.
• in a distributed scenario, it decouples different processes from knowing the rest of the system, and allows new configurations.

Yet the scenarios are identical if not for the names of classes and methods.

The presentation went on to compare the object-oriented and functional approach as different tools for solving different problems: they are not always in competition, but code can contain a mix of both according to the problem at hand. For example, Uberto cited simulations as a really natural place for objects, and transformations of data into different formats (XML, JSON) as a call for pure functions.

This reminded me of the Expression Problem and of how new requirements favor either the functional or object-oriented solution.


Rebecca's book

I'm not sure I will understand the Centralized/Dispersed/Delegate control comparisons before reading Rebecca Wirfs-Brock's book on design, but an issue that came up is that this kind of books is disappearing, despite being very handy in teaching design. Today we see many technical books which teach how to code in Java or Clojure or Ruby, but not book on how to model and solve problems with code.


Elegance and familiarity

A final note is Rick Hickey's (inventor of Clojure) quotation:

Elegance and familiarity are orthogonal.

Just because we see functional code as strange and different from the object-oriented approach, it does not mean it's inelegant: probably just that we are not familiar with it. It is closed against different changes than the equivalent OO solution; and a functional programmer will see our objects as inelegant too.