0

My question is very simple. I have something like 10 different entities in CoreData, all with the same attributs (name, description ...). To access these attributes i doing in this way:

MyEntity *entity=...;
MyEntity2 *entity2=...;
...
MyEntity10 *entity10=...;

[self myfunction:AnEntity];

After I send a random object to a function

-(void)myfunction:(id)myentity

And here i would like to use a variable which can access the entity attributes whether it's a king of class MyEntity or MyEntity2... The problem is that i can't do:

id myobject=myentity;
NSLog(@"%@", myobject.name);

If someone have a solution to avoid testing the kind of class of the object :) Thanks !

Bobyblanco
  • 123
  • 12

2 Answers2

2

If you have 10 different entities, I think it's time to move to NSManagedObject subclasses. Then you can define a protocol that encompasses all of the shared attributes, and declare that your NSManagedObject subclasses comply with that protocol. Then your call becomes

-(void)myfunction:(id<SharedAttributesProtocol>)myObject

{
    NSLog(@"%@", myObject.name);
}

You mentioned "description" as one of your shared attributes. The -description method is already defined, so you probably want to choose another name for that attribute.

This disadvantage of using a parent NSEntity for the common attributes is that you end up with one very wide table. This table has all of the common attributes, but also has all of the distinct attributes for each of the subentities. Depending on the size of your objects, this will be a performance hit under iOS, although it's not so awful on OS X.

Hal Mueller
  • 7,019
  • 2
  • 24
  • 42
  • You have a valid point with the "wide table, and using a protocol is a good alternative, so I am going to upvote your answer. Choosing one of these solutions depends perhaps on how "different" the entities are and whether it is "logical" to have a parent/child relationship. – Martin R Dec 23 '12 at 21:24
  • Thank you for you answer, actually I thought the best way was to create subclass but it was in order to simplify thing.. sometimes I just need to access one kind of entity some other times all so I choose this solution to clarify. Of course there was also the problem of memory as you said, several small tables are better than one big! Thanks again ;) – Bobyblanco Dec 25 '12 at 22:23
0

In fact you could call

[myobject valueForKey:@"name"]

or even

[myobject name]

in your function, because the methods are resolved at runtime. If myobject has a "name" attribute, this will work, otherwise it will crash at runtime.

A cleaner solution would be to define one "parent entity" MyEntity with the common attributes name, description etc. Then you can define subentities MyEntity1, MyEntity2, ... which have MyEntity as "Parent Entity". These subentities inherit all attributes/relationships of the parent entity, and can have additional attributes and relationships.

The corresponding managed object subclasses are then subclasses of the MyEntity class. Your function could look like this:

- (void)myfunction:(MyEntity *)myentity
{
     NSLog(@"%@", myentity.name);
}

and you can call it with instances of any of the subclasses:

MyEntity1 *myentity1 = ...;
[self myfunction:myentity1];
MyEntity2 *myentity2 = ...;
[self myfunction:myentity2];
Martin R
  • 529,903
  • 94
  • 1,240
  • 1,382