Objective-C 2.0编程语言详解

需积分: 9 152 浏览量更新于2024-07-28 收藏 1.22MB PDF 举报

"《Objective-C 2.0 编程语言》是一本关于Objective-C 2.0编程的原版书籍，被广泛认为是权威的学习资料。由Apple Inc.于2008年出版，该书详细介绍了Objective-C 2.0的各个方面，并对开发者进行应用开发提供指导。" 本书详细阐述了Objective-C 2.0编程语言的核心概念和技术，包括面向对象编程的基本原理、语法特性以及Apple的 Cocoa 框架。Objective-C是苹果操作系统如Mac OS X和iOS中的主要编程语言，它在C语言的基础上扩展了面向对象的功能。首先，书中会介绍Objective-C的基础，如类、对象、消息传递机制，这些都是理解任何面向对象语言的关键。Objective-C的类定义方式、对象的创建与销毁、以及如何通过消息发送来调用方法，都是初学者需要掌握的基础知识。接着，书中会深入讲解Objective-C 2.0的新特性，比如属性（Properties）的使用，这极大地简化了对象成员变量的访问。属性提供了自动内存管理、存取方法生成和类型安全等便利。此外，还会涵盖协议（Protocols），这是Objective-C中的接口概念，允许类间不强制继承关系的通信。此外，本书还将探讨内存管理，包括引用计数（Reference Counting）和后来引入的自动引用计数（Automatic Reference Counting, ARC），这些是避免内存泄漏和确保程序稳定运行的关键技术。Objective-C中的Block（块）也是重点内容，它是处理异步任务和复杂控制流的一种强大工具。在Cocoa框架部分，读者将学习到如何利用Foundation和AppKit（或UIKit）框架构建应用。这些框架包含了大量预定义的类和接口，用于图形用户界面、网络通信、文件系统操作等。同时，也会讲解模型-视图-控制器（MVC）设计模式，这是Cocoa开发中的核心设计原则。最后，书中可能还会涉及测试、调试技巧以及最佳实践，帮助开发者编写高质量、可维护的代码。Objective-C 2.0的文档通常还会包含丰富的示例代码，以帮助读者更好地理解和应用所学知识。《Objective-C 2.0 编程语言》是一本全面而深入的教程，适合想要学习或提升Objective-C编程技能的开发者阅读。它不仅覆盖了语言本身，还涵盖了使用Objective-C开发苹果平台应用的整个流程。

Important: The sub-parts of the method name—of the selector—are not optional, nor can their order

be varied. "Named arguments" and "keyword arguments" often carry the implication that the arguments

to a method can vary at runtime, can have default values, can be in a different order, can possibly

have additional named arguments. This is not the case with Objective-C.

For all intents and purposes, an Objective-C method declaration is simply a C function that prepends

two additional arguments (see “How Messaging Works” (page 77)). This is different from the named

or keyword arguments available in a language like Python:

def func(a, b, NeatMode=SuperNeat, Thing=DefaultThing):

pass

where Thing (and NeatMode) might be omitted or might have different values when called.

Methods that take a variable number of arguments are also possible, though they’re somewhat rare.

Extra arguments are separated by commas after the end of the method name. (Unlike colons, the

commas aren’t considered part of the name.) In the following example, the imaginary makeGroup:

method is passed one required argument (group) and three that are optional:

[receiver makeGroup:group, memberOne, memberTwo, memberThree];

Like standard C functions, methods can return values. The following example sets the variable

isFilled to YES if myRect is drawn as a solid rectangle, or NO if it’s drawn in outline form only.

BOOL isFilled;

isFilled = [myRect isFilled];

Note that a variable and a method can have the same name.

One message expression can be nested inside another. Here, the color of one rectangle is set to the

color of another:

[myRect setPrimaryColor:[otherRect primaryColor]];

Objective-C 2.0 also provides a dot (.) operator that offers a compact and convenient syntax for

invoking an object’s accessor methods. This is typically used in conjunction with the declared properties

feature (see “Declared Properties” (page 45)), and is described in “The Dot Syntax” (page 55).

Sending Messages to nil

In Objective-C, it is valid to send a message to nil—it simply has no effect at runtime. There are several

patterns in Cocoa that take advantage of this fact. The value returned from a message to nil may

also be valid:

■

If the method returns an object, any pointer type, any integer scalar of size less than or equal to

sizeof(void*), a float, a double, a long double, or a long long, then a message sent to nil

returns 0.

■

If the method returns a struct, as defined by the Mac OS X ABI Function Call Guide to be returned

in registers, then a message sent to nil returns 0.0 for every field in the data structure. Other

struct data types will not be filled with zeros.

■

If the method returns anything other than the aforementioned value types the return value of a

message sent to nil is undefined.

Object Messaging

CHAPTER 1

Objects and Classes

The following code fragment illustrates valid use of sending a message to nil.

id anObjectMaybeNil = nil;

// this is valid

if ([anObjectMaybeNil methodThatReturnsADouble] == 0.0)

{

// implementation continues...

}

Note: The behavior of sending messages to nil changed with Mac OS X v10.5; for the behavior of

previous versions, see prior documentation.

The Receiver’s Instance Variables

A method has automatic access to the receiving object’s instance variables. You don’t need to pass

them to the method as arguments. For example, the primaryColor method illustrated above takes

no arguments, yet it can find the primary color for otherRect and return it. Every method assumes

the receiver and its instance variables, without having to declare them as arguments.

This convention simplifies Objective-C source code. It also supports the way object-oriented

programmers think about objects and messages. Messages are sent to receivers much as letters are

delivered to your home. Message arguments bring information from the outside to the receiver; they

don’t need to bring the receiver to itself.

A method has automatic access only to the receiver’s instance variables. If it requires information

about a variable stored in another object, it must send a message to the object asking it to reveal the

contents of the variable. The primaryColor and isFilled methods shown above are used for just

this purpose.

See “Defining a Class” (page 31) for more information on referring to instance variables.

Polymorphism

As the examples above illustrate, messages in Objective-C appear in the same syntactic positions as

function calls in standard C. But, because methods “belong to” an object, messages behave differently

than function calls.

In particular, an object can be operated on by only those methods that were defined for it. It can’t

confuse them with methods defined for other kinds of objects, even if another object has a method

with the same name. This means that two objects can respond differently to the same message. For

example, each kind of object sent a display message could display itself in a unique way. A Circle

and a Rectangle would respond differently to identical instructions to track the cursor.

This feature, referred to as polymorphism, plays a significant role in the design of object-oriented

programs. Together with dynamic binding, it permits you to write code that might apply to any

number of different kinds of objects, without you having to choose at the time you write the code

what kinds of objects they might be. They might even be objects that will be developed later, by other

programmers working on other projects. If you write code that sends a display message to an id

variable, any object that has a display method is a potential receiver.

Object Messaging 17

CHAPTER 1

Objects and Classes

Dynamic Binding

A crucial difference between function calls and messages is that a function and its arguments are

joined together in the compiled code, but a message and a receiving object aren’t united until the

program is running and the message is sent. Therefore, the exact method that’s invoked to respond

to a message can only be determined at runtime, not when the code is compiled.

The precise method that a message invokes depends on the receiver. Different receivers may have

different method implementations for the same method name (polymorphism). For the compiler to

find the right method implementation for a message, it would have to know what kind of object the

receiver is—what class it belongs to. This is information the receiver is able to reveal at runtime when

it receives a message (dynamic typing), but it’s not available from the type declarations found in

source code.

The selection of a method implementation happens at runtime. When a message is sent, a runtime

messaging routine looks at the receiver and at the method named in the message. It locates the

receiver’s implementation of a method matching the name, “calls” the method, and passes it a pointer

to the receiver’s instance variables. (For more on this routine, see “How Messaging Works” (page

77).)

The method name in a message thus serves to “select” a method implementation. For this reason,

method names in messages are often referred to as selectors.

This dynamic binding of methods to messages works hand-in-hand with polymorphism to give

object-oriented programming much of its flexibility and power. Since each object can have its own

version of a method, a program can achieve a variety of results, not by varying the message itself,

but by varying just the object that receives the message. This can be done as the program runs; receivers

can be decided “on the fly” and can be made dependent on external factors such as user actions.

When executing code based upon the Application Kit, for example, users determine which objects

receive messages from menu commands like Cut, Copy, and Paste. The message goes to whatever

object controls the current selection. An object that displays text would react to a copy message

differently from an object that displays scanned images. An object that represents a set of shapes

would respond differently from a Rectangle. Since messages don’t select methods (methods aren’t

bound to messages) until runtime, these differences are isolated in the methods that respond to the

message. The code that sends the message doesn’t have to be concerned with them; it doesn’t even

have to enumerate the possibilities. Each application can invent its own objects that respond in their

own way to copy messages.

Objective-C takes dynamic binding one step further and allows even the message that’s sent (the

method selector) to be a variable that’s determined at runtime. This is discussed in the section “How

Messaging Works” (page 77).

Classes

An object-oriented program is typically built from a variety of objects. A program based on the Cocoa

frameworks might use NSMatrix objects, NSWindow objects, NSDictionary objects, NSFont objects,

NSText objects, and many others. Programs often use more than one object of the same kind or

class—several NSArray objects or NSWindow objects, for example.

Classes

CHAPTER 1

Objects and Classes

In Objective-C, you define objects by defining their class. The class definition is a prototype for a kind

of object; it declares the instance variables that become part of every member of the class, and it defines

a set of methods that all objects in the class can use.

The compiler creates just one accessible object for each class, a class object that knows how to build

new objects belonging to the class. (For this reason it’s traditionally called a “factory object.”) The

class object is the compiled version of the class; the objects it builds are instances of the class. The

objects that do the main work of your program are instances created by the class object at runtime.

All instances of a class have the same set of methods, and they all have a set of instance variables cut

from the same mold. Each object gets its own instance variables, but the methods are shared.

By convention, class names begin with an uppercase letter (such as “Rectangle”); the names of instances

typically begin with a lowercase letter (such as “myRect”).

Inheritance

Class definitions are additive; each new class that you define is based on another class from which it

inherits methods and instance variables. The new class simply adds to or modifies what it inherits.

It doesn’t need to duplicate inherited code.

Inheritance links all classes together in a hierarchical tree with a single class at its root. When writing

code that is based upon the Foundation framework, that root class is typically NSObject. Every class

(except a root class) has a superclass one step nearer the root, and any class (including a root class)

can be the superclass for any number of subclasses one step farther from the root. Figure 1-1 illustrates

the hierarchy for a few of the classes used in the drawing program.

Figure 1-1 Some Drawing Program Classes

Image

Text

NSObject

Graphic

Shape

Line

Circle

Rectangle

Square

This figure shows that the Square class is a subclass of the Rectangle class, the Rectangle class is a

subclass of Shape, Shape is a subclass of Graphic, and Graphic is a subclass of NSObject. Inheritance

is cumulative. So a Square object has the methods and instance variables defined for Rectangle, Shape,

Graphic, and NSObject, as well as those defined specifically for Square. This is simply to say that a

Square object isn’t only a Square, it’s also a Rectangle, a Shape, a Graphic, and an NSObject.

Every class but NSObject can thus be seen as a specialization or an adaptation of another class. Each

successive subclass further modifies the cumulative total of what’s inherited. The Square class defines

only the minimum needed to turn a Rectangle into a Square.

Classes 19

CHAPTER 1

Objects and Classes

When you define a class, you link it to the hierarchy by declaring its superclass; every class you create

must be the subclass of another class (unless you define a new root class). Plenty of potential

superclasses are available. Cocoa includes the NSObject class and several frameworks containing

definitions for more than 250 additional classes. Some are classes that you can use “off the

shelf”—incorporate into your program as is. Others you might want to adapt to your own needs by

defining a subclass.

Some framework classes define almost everything you need, but leave some specifics to be implemented

in a subclass. You can thus create very sophisticated objects by writing only a small amount of code,

and reusing work done by the programmers of the framework.

The NSObject Class

NSObject is a root class, and so doesn’t have a superclass. It defines the basic framework for Objective-C

objects and object interactions. It imparts to the classes and instances of classes that inherit from it

the ability to behave as objects and cooperate with the runtime system.

A class that doesn’t need to inherit any special behavior from another class should nevertheless be

made a subclass of the NSObject class. Instances of the class must at least have the ability to behave

like Objective-C objects at runtime. Inheriting this ability from the NSObject class is much simpler

and much more reliable than reinventing it in a new class definition.

Note: Implementing a new root class is a delicate task and one with many hidden hazards. The class

must duplicate much of what the NSObject class does, such as allocate instances, connect them to

their class, and identify them to the runtime system. For this reason, you should generally use the

NSObject class provided with Cocoa as the root class. For more information, see the Foundation

framework documentation for the NSObject class and the NSObject protocol.

Inheriting Instance Variables

When a class object creates a new instance, the new object contains not only the instance variables

that were defined for its class but also the instance variables defined for its superclass and for its

superclass’s superclass, all the way back to the root class. Thus, the isa instance variable defined in

the NSObject class becomes part of every object. isa connects each object to its class.

Figure 1-2 shows some of the instance variables that could be defined for a particular implementation

of Rectangle, and where they may come from. Note that the variables that make the object a Rectangle

are added to the ones that make it a Shape, and the ones that make it a Shape are added to the ones

that make it a Graphic, and so on.

Classes

CHAPTER 1

Objects and Classes

剩余148页未读，继续阅读

doufeif

粉丝: 0
资源: 7

Objective-C 2.0编程语言详解

The Objective-C 2.0 Programming Language

Objective-C 2.0编程语言（Apple Inc.）The Objective-C 2.0 Programming Language (Apple Inc.)

objective-c基础教程 第2版 pdf

programming in objective-c中文

objective-c 程序设计(第六版)参考资料

objective-c 集成 lua

Visual Studio Code如何运行objective-c

在iOS objective-c中如何将点击事件传给flutter层，如何flutter层如何传回给objective-c层

objective-c的mock类

objective-c是什么？

最新资源

objective-c基础教程第2版 pdf