Java 和 Objective C 比较

Like C++, Java has numerous features that Objective-C does not have or implements in 

different ways.  For instance, classic Objective-C has no garbage collector but has retain/release 

and the autorelease pool. You can turn on garbage collection in your Objective-C programs 
if you wish. 

Java interfaces are like Objective-C formal protocols, as they both require the 

implementation of a set of methods. Java has abstract classes, but Objective-C 

does not. Java has class 

variables, while in Objective-C, you use static file scoped global variables and provide 

accessors to them, as shown in the “Coming from C++” section. Objective-C is pretty loose with 

public and private methods. As we’ve noted, any method that an object supports can be 

invoked, even if it doesn’t appear in any external form, such as a header file. 

Java lets you declare classes final, preventing any subclasses from being made. Objective-C goes to the 

other extreme by letting you add methods to any class at runtime.

Class implementations in Objective-C are usually split into two files: the header file and the 
implementation itself. This separation isn’t required, though, for small private classes, as 
you’ve seen with some of the code in this book. The header file (with a .h  extension) holds 
the public information related to the class, such as any new  enums, types, structures, and 
objects that will be used by the code that uses this class. Other bodies of code import this 
file with the preprocessor (using  #import). Java lacks the C preprocessor,  which is a textual 
substitution tool that automatically processes C, Objective-C, and C++ source code before 
it is given to the compiler. When you see directives that start with #, you know that line is 
a command to the preprocessor. The C preprocessor actually knows nothing about the C 
family of languages; it just does blind text substitutions. The preprocessor can be a very 
powerful—and dangerous—tool. Many programmers consider the lack of the preprocessor 
in Java to be a feature.
In Java, almost every error is handled with exceptions. In Objective-C, error handling  
depends on the API you’re using. The Unix API typically returns a –1 value and a global error 
number ( errno) is set to a specific error. The Cocoa APIs  typically throw exceptions only on 
programmer errors or situations where cleanup is not possible. The Objective-C language 
provides exception handling features similar to Java and C++:  @try,  @catch , and @finally . 
In Objective-C, the null (zero) object is termed  nil . You can send messages to nil and not have 
to worry about a NullPointerException. Messages to nil are no-ops, so there is no need to 
check your message sends against  NULL. Messages to nil are discussed earlier in the “Coming 
from C++” section.
APPENDIX: Coming to Objective-C from Other Languages 315
In Objective-C, you can change a class’s behavior at runtime by adding methods to existing 
classes using categories. There are no such things as final classes in Objective-C; you can 
subclass anything, as long as you have a header file for it, because the compiler needs to 
know how big an object the superclass defines.
In practice, you end up doing a lot less subclassing in  Objective-C than in Java. Through 
mechanisms like categories and the dynamic runtime that allows sending any message 

to any object, you can put functionality into fewer classes, and you can also put the 

func -tionality into the class that makes the most sense. For instance, you can put a category on 

NSString  to add a feature, such as reversing a string or removing all white space. Then, 
you can invoke that method on any  NSString , no matter where it comes from. You’re not 
restricted to your own string subclass to provide those features.
Generally, the only times you need to subclass in Cocoa  are when you are creating a brand 
new object (at the top of an object hierarchy), fundamentally changing the behavior of an 
object, or working with a class that requires a subclass because it doesn’t do anything useful 

out of the box. For instance, the NSView  class used by Cocoa for making user interface 

components has no implementation for its drawRect: method. You need to subclass  NSView  and 

override that method to draw in the view. But for many other objects, delegation and data 
sources are used. Because Objective-C can send any message to any object, an object does 
not need to be of a particular subclass or to conform to a particular interface, so a single 
class can be a delegate and data source to any number of different objects.
Because data source and delegate methods are declared in categories, you don’t have to 
implement all of them. Cocoa programming in Objective-C has few empty stub methods, 
or methods that turn around and invoke the same method on an embedded object just to 
keep the compiler quiet when adopting a formal protocol.
With power comes responsibility, of course. With Objective-C’s manual retain, release, and 
autorelease memory management system, it’s easy to create tricky memory errors. Placing 
categories on other classes can be a very powerful mechanism, but if abused, it can make 
your code difficult to untangle and impossible to give to someone else. Plus, Objective-C is 

based on C, so you get all of C’s baggage, along with its dangers when using the 

preproces-sor, including the possibility of pointer-related memory errors.

End