High-Level Processing or Low-Level Data?


Essentially, I'm trying to answer this question - is it better for objects to expose raw, unprocessed data OR higher-level, processed information. Think Vehicle::GetSpeed() vs Vehicle::IsMoving().

While I think I know the answer, what I'm really after is some literature on the matter - does this subject have a name?


Yes, I can think of two named concepts involved in this discussion:

  • "data hiding” (not “encapsulation”)
  • “context dependence”

First, the “data hiding” part. I like that IsMoving() doesn’t reveal implementation details compared to GetSpeed(). IsMoving() expresses itself at a higher level of abstraction, and abstraction is more stable, so depending on abstractions is generally less risky than depending on details. (Read more at "Demystifying the Dependency Inversion Principle")

Next, the “context dependence” part. I like that I can use GetSpeed() in other contexts besides deciding IsMoving(). This makes GetSpeed() easier to reuse in a variety of situations that have nothing to do with merely deciding whether the vehicle is moving, so I can recombine GetSpeed() without having to change it in order to build new things. Context-independent code tends to be easier to reuse safely. (Read much more at Growing Object-Oriented Software Guided by Tests)

So, it depends. If I have GetSpeed() and I want to compute IsMoving(), then I will eventually introduce IsMoving() onto Vehicle. (In Java, for example, we have both List.size() and List.isEmpty(), playing the same roles.) If I have only IsMoving() and I want to use the vehicle’s speed for some other purposes, I might extract GetSpeed(), anyway.

I can’t say that one is universally better than the other.

One last thing: when building toolkits, I want small, context-independent, recombinable pieces; but when building full applications, I want cohesive, abstract, self-documenting things. I can build the second ones by composing the first ones and giving them nice, abstract names.


J. B. Rainsberger, "Demystifying the Dependency Inversion Principle". An overview of the principle.

Steve Freeman and Nat Pryce, Growing Object-Oriented Software Guided by Tests. A tour de force of designing software well; the book I wish I'd written.

Complete and Continue