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?
No comments:
Post a Comment