equals and hashCode in BaseEntity

[Marcin Kuthan]

I don't understand why equals and hashCode have been overridden in BaseEntity class.

1. The implementation breaks one of the most important methods principle (id is changing during object lifecycle).

2. It will not work for more complex JPA mappings (at least under Hibernate). obj.getClass() returns proxy or dynamically enhanced class in some situations. 

3. In 99% of cases when single JPA session is used, you don't need custom equals/hashCode, default object equality is sufficient

In remaining 1% declare and use method like (concept from one of Eric Evans example):

boolean sameIdentityAs(E otherEntity)

Marcin

[Maciej Hadam]

Have anyone heard about Pojomatic project?

http://pojomatic.sourceforge.net/

Declarative configuration of properties being used for equals,
toString, hashcode methods is excellent.

[Marcin Kuthan]

As I understood, authors want to avoid dependency to unnecessary frameworks like pojomatic or http://projectlombok.org/.

[Rafał Jamróz]

I agree - there's no need to provide general implementation of
equals() and hashCode() for entities. You don't event need them for
unit testing.

@Marcin sameIdentity() along with sameValue() (for VO) is a nice
addition. Even though equals() for VO is safe - it makes explicit in
your code how do you want to compare. I don't consider overriding
equals and hashCode in @Entity bad altogether as long as you don't use
JPA id in there but a business ID(entities) or other fields(VO)
instead. Thanks for pointing it out early!

@Maciej I haven't tried Pojomatic but from what I know about Lombok
and similar solutions (like apache-lang EqualsBuilder) there might not
be a place for them in entities, but they fit greatly for comparing
Value Objects

On Sep 2, 12:40 pm, Marcin Kuthan <marcin.kut...@gmail.com> wrote:
> As I understood, authors want to avoid dependency to unnecessary frameworks
> like pojomatic orhttp://projectlombok.org/.

> <http://projectlombok.org/>

[Sławek Sobótka]

Adding example of VO.equals and VO.hashCode (which may be useful in
algorithms using hash-stuctures) implemented using pojomatic is a good
idea. Just to show people nice libraries.

But "magic generators" like lombok in *domain* code == pure evil for
me:)
btw: there is something wrong with the design of the domain if we need
to go this way...

[Marcin Kuthan]

Base class for Value Objects would be also useful. Methods equals and hashCode implemented in reflective way (with commons-lang or pojomatic).

+1 for getting rid of magic generators or aspects in the domain (logic is not explicit and hard to test).