You could also do this with a protocol, but the nice thing about using a base class that the other classes inherit from is that you only have to implement this functionality in one place. If the 7 classes don't all currently inherit from the same base class (which would end up being the superclass of DatedObject), a protocol is probably the way to go. In that case, you can declare your method like this:

One of the big advantages to these two approaches over what you've posted in your question is that you get more help from the compiler in catching places where your code sends a message to an object that doesn't respond to it.

k, implemented inheritance. once you and Joe said it, i pretty much did a /facepalm. thanks for the guidance.
–
Log139Feb 2 '12 at 22:49

+1 for answering since I was too lazy. Also @Log139 note that you were getting lucky that what you were doing works because Obj-C is a dynamic language. If you were trying to do the same thing with a more "primitive" type such a struct you would run into issues with memory layout.
–
JoeFeb 3 '12 at 14:39

ok, say i have a method that accepts DatedOjbect and i pass it Object1 (subclass of DatedObject), when i try to access Object1's properties, i can't. i can type cast it to an Object1 and get access to Object1 properties. is this ok?
–
Log139Feb 3 '12 at 21:47

Well, yes and no. It will work. The problem is, if you pass in an Object2 (a different subclass of DatedObject), and it tries to access Object1 properties that Object2 doesn't support, you'll get an exception. If the method's argument takes a DatedObject, you should only call methods that DatedObject declares. If the method in question never takes anything other than Object1s as an argument, you should specify that the argument is of type Object1. Does that make sense?
–
Andrew MadsenFeb 3 '12 at 21:49

yes. what i ended up doing is using "isKindOfClass" (i tested this, i used "if ([<object passed to method> isKindOfClass[Object1 class]])", if i passed an Object1, it returned true; if i passed Object2 it would return false (er, my else stmt would trigger). i got the same results if i used "isMemberOfClass" (i think isKind will return true of a child checked, and isMember will only if its an exact match?).
–
Log139Feb 6 '12 at 21:06

Parameters of type id don't do any type checking at compile time (like the values in an NSArray) so you can call any method you want on them without generating compiler warnings (this is obviously quite dangerous if you aren't careful).

You can't use dot notation on id variable without casting, but it's better to cast from an id to a concrete type than to cast from a different unrelated type.

It doesn't actually make any difference except to your code readability though.