After tries and refactorings with GenericEntity and EntityId in mmm-util-entity we now came up with with a new and much better approach in mmm-util-data that is provided via the Id interface and its implementations. For final freedom we decided to allow arbitrary types for the primary key (was already done before) and now also for the "version" that was so far fixed as long. It should now be possible to use any Comparable (all we need to check if a version is newer than another version).
As the Id interface is designed to be broadly used it was decided not to be overloaded with generics and only carries the referenced entity as generic but nothing else. Hence the version will there be not typed any further than Comparable<?>. The abstract implementation AbstractId will offer generics for entity, id, and version and will be extended by all implementations of Id. It can be used by generic code to deal with version or id in a more type-safe manner without begging the regular API user.
hohwille
commented
7 years ago
After tries and refactorings with
GenericEntityandEntityIdinmmm-util-entitywe now came up with with a new and much better approach inmmm-util-datathat is provided via theIdinterface and its implementations. For final freedom we decided to allow arbitrary types for the primary key (was already done before) and now also for the "version" that was so far fixed aslong. It should now be possible to use anyComparable(all we need to check if a version is newer than another version). As theIdinterface is designed to be broadly used it was decided not to be overloaded with generics and only carries the referenced entity as generic but nothing else. Hence the version will there be not typed any further thanComparable<?>. The abstract implementationAbstractIdwill offer generics for entity, id, and version and will be extended by all implementations ofId. It can be used by generic code to deal with version or id in a more type-safe manner without begging the regular API user.