As a developer, I want the interface "Entity" to define the contract for all openMDM entities, and "BaseEntity" (renamed to "AbstractEntity") is a convenience top class (whose use is optional).
The relationship between the interface "Entity" and the base class "BaseEntity" is not clear. Obviously, only the interface "entity" should be visible for API clients; on the other hand, each entity class is supposed to inherit from "BaseEntity" - a class that makes significant specifications regarding the internal representation of an entity. This combination makes no sense: either the binding contract for entities is defined by the interface "entity" (in this case, "BaseEntity" would be a convenience class from which you can inherit but does not have to), or the contract is defined by "BaseEntity" (in this case, an additional interface is only confusing).
Since the specification of explicit superclasses strongly limits the implementation possibilities for entities, and contracts should be modeled better than interfaces anyway, I would suggest the first variant in which the interface "entity" defines the contract for all openMDM entities and "BaseEntity" (renamed to "AbstractEntity") is a convenience top class (whose use is optional). "Entity" should contain Getter for "SourceName", "ID", "Name", "Type", and "MimeType" (where "Type" returns a direct reference to the type and not just the name). Additionally, Getters for all outgoing relationships of the entity (e.g. getParent (Type), getChildren (Type), getInfo (Type)) would be good.
Decision from mdm Hackathon (23.10.2017)
We can’t refactor Entity and BaseEntity because:
Entity is needed as an interface because the interface Describable extends Entity as it uses Entity.getValue() in its default implementation.
BaseEntity is needed as an abstract class to restrict visibility to methods like getCore(). If BaseEntity would be an interface a restriction of visibility is not permitted.
The fundamental design of this polymorphic graph is not optimal. Further analysis for restructuring is recommended, but exceeds the scope of current sprints.