I am working with Martin Fowler's definition as a working base.

I have a class called Condition that I am having trouble properly classifying.

What makes me think this might be a value object:

  1. A given Condition is only valid within a context of a single entity; conditions are never shared, nor addressed independently.

  2. Its equality is based on its values; ie, a single entity should not have multiple of the same condition

  3. They are never modified, only added or removed from a given entity.

However, they have some characteristics not typical of value objects as well:

  1. Very complex logic and behavior.

  2. Potentially, references to first-class entities make up its values.

Should I be treating my Condition class as an entity or a value?

If I do treat it as a value object, is it justified to place its data-access code in with its parent object's data-access code (ParentEntityRepository)? How should I deal with this class differently if it is a value object?

  • How large is the state of your condition object? – Robert Harvey May 11 '18 at 19:11
  • Is it justified to place its data-access code in with its parent object's data-access code -- That has less to do with whether or not it's a value object, and more to do with the fact that it's not a domain entity. – Robert Harvey May 11 '18 at 19:12
  • @RobertHarvey Unknown at compile time in terms of bytes. 3 fields + an ID field, which is only used for convenience – TheCatWhisperer May 11 '18 at 19:13
  • Can you explain in more detail the phrase "references to first-class entities make up its values"? – Robert Harvey May 11 '18 at 19:14
  • Also, is this C#? Some other curly-brace language? – Robert Harvey May 11 '18 at 19:19

Based on the description and the answer you gave in the comments, it sounds to me like condition is not a value object itself but that one of it's components is a value object.

I would only consider something a proper value object if all of it's state is evaluated in determining whether two instances are equal. I would even go so far as to say that (e.g. in Java) you should not define an equals or hashcode for an object unless it is immutable and every piece of state is used as part of the implementation. Under this rule, any object that has equals implemented is a value object.

If this works for your situation, it opens up the option of using flyweights for these value objects within your condition objects.

  • Why not define equals for an entity to compare their Id(s)? You might have to separate instances that refer to the same entity – TheCatWhisperer May 14 '18 at 13:03
  • 1
    Are you saying implement an equals on the composite object? I spent a lot of time twiddling around with equals() and what I learned is that universal equality is a useful concept but only in a narrow scope where you essentially don't ever care about about the object instance identity. Outside of that, it starts to create more issues than i solves. If you want to know if two objects refer to the same condition, I would do that directly i.e. a.conditionId == b.conditionId. If you want me to elaborate, I can add to the answer. – JimmyJames May 15 '18 at 13:38
  • I have started to come back to that conclusion as well. – TheCatWhisperer May 15 '18 at 13:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.