Question

I have an Offer class (NSManagedObject subclass) that I want to use to handle offers made for purchases. One side of each offer is a buyer and the other side is the product. There is also a price. However these class instances that can be buyers have pretty different lineage and most likely will have different parent classes all the way back to NSManagedObject. Same thing is true for the products.

Because of this I don’t want to make “Buyer” and “Product” abstract classes that these items would inherit from. I’d much rather just have protocols “buyable” and “purchasable” and have classes implement how they are purchased and how they make purchases. Unfortunately it seems as though relationships in NSManagedObjects don’t allow you to specify classes by their protocols.

Any way around this? Can someone set me straight? Rob

Answer 1

You can’t assign a protocol because the context has to instantiate an actual object and protocols don’t tell the context what class to instantiate. E.g. if you tell the context to insert a Buyer protocol what subclass would actually get created?

It sounds what you actually need are subentities. You would create abstract entities for Buyer and Product then relate both to Offer. Then for every variation of Buyer or Product create a subentity. The entities don’t have to add new properties they can just have a different name. This way, an Offer object will accept any subentity of Buyer in its buyer relationship and any subentity of Product in its product relationship.

Then assign a different class to each subentity to customize the entities behavior.

The key thing here for you is that the inheritance of the classes does not have to parallel in anyway the entity inheritance. Your class tree can be completely different than the entity tree. As long as the individual class maps onto the individual entity, it will work.

Abstract entities are pretty much protocol definitions themselves. They define the interface an entity must have but do not themselves implement anything.