精通Objective-C：Mac版第2版指南

5星 · 超过95%的资源需积分: 9 82 浏览量更新于2024-07-27 1 收藏 16.45MB PDF 举报

"Learn Objective C On The Mac 2nd Edition" 本书是一本关于Objective-C编程的教程，特别针对Mac平台的iOS开发。Objective-C是一种基于C语言的面向对象编程语言，是苹果公司开发的iOS和macOS操作系统的主要编程语言。尽管初学者可能会觉得Objective-C相比其他语言学习起来有些困难，但它是深入理解并开发iOS应用的基础。本书内容分为多个章节，逐步引导读者掌握Objective-C的关键概念和技术： 1. **Chapter 1: Hello** - 开篇介绍Objective-C的基本概念，包括如何编写第一个简单的“Hello, World”程序，帮助读者建立初步的编程环境。 2. **Chapter 2: Extensions to C** - 讨论Objective-C对C语言的扩展，如消息传递机制，这是Objective-C的核心特性。 3. **Chapter 3: Introduction to Object-Oriented Programming** - 详细介绍面向对象编程的基础，包括类、对象、继承等概念。 4. **Chapter 4: Inheritance** - 深入探讨继承，这是面向对象编程中的一个重要概念，允许子类继承父类的属性和方法。 5. **Chapter 5: Composition** - 讲解组合，它是另一种实现代码重用的方式，通过将多个对象组合成一个更复杂对象。 6. **Chapter 6: Source File Organization** - 阐述源代码文件的组织结构，这对于大型项目的管理至关重要。 7. **Chapter 7: More About Xcode** - 介绍苹果的集成开发环境Xcode，包括其界面、工具和工作流程，帮助开发者高效地构建应用。 8. **Chapter 8: A Quick Tour of the Foundation Kit** - 快速浏览Foundation框架，它是iOS和macOS开发的基础，提供了大量实用的类和工具。 9. **Chapter 9: Memory Management** - 解释内存管理，包括自动引用计数（ARC）和手动内存管理的原则。 10. **Chapter 10: Object Initialization** - 讨论对象初始化过程，以及如何正确地创建和初始化对象。 11. **Chapter 11: Properties** - 介绍Objective-C的属性特性，包括声明、访问器和存储策略。 12. **Chapter 12: Categories** - 解释类别，它允许向已有的类添加方法，而无需子类化。 13. **Chapter 13: Protocols** - 讨论协议，一种接口定义机制，用于实现多态性。 14. **Chapter 14: Blocks and Concurrency** - 介绍Block（代码块）和并发编程，这对于优化性能和实现异步操作至关重要。 15. **Chapter 15: Introduction to UIKit** - 引导读者了解UIKit框架，它是iOS应用程序用户界面的主要构建块。 16. **Chapter 16: Introduction to the ApplicationKit** - 对于macOS开发，介绍ApplicationKit框架，提供构建桌面应用的工具。 17. **Chapter 17: File Loading and Saving** - 讲解文件的加载和保存，包括数据持久化的策略和方法。 18. **Chapter 18: Key-Value Coding** - 介绍键值编码，一种间接访问对象属性的机制，常用于数据绑定和自动化。通过这些章节的学习，读者可以全面掌握Objective-C编程基础，并具备开发iOS和macOS应用程序的能力。此外，书中还包含了关于作者、技术审阅者的信息，以及对读者如何有效利用本书的建议，方便读者随时查阅和学习。

Chapter 2: Extensions to C12

Deconstructing Hello Objective-C

Here, again, are the contents of main.m:

#import <Foundation/Foundation.h>

int main (int argc, const char *argv[])

{

NSLog (@"Hello, Objective-C!");

return (0);

} // main

Xcode uses the .m extension to indicate a ﬁle that holds Objective-C code and will be processed

by the Objective-C compiler. File names ending in .c are handled by the C compiler, and .cpp

ﬁles are the province of the C++ compiler. (In Xcode, all this compiling is handled by the LLVM

compiler by default), a single compiler that understands all three variations of the language.)

The main ﬁle contains two lines of code that should be familiar to you already if you know

plain C: the declaration of main() and the return (0) statement at the end. Remember that

Objective-C really is C at heart, and the syntax for declaring main() and returning a value is the

same as in C. The rest of the code looks slightly different from regular C. For example, what is

that wacky #import thing? To ﬁnd out, read on!

Note The .m extension originally stood for “messages” when Objective-C was ﬁrst introduced,

referring to a central feature of Objective-C that we’ll talk about in future chapters. Nowadays, we just

call them “dot-m ﬁles.”

That Wacky #import Thing

Just like C, Objective-C uses header ﬁles to hold the declarations of elements such as structs,

symbolic constants, and function prototypes. In C, you use the #include statement to inform

the compiler that it should consult a header ﬁle for some deﬁnitions. You can use #include in

Objective-C programs for the same purpose, but you probably never will. Instead, you’ll use

#import, like this:

#import <Foundation/Foundation.h>

#import is a feature provided by the compiler that Xcode uses, which is what Xcode uses when

you’re compiling Objective-C, C, and C++ programs. #import guarantees that a header ﬁle will

be included only once, no matter how many times the #import directive is actually seen for

that ﬁle.

Note In C, programmers typically use a scheme based on the #ifdef directive to avoid the situation

where one ﬁle includes a second ﬁle, which then, recursively, includes the ﬁrst.

In Objective-C, programmers use #import to accomplish the same thing.

Chapter 2: Extensions to C

The #import <Foundation/Foundation.h> statement tells the compiler to look at the

Foundation.h header ﬁle in the Foundation framework.

Introducing Frameworks

What’s a framework? We’re glad you asked. A framework is a collection of parts—header

ﬁles, libraries, images, sounds, and more—collected together into a single unit. Apple ships

technologies such as Cocoa, Carbon, QuickTime, and OpenGL as sets of frameworks. Cocoa

consists of a pair of frameworks, Foundation and Application Kit (also known as AppKit), along

with a suite of supporting frameworks, including Core Animation and Core Image, which add all

sorts of cool stuff to Cocoa.

The Foundation framework handles features found in the layers beneath the user interface, such

as data structures and communication mechanisms. All the programs in this book are based on

the Foundation framework.

Note Once you ﬁnish this book, your next step along the road to becoming a Cocoa guru is to master

Cocoa’s Application Kit, which contains Cocoa’s high-level features: user interface elements, printing,

color and sound management, AppleScript support, and so on. To ﬁnd out more, check out Learn

Cocoa on the Mac by Jack Nutting, David Mark, and Jeff LaMarche (Apress 2010).

Each framework is a signiﬁcant collection of technology, often containing dozens or even

hundreds of header ﬁles. Each framework has a master header ﬁle that includes all the

framework’s individual header ﬁles. By using #import on the master header ﬁle, you have access

to all the framework’s features.

The header ﬁles for the Foundation framework take up nearly a megabyte of disk storage and

contain more than 14,000 lines of code, spread across over a hundred ﬁles. When you include

the master header ﬁle with #import <Foundation/Foundation.h>, you get that whole vast

collection. You might think wading through all that text for every ﬁle would take the compiler a lot

of time, but Xcode is smart: it speeds up the task by using precompiled headers, a compressed

and digested form of the header that’s loaded quickly when you #import it.

If you’re curious about which headers are included with the Foundation framework, you can

peek inside its Headers directory (/System/Library/Frameworks/Foundation.framework/Headers/).

You won’t break anything if you browse the ﬁles in there; just don’t remove or change anything.

NSLog() and @"strings"

Now that we have used #import on the master header ﬁle for the Foundation framework, you’re

ready to write code that takes advantage of some Cocoa features. The ﬁrst (and only) real line of

code in Hello Objective-C uses the NSLog() function, like so:

NSLog (@"Hello, Objective-C!");

Chapter 2: Extensions to C14

This prints “Hello, Objective-C!” to the console. If you’ve used C at all, you have undoubtedly

encountered printf() in your travels. NSLog() is a Cocoa function that works very much like printf().

Just like printf(), NSLog() takes a string as its ﬁrst argument. This string can contain format

speciﬁers (such as %d), and the function takes additional parameters that match the format

speciﬁers. printf() plugs these extra parameters into the string before it gets printed.

As we’ve said before, Objective-C is just C with a little bit of special sauce, so you’re welcome to

use printf() instead of NSLog() if you want. We recommend NSLog(), however, because it adds

features such as time and date stamps, as well as automatically appending the newline ('\n')

character for you.

The NS Preﬁx: A Prescription Against Name Collisions

You might be thinking that NSLog() is kind of a strange name for a function. What is that “NS”

doing there? It turns out that Cocoa preﬁxes all its function, constant, and type names with

“NS”. This preﬁx tells you the function comes from Cocoa instead of some other toolkit.

The preﬁx helps prevent name collisions, big problems that result when the same identiﬁer is

used for two different things. If Cocoa had named this function Log(), there’s a good chance

the name would clash with a Log() function created by some innocent programmer somewhere.

When a program containing Log() is built with Cocoa included, Xcode complains that Log() is

deﬁned multiple times, and sadness results.

Now that you have an idea why a preﬁx is a good idea, you might wonder about the speciﬁc

choice: why “NS” instead of “Cocoa,” for example? Well, the “NS” preﬁx dates back from the

time when the toolkit was called NextSTEP and was the product of NeXT Software (formerly

NeXT, Inc.), which was acquired by Apple in 1996. Rather than break compatibility with code

already written for NextSTEP, Apple just continued to use the “NS” preﬁx. It’s a historical

curiosity now, like your appendix.

Cocoa has staked its claim on the “NS” preﬁx, so obviously, you should not preﬁx any of your

own variables or function names with “NS”. If you do, you will confuse the readers of your code,

making them think your stuff actually belongs to Cocoa. Also, your code might break in the

future if Apple happens to add a function to Cocoa with the same name as yours. There is no

centralized preﬁx registry, so you can pick your own preﬁx. Many people preﬁx names with their

initials or company names. To make our examples a little simpler, we won’t use a preﬁx for the

code in this book.

NSString: Where it’s @

Let’s take another look at that NSLog() statement: NSLog (@"Hello, Objective-C!");

Did you notice the at sign before the string? It’s not a typo that made it past our vigilant editors.

The at sign is one of the features that Objective-C adds to standard C. A string in double quotes

preceded by an at sign means that the quoted string should be treated as a Cocoa NSString

element.

So what’s an NSString element? Peel the “NS” preﬁx off the name and you see a familiar term:

“String.” You already know that a string is a sequence of characters, usually human-readable, so

you can probably guess (correctly) that an NSString is a sequence of characters in Cocoa.

Chapter 2: Extensions to C16

Here’s another cool fact about NSString: the name itself highlights one of the nice features of

Cocoa. Most Cocoa elements are named in a very straightforward manner, striving to describe

the features they implement. For instance, NSArray provides arrays; NSDateFormatter helps you

format dates in different ways; NSThread gives you tools for multithreaded programming; and

NSSpeechSynthesizer lets you hear speech.

Now, we’ll get back to stepping through our little program. The last line of the program is the

return statement that ends the execution of main() and ﬁnishes the program:

return (0);

The zero value returned says that our program completed successfully. This is just the way

return statements work in C.

Congratulations, again! You’ve just written, compiled, run, and dissected your ﬁrst Objective-C

program.

Are You the Boolean Type?

Many languages have a Boolean type, which is, of course, a fancy term for variables that store

true and false values. Objective-C is no exception.

C has a Boolean data type, bool, which can take on the values true and false. Objective-C

provides a similar type, BOOL, which can have the values YES and NO. Objective-C’s BOOL type,

incidentally, predates C’s bool type by over a decade. The two different Boolean types can

coexist in the same program, but when you’re writing Cocoa code, you’ll be using BOOL.

Note BOOL in Objective-C is actually just a type deﬁnition (typedef) for the signed character type

(signed char), which uses 8 bits of storage. YES is deﬁned as 1 and NO as 0 (using #deﬁne).

Objective-C doesn’t treat BOOL as a true Boolean type that can hold only YES or NO values. The compiler

considers BOOL to be an 8-bit number, and the values of YES and NO are just a convention. This causes a

subtle gotcha: if you inadvertently assign an integer value that’s more than 1 byte long, such as a short or

an int value, to a BOOL variable, only the lowest byte is used for the value of the BOOL. If that byte happens

to be zero (as with 8960, which in hexadecimal is 0x2300), the BOOL value will be zero, the NO value.

Mighty BOOL in Action

To show mighty BOOL in action, we move on to our next project, 02.02 - BOOL Party, which

compares pairs of integers to see if they’re different. Aside from main(), the program deﬁnes

two functions. The ﬁrst, areIntsDifferent(), takes two integer values and returns a BOOL: YES if

the integers are different and NO if they are the same. A second function, boolString(), takes a

BOOL parameter and returns the string @"YES" if the parameter is YES and @"NO" if the parameter

is NO. This function is handy to have around when you want to print out a human-readable

representation of BOOL values. main() uses these two functions to compare integers and print out

the results.

剩余370页未读，继续阅读

身份认证购VIP最低享 7 折!

30元优惠券

houjoyo

粉丝: 0

精通Objective-C：Mac版第2版指南

Mac上Objective-C入门经典：全面解析与实践

iOS开发新手入门：掌握Objective-C与iOS 7 SDK

精通Objective-C：Mac与iOS平台编程指南(第2版)

Learn Objective-c on the Mac 2nd edition

Learn Objective-C On The Mac, 2nd Edition

Apress Learn Objective-C on the Mac 2nd Edition.pdf

Learn.Objective-C.on.the.Mac.2nd.Edition.SourceCode

Learn Objective-C on the Mac For OS X and iOS 2nd Edition

Learn Swift 2 on the Mac 2nd 第2版 无水印pdf 0分

Learn Java for Android Development, 2nd Edition

最新资源

Learn Swift 2 on the Mac 2nd 第2版无水印pdf 0分