You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 8, 2020. It is now read-only.
background
the current implementations of the integrity tests only allows "excluded properties" (blacklist approach). the reason for that is that if a programmer adds a new property to a class the unit test shall remind him to think about adding this property to the implementations of equals, hashCode and toString or exclude it if it should not be in there. so it is expected that each class is always trying to be as accurate as possible. this means:
a good and diverse hashCode
an expressive toString implementation which is always "up-to-date" with the class' properties
an exact equals implementation
especially for use-cases where multiple non-persistent (primary key is null) entities are stored in a collection
why now includes, when this is not what we want?
sometimes the above mentioned arguments are not so important or the underlying use-cases do not apply. for example sometimes a bean is stored in large collection or map and the hashCode generation and equals comparison must be very fast. caching may not be possible or suitable and the bean does have a lot of properties.
the best argument for an alternative whitelist-approach is, that the programmer may want that the implementation explicitly only includes the "included properties" and nothing else.
I see at least two possible use-cases:
a programmer accidentally adds an already "excluded property" to the hashCode, equals and/or toString implementation.
at the moment this is covered by the assertion of unnecessarily excluded properties, which is ok but could be more semantic
a programmer adds a new property to the class and adds it to the hashCode, equals and toString implementation.
at the moment this will not throw any assertion errors because the property is new (not excluded) and it has been added correctly to all implementations, but it may not be wanted to be there.
implementation details
the excludes and includes feature should be mutually exclusive which means:
setting includes while the excludes are not empty should throw an exception and vice versa
notes
the feature must be documented in such a way that the user is aware of not using the feature for convenience to for example skip an exhausting to write set of excluded properties, but because he really has the requirement to only contain the specified includes in his implementations.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
background
the current implementations of the integrity tests only allows "excluded properties" (blacklist approach). the reason for that is that if a programmer adds a new property to a class the unit test shall remind him to think about adding this property to the implementations of equals, hashCode and toString or exclude it if it should not be in there. so it is expected that each class is always trying to be as accurate as possible. this means:
why now includes, when this is not what we want?
sometimes the above mentioned arguments are not so important or the underlying use-cases do not apply. for example sometimes a bean is stored in large collection or map and the hashCode generation and equals comparison must be very fast. caching may not be possible or suitable and the bean does have a lot of properties.
the best argument for an alternative whitelist-approach is, that the programmer may want that the implementation explicitly only includes the "included properties" and nothing else.
I see at least two possible use-cases:
implementation details
the excludes and includes feature should be mutually exclusive which means:
notes
the feature must be documented in such a way that the user is aware of not using the feature for convenience to for example skip an exhausting to write set of excluded properties, but because he really has the requirement to only contain the specified includes in his implementations.
The text was updated successfully, but these errors were encountered: