Interface ConstraintJustification
- All Known Implementing Classes:
DefaultConstraintJustification
Implementations may decide to implement Comparable
to preserve order of instances when displayed in user interfaces, logs etc.
This is entirely optional.
If two instances of this class are equal,
they are considered to be the same justification.
This matters in case of SolutionManager.analyze(Object) score analysis
where such justifications are grouped together.
This situation is likely to occur in case a ConstraintStream produces duplicate tuples,
which can be avoided by using UniConstraintStream.distinct() or its bi, tri and quad counterparts.
Alternatively, some unique ID (such as UUID.randomUUID()) can be used to distinguish between instances.
Score analysis does not diff contents of the implementations;
instead it uses equality of the implementations (as defined above) to tell them apart from the outside.
For this reason, it is recommended that:
- The implementations must not use
Scoreforequaland hash codes, as that would prevent diffing from working entirely. - The implementations should not store any
Scoreinstances, as they would not be diffed, leading to confusion withMatchAnalysis.score(), which does get diffed.
If the user wishes to use score analysis, they are required to ensure
that the class(es) implementing this interface can be serialized into any format
which is supported by the SolutionManager implementation, typically JSON.
- See Also: