“primitive obsession” or “open secret”?

Yesterday Corey Haines posted yet another great video interview with JB Rainsberger. This time the topic under discussion was the Primitive Obsession code smell — what it is, how to recognise it, why it is a problem, what to do about it, and what you’ll see when you’ve fixed it.

I agree with JB — this is a difficult concept to communicate when teaching, and I think part of that comes from the name Primitive Obsession. In fact, after a vast amount of deliberation, Bill Wake and I proposed the alternative name Open Secret in our book Refactoring in Ruby. Our reasoning is that, as JB points out in the video, the essence of this smell is the fact that the lack of an encapsulating abstraction pushes knowledge and responsibilities and behaviour out into the open; whereas the representation of that knowledge should be a secret. It’s not so much the primitives that are the problem, but that they represent a domain abstraction — and that one chosen representation of that concept is visible to, and necessarily understood by, all and sundry.

Does that rename help explain this code smell?

Advertisements

communicating intent is all about names

Ths ten-minute video chat between Corey Haines and J.B.Rainsberger introduced a nice simplification of eXtremeNormalForm.

In the discussion, JB hardens up the wishy-washy Communicates Intent value by noting that it’s just about “bad names”, and here’s why. In an OO language, “communicating intent” boils down to breaking the system into small pieces and giving them good names, names that resonate with the design and the domain. Small pieces are no good on their own, and good names for bad ideas will soon be weeded out. JB therefore claims that good design (he says good architecture) boils down to

  1. eliminate duplication
  2. eliminate bad names

(He takes passing all tests – ie. correctness – as a given, and he says that eliminating duplication and bad names also renders the software “small”. I disagree on that last point.) So, his assertion is equivalent to saying that every code smell is a symptom of either Duplication or Bad Names, which I find easier to explain than asking people to ensure that the code “communicates intent”.