Objective-C入门 简介Cocoa框架
Cocoa Framework简称Cocoa，它是Mac OS X上的快速应用程序开发(RAD, Rapid Application Development)框架，一个高度面向对象的(Object Oriented)开发框架。无论您是资深的Mac开发人员，还是即将踏入Mac开发世界的新新人类，Cocoa都是您开发应用程序的瑞士军刀、乐高积木，它是您构建Mac OS X应用程序最强大、最高效的工具。值得一提的是，苹果公司之所以能够开发出众多顶级软件，其实也正是因为有着Cocoa这个秘密武器。Cocoa是Mac OS X上原生支持的应用程序开发框架，苹果公司强烈推荐所有Mac开发人员使用。
骨灰话题：Hello World!
相信对于任何一个开发人员，Hello World!都应该是个熟悉无比的东西。那么，Cocoa的Hello World!程序您看得懂么?
import
int main (int argc, const char * argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
NSLog(@"Hello, World!");
[pool drain];
return 0;
} Hmm... 看不明白?不再仔细看看?还是看不明白?
不论您是否看得明白，首先，和绝大多数您所见过的C程序一样，任何一个Cocoa应用程序都有一个主函数：
int main(int argc, const char * argv[])
主函数是应用程序的主入口，也是一切开始和结束的地方。是的，没错!从表面上看，这些代码和常见的C程序的代码没有什么区别，而且事实上，它们和C程序的代码的的确确没有什么区别。
接下来你该问我，那什么是Foundation?Foundation.h里装的又是什么?什么是NSAutoreleasePool?那些中括号又是什么?...... 别急，在后续的几章里我们会慢慢把这么多陌生的面孔熟悉起来，当然我也可以现在就大致的解释一下：
Foundation全称Foundation Framework，是Cocoa的一个子开发框架。Foundation里包含了Cocoa中最基本的一些类，它们在一个Mac应用程序中通常负责对象管理、内存管理、容器等相关数据结构的操作。Foundation.h是Foundation的头文件，一旦引入了这个头文件，我们就可以在自己的程序里使用任何在Foundation里声明的类。例如在上述代码中，NSAutoreleasePool就是Foundation中声明的一个类，它为应用程序提供可控制的延迟对象释放的内存管理。至于那些方括号，它们是Objective-C里最最基本的语法成分，一对方括号中间的内容表示对对象(或类)进行一次方法的调用。
如果您没有听明白，请不要惊慌失措，咱们在下面的几章里慢慢说。另外，Cocoa的国际音标是['koukou]希望大家能把这个单词的音读对。
我其实很C
在使用Cocoa进行应用程序开发的时候，Objective-C是我们首选的语言。(当然，Cocoa也通过官方、第三方等途径，构建了Cocoa-Ruby、Cocoa-Python等编程语言上的桥接，使无论是来自Ruby还是Python世界的开发人员能够使用他们熟悉的语言快速上手。)不过在这里，我们还是要首推Objective-C作为一个Cocoa程序的开发语言，原因有二：
其一、Objective-C实际上是C的超集。
Objective-C的运行环境库(Runtime Library)完全是由C编写的，因此任何一个Objective-C消息派发(Message Dispatching)，都会被替换成Objective-C运行环境中的某个或某几个C函数的调用。这种机制为Objective-C带来了高效的消息派发和对C代码完全原生的兼容。
其二、整个Cocoa Framework都是由Objective-C/C实现的。
因此在开发一个Cocoa应用程序的时候，Objective-C是我们不二的选择。
当我们说到“Objective-C”的时候，尽管编程模型和C不同，尽管语法看似有些奇怪，但事实我们所讨论的依然还是C语言。因为Objective-C确实是C，说的简单些：
Objective-C就是拥有一个面向对象层(Object Oriented Layer)的C。而Objective-C正是通过从Smalltalk进化而来的这种语法，实现了对这个面向对象层的支持。因此如果您正在使用Objective-C开发一个Cocoa应用程序，同时又希望在某些代码的某些位置插入一些C代码，那就请放心大胆的继续吧!
设计模式深入骨髓：无处不在的MVC
在传统的开发模式中，我们很容易陷入“胶水代码”的陷阱里。所谓的“胶水代码”，顾名思义，就是仅仅用来保持用户界面数据、状态同步的函数调用的集合体。这些函数调用扯不断，理还乱，并且使代码变的非常冗长、易出错、不易维护。
为了解决这个问题，Cocoa提供了多个内部机制：Key-Value Coding(KVC)、Key-Value Observing(KVO)、Key-Value Binding(KVB)。这些机制通过规定了一组通用的Cocoa命名法则、调用规则等，实现了如下功能：
1. 使用一对高度规范化的访问方法，获取以及设置任何对象的任何属性的值(所谓的属性既可以是个实实在在的成员变量，也可以是通过一对成员方法所抽象出的该对象的一个性质)。
2. 通过继承一个特定的方法，并且指定希望监视的对象及希望监视的属性名称，就能在该对象的指定属性的值发生改变时，得到一个“通知”(尽管这不是一个真正意义上的通知)，并且得到相关属性的值的变化(原先的值和改变后的新值)。
3. 通过一个简单的函数调用，使一个视图对象的一个指定属性随时随地都和一个控制器对象或模型对象的一个指定属性保持同步。
一个开发者可以利用这些功能，将自己创建的类写的很范化、很通用，然后通过KVB将多个视图“绑定”到一个或多个控制器上，再将控制器绑定到最底层的数据模型上。这样一来，任何一个视图上的改变都会通过KVC被“压”到控制器里，然后又通过KVC从控制器“压”到数据模型里。当数据模型中的值发生改变时，一个或多个控制器又会得到KVO的“通知”，接着只要被绑定了的视图又会得到这一个或多个控制器的KVO“通知”。这样以来，开发者只需要在适当的时候告诉Cocoa，什么对象的什么值该和什么对象的什么值绑定，就可以了，其余数据更新、格式化等工作Cocoa都会替你完成。
是不是很方便呢?
Easy Life之一：内存管理
内存管理是令很多开发人员头大的问题，在Cocoa中，内存管理是通过引用计数器模型完成的。
Cocoa中的每个对象都拥有一个引用计数器，用来维持自己的生命周期。每当一个对象需要“使用”或“占有”另一个对象的时候，它通过向该对象发送一个retain消息来对该对象的引用计数器进行自增，而当它不再需要(或使用完)该对象的时候，它通过向该对象发送一个release消息来对该对象的引用计数器进行自减。当一个对象的引用计数器自减到零时，该对象就会被释放。
下面我们来看一个例子，例如：
NSString *aString = [[NSString alloc] initWithString:@"This is a demo."];
这段代码会创建一个NSString对象，并对其进行初始化。当一个对象被创建的时候，它的引用计数器会被设为1。因此当您不再需要该对象，只要直接对其发送release消息，它就会被直接析构。当您有别的代码块也需要使用这个NSString时，您可以对这个NSString对象调用一次retain来增加它的引用计数器：
[aString retain]; 这个时候，它的引用计数器值就是2了。当您使用完该对象时，如果您对该对象调用过retain，那就应该“对称”地调用一次release。这时一种基本地编程规范，我将它称为“谁retain，谁release”。
[aString release];
调用完以后，引用计数器再次回到1。最后，当我们彻底不需要这个对象的时候，我们可以这么做：
[aString release]; aString = nil;
上两行代码中，第一句会负责将这个NSString对象析构，第二句会负责将原来指向这个NSString对象的指针(NSString *aString)“归零”，因为“野指针”随时可能造成您程序的异常及崩溃。
听着是不是挺简单?
当然也有稍微复杂一些的情况，话说一开始我们有提到一个叫作NSAutoreleasePool的类吧?NSAutoreleasePool是Cocoa内存管理机制里很重要的一个环节。我们在本着“谁retain，谁release”的对象使用的大前提下，经常会碰到这么一个问题，那就是我们希望返回一个在局部中创建的对象：
(NSString)demoString
{
NSString *result = [[NSString alloc] initWithString:@"This is a demo."];
return result;
} 在“谁retain，谁release”的原则下，上面的代码显然只负责了retain(alloc调用等效于retain)，但是没有负责release，因此这么写可能会造成内存泄露，因为调用这个方法(或这个API)的代码段并不知道究竟是否需要负责释放这个方法(或这个API)的返回值。
但是如果我们将它直接release了：
(NSString)demoString
{
NSString *result = [[NSString alloc] initWithString:@"This is a demo."];
[result release];
return result;
} 那return的将会是个“野指针”(或者如果你干的足够干净，return的是个零指针)，不是我们需要的值。因此我们需要一个能够延迟释放，并且能够自动释放的机制。于是，人们发明了名叫NSAutoreleasePool的又一个轮子，而代码则变成了这个样子：
(NSString)demoString
{
NSString *result = [[NSString alloc] initWithString:@"This is a demo."];
[result autorelease];
return result;
} 在对一个对象发送了autorelease之后，这个对象不会被立即释放，而是被“登记”到了离它最近的一个NSAutoreleasePool对象上。当该NSAutoreleasePool被清空或释放的时候，这个“登记”了的对象才会被真正发送一个release消息。
Easy Life之二：容器
容器是让多数程序员又爱又恨的东西。在Cocoa中，容器是如此的简单易用以至于您一旦用过，就会对它们“爱不释手”。Cocoa中的容器类主要有这么几个：NSString、NSArray、NSDictionary、NSSet和NSIndexSet等，它们都是Foundation Framework的一部分。
为什么人们会对Cocoa的容器“爱不释手”呢?
原因一：NSArray、NSDictionary、NSSet都不强制其内部元素类型的一致性。举个简单的例子：
NSString *aString = [NSString stringWithString:@"This is a demo."];
NSNumber *aNumber = [NSNumber numberWithInteger:0];
NSArray *anArray = [[NSArray alloc] initWithObjects:aString, aNumber, nil];
在上述例子中，我们首先建立了一个NSString对象，然后又建立了一个NSNumber对象，最后我们将这两个NSString和NSNumber对象都“塞”到了一个NSArray对象中。
有够爽吧?连想都别想，什么东西都能往里面装(基本类型、结构体除外)!
原因二：容器类的“可修改”和“不可修改”
上面我们展示的NSString、NSArray、NSDictionary、NSSet以及NSIndexSet等，都是容器的“不可修改”的版本。所谓的“不可修改”，指的是这个容器一旦被创建以后，我们就不可以通过代码修改它的集合。那如果我们需要修改(例如添加、删除、替换)这些容器的元素，该怎么办呢?
Cocoa中几乎所有的容器类，都提供了另外一个“可修改”的版本。例如：继承自NSString的NSMutableString、继承自NSArray的NSMutableArray、继承自NSDictionary的NSMutableDictioanry、继承自NSSet的NSMutableSet以及继承自NSIndexSet的NSMutableIndexSet等。这些“可修改”的版本提供了简单直观的方法，用来修改其内部的元素。例如：
NSString *aString = [NSString stringWithString:@"This is a demo."]; NSNumber *aNumber = [NSNumber numberWithInteger:0]; NSMutableArray *aMutableArray = [NSMutableArray array]; [aMutableArray addObject:aString]; [aMutableArray addObject:aNumber]; [aMutableArray removeObjectAtIndex:0]; [aMutableArray removeAllObjects];
在上述代码中，第一、二行建立了一个NSString对象和一个NSNumber对象。第三行建立了一个NSMutableArray对象(也就是一个“可修改”的NSArray对象)。第四、五行通过-addObject:方法分别将第一、二行建立的NSString对象和NSNumber对象加入了这个“可修改”的NSArray里。第六行则是根据我们给定的索引号0，删除了数组中的第一个元素。第七行的-removeAllObjects最后一口气将数组中存在的所有元素统统删除(置空数组)。
是不是感觉一切都变的简单了许多呢?
那就赶快拿起Xcode，开始享受Cocoa编程所带来的快乐吧!
粉丝看Cocoa
“Simple things simple, complex things possible.”(简单的事情更简单，复杂的事情也成为可能。)
“C++ is to C as Lung Cancer is to Lang.”(C++之于C正如肺癌之于肺。)
“We thought we would see how hard it would be to switch the code we had to use Cocoa Bindings. We rewrote everything in a day or two - I think we deleted over a thousand lines of code that just wasn't needed any more.”(当初我们认为将原有的代码迁移到使用Cocoa Bindings的代码是一件非常艰苦的活。但事实上我们在仅仅一两天内就重写了所有的东西——我想我们删除了有超过一千行因为Cocoa Bindings而不再需要了的代码。)
“Without Cocoa Bindings, it would have taken another four or five months, maybe more, to finish Delicious Library.”(要是没有Cocoa Bindings，完成Delicious Library将要再花上四、五个月的时间，或许更长。)