Game Development Reference
the selectorString will be one of the following, depending on the con-
tactType and the otherObj class name:
// and so on . . .
Before performing the selector, notifyAB first checks whether obj actually re-
sponds to that selector. In the current implementation, only the Plunger class imple-
ments one of the selectors: beginContactWithBall . All other selectors will never
be performed because they don't exist (yet).
The Contact class is also defined in ContactListener.h and merely acts as a
container object holding any collision information that you might want to pass to re-
ceiving classes. By using a container class, the selector format doesn't need to change
when you decide to pass more or less information, simply because the only parameter
is a pointer to a Contact object, and the information is encapsulated within the
Tip There's also a technical reason for using a container class. The per-
formSelector method of the NSObject class knows only three variants:
with zero, one, or two parameters. Because you definitely like to pass on more
than two parameters to the receiving object, there's simply no other choice than
to use a container class. Whenever you find the performSelector method
limiting, remember that you can always create a container class holding any in-
formation that you'd like to pass on to the class implementing the selector.
Because Contact is such a simple class, Listing 13-21 shows both interface and im-
plementation in one listing.
@interface Contact : NSObject