It is possible to have one NSManagedObject subclass represent multiple Core Data entities. For example the class Thing could represent the entities Vegetable and Blanket even when the data is modelled such that Vegetable and Blanket do not share heritage.
I assume that the engineers at Apple did this for a rational reason. But I cannot think of a single circumstance when using one class for multiple entities would be useful or wise. A one-to-one mapping of class to entity seems like the only practical use case.
What could the rationale be for this design decision?
I don’t think anyone ever does it but as long as the entities have the same keys you could use the same NSManagedObject subclass to represent them.
You can do this because NSManagedObject itself is designed to be able to represent any entity using its associative storage. When you don’t bother to subclass, you end up with instances of the NSManagedObject class representing each of the different entities in your data model.
NSManagedObject subclasses don’t really change that much. The properties defined in the subclasses are really just wrappers around the NSManagedObject base classes associative storage. (That’s the one you access with
primativeValueForKey:. The subclass are largely a convenience to provide easy access and any customized behavior the data model itself cannot provide. However, they retain NSManagedObjects flexibility.If you have subentities that change nothing but the name of the enitity, then you could safely use the same class to represent them. If they differ in any other way, however, it would be reckless to do so.