9. Polymorphism, Dynamic Typing, and Dynamic Binding
#obc#
*Polymorphism* enables programs to be developed so that objects from different classes can define methods that share the same name. *Dynamic typing* defers the determination of the class that an object belongs to until the program is executing. *Dynamic binding* defers the determination of the actual method to invoke on an object until program execution time.
## polymorphism: same name, different class
Polymorphism enables you to develop a set of classes that each can respond to the same method name. Each class definition encapsulates the code needed to respond to that particular method, and this makes it independent of the other class definitions. This also enables you to later add new classes that can respond to methods with the same name.
## dynamic binding and the `id` type
how does it know which print method to invoke?
As noted previously, the answer lies in the fact that the Objective-C system always keeps track of the class to which an object belongs. It also lies in the concepts of dynamic typing and dynamic binding. That is, the system makes the decision about the class of the object, and, therefore, which method to invoke dynamically, at runtime rather than at compile time.
## compile time versus runtime checking
```
id dataValue = [[Fraction alloc] init];
...
[dataValue setReal: 10.0 andImaginary: 2.5];
```
When the program is executing, the system first checks the type of object stored inside `dataValue`. Because `dataValue` has a `Fraction` stored in it, the runtime system looks for a method `setReal:andImaginary:` defined for the `Fraction` class. Because it can’t find such a method, the error message shown previously is issued and the program is terminated.
## the `id` data type and static typing
First, when you define a variable to be an object from a particular class, you are using what’s known as *static* typing. The word *static* refers to the fact that the type of object that will be stored in the variable is being explicitly declared. So the class of the object stored in that type is predeterminate, or *static*. When you use static typing, the compiler ensures, to the best of its ability, that the variable is used consistently throughout the program.
Another reason for using static typing is that it makes your programs more readable.
## argument and return types with dynamic typing
If a method with the
same name is implemented in more than one of your classes, each method must agree on the type of each argument and the type of value it returns so that the compiler can generate the correct code for your message expressions.
## asking questions about classes
*截图占位符*
To generate a class object from a class name or another object, you send it the `class` message.
To generate one of the so-called selectors listed in Table 9.1 , you apply the `@selector` directive to a method name.
Remember that `isMemberOfClass:` tests for direct membership in a class, whereas `isKindOfClass:` checks for membership in the inheritance hierarchy.
## exception handling using `@try`
```
@try {
statement
statement
...
}
@catch (NSException *exception) {
s tatement
statement
...
}
```
An `@finally` block can be used to include code to execute whether or not a statement in an `@try` block throws an exception. An `@throw` directive enables you to throw your own exception.
In general, you don’t want exceptions to occur while your program is running. So it’s considered better programming practice to test for errors before they occur rather than to catch them after they occur. It’s also better to test for an error in a method and return some value as an error indicator than to throw an exception. It is strongly recommended that if you catch an exception you only do so with the intention of cleaning up and terminating your application. Why? Because Apple does not guarantee that your application will be in a well-defined state for continuing program execution once an exception is thrown.
