1、
1. @interface EOCPerson : NSObject {
2. @public
3. NSString *_firstName;
4. NSString *_lastName;
5. @private
6. NSString *_someInternalData;
7. }
8. @end
原来编过Java或C++程序的人应该比较熟悉这种写法，在这些语言中，可以定义实例变量的作用域。然而编写Objective-C代码时却很少这么做。这种写法的问题是：对象布局在编译期（compile time）就已经固定了。只要碰到访问_firstName变量的代码，编译器就把其替换为“偏移量”（offset），这个偏移量是“硬编码”（hardcode），表示该变量距离存放对象的内存区域的起始地址有多远。这样做目前来看没问题，但是如果又加了一个实例变量，那就麻烦了。比如说，假设在_firstName之前又多了一个实例变量：
1. @interface EOCPerson : NSObject {
2. @public
3. NSDate *_dateOfBirth;
4. NSString *_firstName;
5. NSString *_lastName;
6. @private
7. NSString *_someInternalData;
8. }
9. @end
原来表示_firstName的偏移量现在却指向_dateOfBirth了。把偏移量硬编码于其中的那些代码都会读取到错误的值。
如果代码使用了编译期计算出来的偏移量，那么在修改类定义之后必须重新编译，否则就会出错。例如，某个代码库中的代码使用了一份旧的类定义。如果和其相链接的代码使用了新的类定义，那么运行时就会出现不兼容现象（incompatibility）。各种编程语言都有应对此问题的办法。Objective-C的做法是，把实例变量当做一种存储偏移量所用的“特殊变量”（special variable），交由“类对象”（class object）保管（第14条详述了类对象）。偏移量会在运行期查找，如果类的定义变了，那么存储的偏移量也就变了，这样的话，无论何时访问实例变量，总能使用正确的偏移量。甚至可以在运行期向类中新增实例变量，这就是稳固的“应用程序二进制接口”（Application Binary Interface，ABI）。ABI定义了许多内容，其中一项就是生成代码时所应遵循的规范。有了这种“稳固的”（nonfragile）的ABI，我们就可以在“class-continuation分类”或实现文件中定义实例变量了。所以说，不一定要在接口中把全部实例变量都声明好，可以将某些变量从接口的public区段里移走，以便保护与类实现有关的内部信息。
这个问题还有一种解决办法，就是尽量不要直接访问实例变量，而应该通过存取方法来做。虽说属性最终还是得通过实例变量来实现，但它却提供了一种简洁的抽象机制。你可以自己编写存取方法，然而在正规的 Objective-C 编码风格中，存取方法有着严格的命名规范。正因为有了这种严格的命名规范，所以 Objective-C 这门语言才能根据名称自动创建出存取方法。这时@property 语法就派上用场了。
注：
应用程序二进制接口描述了应用程序和操作系统之间，一个应用和它的库之间，或者应用的组成部分之间的低层接口。ABI不同于应用程序接口（API），API定义了源代码和库之间的接口，因此同样的代码可以在支持这个API的任何系统中编译，然而ABI允许编译好的目标代码在使用兼容ABI的系统中无需改动就能运行。
ABI掩盖了各种细节，例如调用约定（控制着函数的参数如何传送以及如何接受返回值）；系统调用的编码和一个应用如何向操作系统进行系统调用；以及在一个完整的操作系统ABI中，对象文件的二进制格式、程序库等等。一个完整的ABI，像 Intel 二进制兼容标准 (iBCS) ，允许支持它的操作系统上的程序不经修改在其他支持此 ABI 的操作系统上运行。其他的 ABI 标准化细节包括 C++ name decoration 和同一个平台上的编译器之间的调用约定，但是不包括跨平台的兼容性。
2、在前例中，会生成两个实例变量，其名称分别为_firstName与_lastName。也可以在类的实现代码里通过@synthesize语法来指定实例变量的名字：
1. @implementation EOCPerson
2. @synthesize firstName = _myFirstName;
3. @synthesize lastName = _myLastName;
4. @end
前述语法会将生成的实例变量命名为_myFirstName与_myLastName，而不再使用默认的名字。一般情况下无须修改默认的实例变量名。
3、还有一种办法能阻止编译器自动合成存取方法，就是使用@dynamic关键字，它会告诉编译器：不要自动创建实现属性所用的实例变量，也不要为其创建存取方法。而且，在编译访问属性的代码时，即使编译器发现没有定义存取方法，也不会报错，它相信这些方法能在运行期找到。比方说，如果从 CoreData 框架中的 NSManagedObject 类里继承了一个子类，那么就需要在运行期动态创建存取方法。继承 NSManagedObject 时之所以要这样做，是因为子类的某些属性不是实例变量，其数据来自后端的数据库中。例如：
1. @interface EOCPerson : NSManagedObject
2. @property NSString *firstName;
3. @property NSString *lastName;
4. @end
5.
6. @implementation EOCPerson
7. @dynamic firstName, lastName;
8. @end
编译器不会为上面这个类自动合成存取方法或实例变量。如果用代码访问其中的属性，编译器也不会发出警示信息。
4、
● assign “设置方法”只会执行针对“纯量类型”（scalar type，例如CGFloat或NSInteger等）的简单赋值操作。
● strong 此特质表明该属性定义了一种“拥有关系”（owning relationship）。为这种属性设置新值时，设置方法会先保留新值，并释放旧值，然后再将新值设置上去。
● weak 此特质表明该属性定义了一种“非拥有关系”（nonowning relationship）。为这种属性设置新值时，设置方法既不保留新值，也不释放旧值。此特质同assign类似，然而在属性所指的对象遭到摧毁时，属性值也会清空（nil out）。
● unsafe_unretained 此特质的语义和assign相同，但是它适用于“对象类型”（object type），该特质表达一种“非拥有关系”（“不保留”，unretained），当目标对象遭到摧毁时，属性值不会自动清空（“不安全”，unsafe），这一点与weak有区别。
● copy 此特质所表达的所属关系与strong类似。然而设置方法并不保留新值，而是将其“拷贝”（copy）。当属性类型为NSString*时，经常用此特质来保护其封装性，因为传递给设置方法的新值有可能指向一个NSMutableString类的实例。这个类是NSString的子类，表示一种可以修改其值的字符串，此时若是不拷贝字符串，那么设置完属性之后，字符串的值就可能会在对象不知情的情况下遭人更改。所以，这时就要拷贝一份“不可变”（immutable）的字符串，确保对象中的字符串值不会无意间变动。只要实现属性所用的对象是“可变的”（mutable），就应该在设置新属性值时拷贝一份。
5、通过上述特质，可以微调由编译器所合成的存取方法。不过需要注意：若是自己来实现这些存取方法，那么应该保证其具备相关属性所声明的特质。比方说，如果将某个属性声明为copy，那么就应该在“设置方法”中拷贝相关对象，否则会误导该属性的使用者，而且，若是不遵从这一约定，还会令程序产生bug。
如果想在其他方法里设置属性值，那么同样要遵守属性定义中所宣称的语义。例如，我们扩充一下前面提到的EOCPerson类。由于字符串值可能会改变，所以要把相关属性的“内存管理语义”声明为copy。该类中新增了一个“初始化方法”（initializer），用于设置“名”（first name）和“姓”（last name）的初始值：
1. @interface EOCPerson : NSManagedObject
2.
3. @property (copy) NSString *firstName;
4. @property (copy) NSString *lastName;
5.
6. - (id)initWithFirstName:(NSString*)firstName
7. lastName:(NSString*)lastName;
8. @end
在实现这个自定义的初始化方法时，一定要遵循属性定义中宣称的“copy”语义，因为“属性定义”就相当于“类”和“待设置的属性值”之间所达成的契约。初始化方法的实现代码可以这样写：
1. - (id)initWithFirstName:(NSString*)firstName
2. lastName:(NSString*)lastName
3. {
4. if ((self = [super init])) {
5. _firstName = [firstName copy];
6. _lastName = [lastName copy];
7. }
8. return self;
9. }
6、atomic与nonatomic的区别是什么呢？前面说过，具备atomic特质的获取方法会通过锁定机制来确保其操作的原子性。这也就是说，如果两个线程读写同一属性，那么不论何时，总能看到有效的属性值。若是不加锁的话（或者说使用nonatomic语义），那么当其中一个线程正在改写某属性值时，另外一个线程也许会突然闯入，把尚未修改好的属性值读取出来。发生这种情况时，线程读到的属性值可能不对。
注：在并发编程中，如果某操作具备整体性，也就是说，系统其他部分无法观察到其中间步骤所产生的临时结果，而只能看到操作前与操作后的结果，那么该操作就是“原子的”，或者说，该操作具备“原子性”。
7、如果开发过iOS程序，你就会发现，其中所有属性都声明为nonatomic。这样做的历史原因是：在iOS中使用同步锁的开销较大，这会带来性能问题。一般情况下并不要求属性必须是“原子的”，因为这并不能保证“线程安全”（thread safety），若要实现“线程安全”的操作，还需采用更为深层的锁定机制才行。例如，一个线程在连续多次读取某属性值的过程中有别的线程在同时改写该值，那么即便将属性声明为atomic，也还是会读到不同的属性值。因此，开发iOS程序时一般都会使用nonatomic属性。但是在开发Mac OS X程序时，使用atomic属性通常都不会有性能瓶颈。
要点
① 可以用 @property 语法来定义对象中所封装的数据。
② 通过“特质”来指定存储数据所需的正确语义。
③ 在设置属性所对应的实例变量时，一定要遵从该属性所声明的语义。
④ 开发iOS程序时应该使用nonatomic属性，因为atomic属性会严重影响性能。