Cocoa
骨灰话题:Hello
相信对于任何一个开发人员,Hello
import
int
NSAutoreleasePool
NSLog(@"Hello,
[pool
return
}
Hmm...
不论您是否看得明白,首先,和绝大多数您所见过的C程序一样,任何一个Cocoa应用程序都有一个主函数:
int
主函数是应用程序的主入口,也是一切开始和结束的地方。是的,没错!从表面上看,这些代码和常见的C程序的代码没有什么区别,而且事实上,它们和C程序的代码的的确确没有什么区别。
接下来你该问我,那什么是Foundation?Foundation.h里装的又是什么?什么是NSAutoreleasePool?那些中括号又是什么?......
Foundation全称Foundation
如果您没有听明白,请不要惊慌失措,咱们在下面的几章里慢慢说。另外,Cocoa的国际音标是['koukou]希望大家能把这个单词的音读对。
我其实很C
在使用Cocoa进行应用程序开发的时候,Objective-C是我们首选的语言。(当然,Cocoa也通过官方、第三方等途径,构建了Cocoa-Ruby、Cocoa-Python等编程语言上的桥接,使无论是来自Ruby还是Python世界的开发人员能够使用他们熟悉的语言快速上手。)不过在这里,我们还是要首推Objective-C作为一个Cocoa程序的开发语言,原因有二:
其一、Objective-C实际上是C的超集。
Objective-C的运行环境库(Runtime
其二、整个Cocoa
因此在开发一个Cocoa应用程序的时候,Objective-C是我们不二的选择。
当我们说到“Objective-C”的时候,尽管编程模型和C不同,尽管语法看似有些奇怪,但事实我们所讨论的依然还是C语言。因为Objective-C确实是C,说的简单些:
Objective-C就是拥有一个面向对象层(Object
设计模式深入骨髓:无处不在的MVC
在传统的开发模式中,我们很容易陷入“胶水代码”的陷阱里。所谓的“胶水代码”,顾名思义,就是仅仅用来保持用户界面数据、状态同步的函数调用的集合体。这些函数调用扯不断,理还乱,并且使代码变的非常冗长、易出错、不易维护。
为了解决这个问题,Cocoa提供了多个内部机制:Key-Value
1.
2.
3.
一个开发者可以利用这些功能,将自己创建的类写的很范化、很通用,然后通过KVB将多个视图“绑定”到一个或多个控制器上,再将控制器绑定到最底层的数据模型上。这样一来,任何一个视图上的改变都会通过KVC被“压”到控制器里,然后又通过KVC从控制器“压”到数据模型里。当数据模型中的值发生改变时,一个或多个控制器又会得到KVO的“通知”,接着只要被绑定了的视图又会得到这一个或多个控制器的KVO“通知”。这样以来,开发者只需要在适当的时候告诉Cocoa,什么对象的什么值该和什么对象的什么值绑定,就可以了,其余数据更新、格式化等工作Cocoa都会替你完成。
是不是很方便呢?
Easy
内存管理是令很多开发人员头大的问题,在Cocoa中,内存管理是通过引用计数器模型完成的。
Cocoa中的每个对象都拥有一个引用计数器,用来维持自己的生命周期。每当一个对象需要“使用”或“占有”另一个对象的时候,它通过向该对象发送一个retain消息来对该对象的引用计数器进行自增,而当它不再需要(或使用完)该对象的时候,它通过向该对象发送一个release消息来对该对象的引用计数器进行自减。当一个对象的引用计数器自减到零时,该对象就会被释放。
下面我们来看一个例子,例如:
NSString
这段代码会创建一个NSString对象,并对其进行初始化。当一个对象被创建的时候,它的引用计数器会被设为1。因此当您不再需要该对象,只要直接对其发送release消息,它就会被直接析构。当您有别的代码块也需要使用这个NSString时,您可以对这个NSString对象调用一次retain来增加它的引用计数器:
[aString
[aString
调用完以后,引用计数器再次回到1。最后,当我们彻底不需要这个对象的时候,我们可以这么做:
[aString
aString
上两行代码中,第一句会负责将这个NSString对象析构,第二句会负责将原来指向这个NSString对象的指针(NSString
听着是不是挺简单?
当然也有稍微复杂一些的情况,话说一开始我们有提到一个叫作NSAutoreleasePool的类吧?NSAutoreleasePool是Cocoa内存管理机制里很重要的一个环节。我们在本着“谁retain,谁release”的对象使用的大前提下,经常会碰到这么一个问题,那就是我们希望返回一个在局部中创建的对象:
(NSString)demoString
{
NSString
return
}
在“谁retain,谁release”的原则下,上面的代码显然只负责了retain(alloc调用等效于retain),但是没有负责release,因此这么写可能会造成内存泄露,因为调用这个方法(或这个API)的代码段并不知道究竟是否需要负责释放这个方法(或这个API)的返回值。
但是如果我们将它直接release了:
(NSString)demoString
{
NSString
[result
return
}
那return的将会是个“野指针”(或者如果你干的足够干净,return的是个零指针),不是我们需要的值。因此我们需要一个能够延迟释放,并且能够自动释放的机制。于是,人们发明了名叫NSAutoreleasePool的又一个轮子,而代码则变成了这个样子:
(NSString)demoString
{
NSString
[result
return
}
在对一个对象发送了autorelease之后,这个对象不会被立即释放,而是被“登记”到了离它最近的一个NSAutoreleasePool对象上。当该NSAutoreleasePool被清空或释放的时候,这个“登记”了的对象才会被真正发送一个release消息。
Easy
容器是让多数程序员又爱又恨的东西。在Cocoa中,容器是如此的简单易用以至于您一旦用过,就会对它们“爱不释手”。Cocoa中的容器类主要有这么几个:NSString、NSArray、NSDictionary、NSSet和NSIndexSet等,它们都是Foundation
为什么人们会对Cocoa的容器“爱不释手”呢?
原因一:NSArray、NSDictionary、NSSet都不强制其内部元素类型的一致性。举个简单的例子:
NSString
NSNumber
NSArray
在上述例子中,我们首先建立了一个NSString对象,然后又建立了一个NSNumber对象,最后我们将这两个NSString和NSNumber对象都“塞”到了一个NSArray对象中。
有够爽吧?连想都别想,什么东西都能往里面装(基本类型、结构体除外)!
原因二:容器类的“可修改”和“不可修改”
上面我们展示的NSString、NSArray、NSDictionary、NSSet以及NSIndexSet等,都是容器的“不可修改”的版本。所谓的“不可修改”,指的是这个容器一旦被创建以后,我们就不可以通过代码修改它的集合。那如果我们需要修改(例如添加、删除、替换)这些容器的元素,该怎么办呢?
Cocoa中几乎所有的容器类,都提供了另外一个“可修改”的版本。例如:继承自NSString的NSMutableString、继承自NSArray的NSMutableArray、继承自NSDictionary的NSMutableDictioanry、继承自NSSet的NSMutableSet以及继承自NSIndexSet的NSMutableIndexSet等。这些“可修改”的版本提供了简单直观的方法,用来修改其内部的元素。例如:
NSString
NSNumber
NSMutableArray
[aMutableArray
[aMutableArray
[aMutableArray
[aMutableArray
在上述代码中,第一、二行建立了一个NSString对象和一个NSNumber对象。第三行建立了一个NSMutableArray对象(也就是一个“可修改”的NSArray对象)。第四、五行通过-addObject:方法分别将第一、二行建立的NSString对象和NSNumber对象加入了这个“可修改”的NSArray里。第六行则是根据我们给定的索引号0,删除了数组中的第一个元素。第七行的-removeAllObjects最后一口气将数组中存在的所有元素统统删除(置空数组)。