Wednesday, March 03, 2004

Value objects

What is the correct design for value objects? I'm not talking EJB, but general user types for any kind of large application which takes external input. Some points I think on:

  • In a language like Java, should value objects be the equivalent of typedefs, that is, embody no knowledge?
  • If a value object has integrity checks in the constructor, what should it do on bad input?
  • In Java, if the value object constructor throws on bad input, should it throw a checked or an unchecked exception?
  • When mapping value objects to persistent storage, should the mapping match the underlying native type or should it also reflect input restrictions?

Colleagues and I have been discussing this since I joined my current project, and we settled on the most restrictive options: in Java, throw checked exceptions for bad input and in the persistence mapping use the most restricted storage type with integrity checks when possible. I understand the conservative thinking behind these decisions, but I also see that it leads to greater maintenance costs.

Was this the right thing to do?

Post a Comment