Object oriented artifacts in a functional world

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

I love this:

In the world of object-oriented programming, it is common to create classes to represent data elements from your domain. These classes run into all kinds of trouble. First, they tend to breed closely coupled classes like DTOs and XML type mappers. Second, they rarely contain any intelligence and sometimes don’t contain any behavior at all. Third, proliferating concrete classes can make it hard to see common abstractions trying to escape.

In the past, I answered all of those objections by arguing that they were “merely” bad design. It is possible to do good OO design that doesn’t suffer from those failings. I’ve reluctantly come to believe that the majority of OO code will never escape those failings. Common style, frameworks, and tools all push toward a design dominated by “god classes” and data containers.

Instead of fighting that, I’ve decided to embrace it. If your objects are just going to be data containers, then embrace the data! Don’t hide it away inside objects, and don’t fragment your namespace of functions over the data by splitting them across dozens of classes.

Now when I build applications in Clojure I tend not to use Clojure’s OO constructs, protocols and types, for the domain data passing through the system. I’ve followed Rich and Stu down the path of values and data structures.

I do find Clojure’s OO constructs valuable for the structure of the system itself. I like to use protocols to limn the boundaries between subsystems. They provide exactly the degree of information hiding I want. We’ve been evolving a common idiom for creating instances of protocols, where we have an implementation as a type together with a constructor function. The constructor function is considered public, while the type is meant to be private.

There is more at the link. In my opinion, Clojure rescues all that is good about object oriented programming, while allowing us to abandon all that was bad.

Post external references

  1. 1
    http://thinkrelevance.com/blog/2013/11/07/when-should-you-use-clojures-object-oriented-features
Source