Purposes & Properties of Value Objects

Last time we talked about how to reduce the abuse of primitive types, by the extraction of objects to represent concepts in our model domain.

But how shall we design these objects? Let's talk about their fundamental properties.

Imagine we're building a weather app. We recognized that floats weren't the right fit to express temperatures, because it was odd to ask if "a float is cold". Better to extract Temperature. We call it a value object.

class Temperature
  def initialize(temperature)
    @temperature = Float(temperature)
  end

  protected

  attr_reader :temperature
end

We have defined a protected accessor (temperature), to let other instances of Temperature to have access to it.

Now let this object to answer that question.

Questions

The main purpose of a value object is answer meaningful questions for our application. Something like: "Is 37°F cold?".

class Temperature
  def initialize(temperature)
    @temperature = Float(temperature)
  end

  def cold?
    temperature < 59.0 # Fahrenheit degrees
  end

  protected

  attr_reader :temperature
end

Temperature.new(37).cold? # => true

Yay! We're now able to tell if a temperature is cold or not.

Comparability

If we look at the implementation of #cold?, we spot the same problem again: we're using a float to represent a model domain concept: the cold threshold temperature. That's primitive obsession biting again! We can use Temperature instead.

class Temperature
  def initialize(temperature)
    @temperature = Float(temperature)
  end

  def cold?
    temperature < COLD_THRESHOLD
  end

  protected

  COLD_THRESHOLD = new(59)
  attr_reader :temperature
end

Temperature.new(37).cold?
  # => temperature.rb:8:in `<': comparison of Float with Temperature failed (ArgumentError)

Ouch! We can't compare a Float (@temperature) with a Temperature instance (COLD_THRESHOLD).

What we want here is to make our Temperature to be comparable with other Temperature instances. Luckily there is a useful mixin in Ruby standard library: Comparable.

class Temperature
  include Comparable

  def initialize(temperature)
    @temperature = Float(temperature)
  end

  def cold?
    self < COLD_THRESHOLD
  end
  
  def <=>(other)
    temperature <=> other.temperature
  end
  
  def to_s
    temperature.to_s
  end

  protected

  COLD_THRESHOLD = new(59)
  attr_reader :temperature
end

Temperature.new(37).cold?                  # => true
Temperature.new(37) > Temperature.new(68)  # => false
Temperature.new(37) == Temperature.new(37) # => true

Comparable requires to define the spaceship operator (aka #<=>) and to return -1, 0 or 1 if other is respectively lesser, equal, or greater than. Now, thanks to Comparable, our Temperature is able to respond to comparability checks like lesser than (#<), or equal to (#==).

We're also capable to check if two temperatures are equal if they carry the same value.

Equality

Now we need to get a list of all the unique temperatures of the last month. We start from raw data which include duplicates:

[Temperature.new(44), Temperature.new(68), Temperature.new(68)].uniq
  # => [44.0, 68.0, 68.0] # WRONG

What's going on here? We expected to see 68.0 only once, but there is twice! This bug is caused by how a language like Ruby checks for unique entries.

It transforms the object identity (#object_id) into an integer which will remain constant during the life span of the process. This technique is called hashing.

We can tell our language how to check for identity equality, by providing our own hashing implementation.

class Temperature
  # ...
  alias eql? ==

  def hash
    temperature.hash
  end
end

But wait! We use a value (@temperature) to define its identity?

That's right! Because value objects define their identity by their value. 68°F is.. 68°F – and it will be always equal to 68°F.

[Temperature.new(44), Temperature.new(68), Temperature.new(68)].uniq
  # => [44.0, 68.0]

Immutability

Because we delegate important behaviors to the encapsulated value, we want it to not change. When we implement a hashing strategy we want it to be constant until the end of the program execution. If the value changes, we can't meet this requirement. We should freeze it.

In our case, the value that we hold is a Float, which is already frozen. But if we have other types like strings, hashes, arrays, we should explicitly do that. Preferably, we should define the getter as protected to prevent accidental data modifications.

Conclusion

We designed Temperature to be responsible for specific model domain questions, but also to behave like a primitive.

If you think, our language type system is made of basic "generic primitives", on top of which we build another layer of model domain "specific primitives": the value objects.

Share on Twitter and Facebook

Luca Guidi

Former astronaut, soccer player, superhero. All at the age of 10. For some reason now I write code.