1

So I've read Effective Java: Chapter 3. Methods Common to All Objects (a lot over the years :) ) and DDD from Erich Evans (a lot over the years :) ) And always follow the convention of comparing ids when writing equals functions for entities and for value types using the internal state / data of the object. So now we have a new challenge where we have an application with an existing rich domain model which should be persisted in the future. I have a very specific question about this where I am experiencing a bit of code writers block. There a few classes in there that have no identity with various pieces of information... a typical value object you might say... but also have references to other child objects (i.e. object graph). So it would usually be something like:

public class BeeskneesEntityA {
    private Long id;
    private Voj childV;
}

public class Voj {
    private Long priceInCents;
    private Long otherLong;
    private BeeskneesEntityB childB;
}

public class BeeskneesEntityB {
    private Long id;
    ...
}
  1. How would equals be written in this case ignoring for a moment that we will persist it? Should the child objects be navigated and also be checked for equality?
  2. What would be the best way to persist these objects? Give them an id?
dashambles
  • 529
  • 8
  • 22
  • 1
    Using the `id` to determine equality is the worst idea ever. You could have two `equal` objects, one that is persisted already (having an id), the other in a transient state (without id). If you determine equality based on the id, they would be considered different, even if they aren't. Keep in mind `equal` means `equal` - neither beeing the same object nor beeing an object of the same origin. Also if you have modifications to Loaded Objects (with id) this object should no longer be equal to any other object having the same id but the original attributes. – dognose Oct 19 '15 at 11:41
  • 1
    You can use id!. It all depends on what equals means to your objects. For example in a list of user objects you may consider two objects as equal if they have the same username as username could not be same for two d/t users. – dsharew Oct 19 '15 at 11:44
  • @DegenSharew Using the `id` as only attribute for the `equals` method creates so much trouble you need to handle: You cannot add 2 or more unsaved instances to a set or hashmap, as they are considered equal, therefore overriding the other instance. If you have some sort of bulk-editing you need to manually detect changes, rather than using `equals` to find changed instances and perform a selective update based on non-equality. – dognose Oct 19 '15 at 11:59
  • Related: http://stackoverflow.com/questions/17003427/is-it-proper-for-equals-to-depend-only-on-an-id – jaco0646 Oct 19 '15 at 14:00
  • I absolutely don't agree about it being the worst idea ever. In many cases (imagine something like an entity that needs to be persisted which has 2 arbitrary floats and a foreign key to another table) it is the only possible solution. But I don't want to get into that here and it is not what the question is about. – dashambles Oct 19 '15 at 14:53

0 Answers0