Question

I’m looking for advice on whether or not this is a good practice. I apologize for the long form explanation. I have a large grid of x,y coordinates. The grid is occupied by objects of varying classes, all with different methods and data. When a user touches a grid coordinate, I’m looking for the cleanest way to route my program to the proper method, dependent on the object type.

I’ll use shapes as an easy way to explain what I’m doing. Say I have 2 classes, Circle and Square both with a parent class of Shape.

I’m adding objects of Circle class and Square class to an NSMutableArray called shapeManager. When a user touches the grid I want to figure out the object type for that coordinate so I can route to the appropriate method.

for (Shape *shape in shapeManager) {

  if (shape.type == kCircle) {

    [self circleSelected:shape];

  }

}

-(void)circleSelected:(circle *)circle { }

Am I recasting the pointer as a different class when I do this? Are there any downsides to this? I’m just looking for a good way to handle a touch event on a grid, when the object that lives at that coordinate is unknown and of multiple possible classes.

Answer 1

The downside to your approach comes if you add another Shape – you end up having to change this code. The other approach is to add a method, say userSelected, to your Shape class and have each subclass override this method to do whatever is appropriate for the kind of shape they represent.

In this other approach your loop becomes:

for(Shape *shape in shapeManager)
   [shape userSelected];

And, for example, Circle gains a method:

@implementation Circle

// override Shape's userSelected and do what a circle needs to do
- (void) userSelected
{
   ...
}

Which approach you choose is up to you, there is no right answer per se, but object-oriented style usually favours the latter.

Comment Followup

To go from a child to a parent you do not need a cast, but can include one – this is a fundamental plank of inheritance-based object-oriented languages like Obj-C.

Going the other way, from parent to child, in Obj-C (a) requires a cast and (b) should be protected by a check – both because you don’t know which, if any, of the children you have. In Obj-C (a) just tells the compiler you think you know and it should trust you, (b) is you checking to make sure!

You do (b) with [<obj> isKindOfClass:[<classname> class] which tests if <obj> is of type <classname> or any of its children; or you can use isMemberOfClass which tests if <obj> is of type <classname> but not any of its children. The former is more common to allow for easy expansion (e.g. you may start off with Rectangle being a Shape and later introduce Square being a Rectangle; a test for isMemberOfClass:[Rectangle class] would be YES for both Rectangle and Square while isKindOfClass:[Rectangle class] is only YES for Rectangle).

Explicit testing is commonly not required as method dispatch often subsumes it – as in [shape userSelected] above which will call the appropriate implementation of userSelected based on the actual type of shape at runtime. When explicit testing is required using tests and casts is the way to do it.

And yes, collections of mixed type are common, indeed they are another of the planks of inheritance-based object-oriented languages like Obj-C.

[Note: What Obj-C lacks which a number of other languages have is a way to limit what a collection may contain. E.g. an NSMutableArray can contain any object, while in your case it might be beneficial to be able to say NSMutableArray of Shape to limit it to just Shape and its subclasses. C#, Ada, and even C++ (in as much as it enforces anything) all provide this. If you need to you can do it yourself in Obj-C, see this answer.]