私人综合财产是矛盾的吗？

Question

在阅读了初学者的 iPhone 开发人员书籍并在线阅读示例代码后，我注意到大多数 Objective C 程序员都会综合几乎所有实例变量。有些变量很容易合成，但大多数变量在遵循面向对象的封装原则时不应该这样做。最糟糕的是标记为私有的综合财产。尝试使用其他人的代码的 C++ 程序员将读取头文件中的公共字段和方法。他们将跳过私有变量。该 C++ 程序员不会知道您打算以某种有意义的方式使用私有属性。

查看延迟表格图像加载 由 Apple 提供：

标题

@interface ParseOperation : NSOperation <NSXMLParserDelegate>

{
@private
    id <ParseOperationDelegate> delegate;
    NSData          *dataToParse;
    NSMutableArray  *workingArray;
    AppRecord       *workingEntry;
    NSMutableString *workingPropertyString;
    NSArray         *elementsToParse;
    BOOL            storingCharacterData;
}

源代码

@interface ParseOperation ()
@property (nonatomic, assign) id <ParseOperationDelegate> delegate;
@property (nonatomic, retain) NSData *dataToParse;
@property (nonatomic, retain) NSMutableArray *workingArray;
@property (nonatomic, retain) AppRecord *workingEntry;
@property (nonatomic, retain) NSMutableString *workingPropertyString;
@property (nonatomic, retain) NSArray *elementsToParse;
@property (nonatomic, assign) BOOL storingCharacterData;
@end

@implementation ParseOperation
@synthesize delegate, dataToParse, workingArray, workingEntry, workingPropertyString, elementsToParse, storingCharacterData;

现在我知道这不是 C++，我们不应该假设所有 C++ 实践都应该在 Objective C 中得到尊重。但是 Objective C 应该有远离一般编程实践的充分理由。

1. 为什么所有私有ivars都被合成？当您将项目视为一个整体时，只有 NSMutableArray *workingArray 被外部类使用。所以其他 ivars 都不应该有 setter 和 getter。
2. 为什么要合成非常敏感的ivars？首先，现在 id delegate 有了 setter，该对象的用户可以在 XML 解析过程中切换委托，这是没有意义的。另外，NSData *dataToParse 是从网络检索的原始 XML 数据。现在它有了一个设置器，该对象的用户可以损坏数据。
3. 将标头中的所有内容标记为 private 有何意义？由于所有 ivars 都被合成为具有 getter/setter，因此它们实际上是公共的。您可以将它们设置为您想要的任何值，并且可以随时获取它们的值。

Answer 1

我在许多课程中都遵循这个例子所模仿的习语，所以我可以尝试解释我自己对这种做法的理由。

此示例中的属性在 .m 文件的类扩展中声明。这使得它们实际上是私有的。任何从另一个类访问这些属性的尝试都会在编译时导致“未找到属性”错误。

对于来自其他语言的开发人员来说，为私有实例变量综合 getter 和 setter 可能看起来很奇怪。事实上，我这样做的原因只有一个。如果一致使用，综合属性可以简化内存管理，并有助于避免可能导致错误的粗心错误。这里有几个例子：

考虑这个：

self.workingPropertyString = [NSMutableString string];

与这个：

workingPropertyString = [[NSMutableString string] retain];

许多开发人员会声称这两个分配在功能上是等效的，但有一个重要的区别。如果workingPropertyString 已经指向保留的对象，则第二个分配会泄漏内存。要编写与合成 setter 功能等效的代码，您必须执行以下操作：

NSMutableString *newString = [NSMutableString string];
if (workingPropertyString != newString) {
    [workingPropertyString release];
    workingPropertyString = [newString retain];
}

此代码避免泄漏实例变量可能指向的任何现有对象，并且它安全地处理您可能重新分配实例变量的可能性。与实例变量相同的对象。综合设置器会为您完成所有这些工作。

当然，我们可以看到在这种情况下 (workingPropertyString != newString) 始终为 true，因此我们可以简化这个特定的分配。事实上，在大多数情况下，您可能可以通过对实例变量进行简单的直接赋值来逃脱，但当然，例外情况往往会产生最多的错误。我更喜欢谨慎行事，并通过合成设置器设置所有对象实例变量。我所有的实例对象分配都是简单的行话，看起来像这样：

self.foo = [Foo fooWithTitle:@"The Foo"];

或者这样：

self.foo = [[[Foo alloc] initWithTitle:@"The Foo"] autorelease];

这种简单性和一致性让我弱小的大脑不需要思考什么。因此，我几乎从来没有遇到过与内存管理相关的错误。 （我知道 autorelease 理论上可能会在紧密循环中消耗过多的内存，但我在实践中还没有遇到过这个问题。如果我遇到过，这也是一个简单的优化案例。）

我喜欢这种做法的另一件事是我的 dealloc 方法都看起来像这样：

- (void)dealloc {
    self.delegate = nil;
    self.dataToParse = nil;
    self.workingArray = nil;
    self.workingEntry = nil;
    self.workingPropertyString = nil;
    self.elementsToParse = nil;
    [super dealloc];
}

编辑：Daniel Dickison 指出了一些
在 dealloc 中使用访问器的风险
我没有考虑过。请参阅
注释。

其中每个对象属性都简单地设置为 nil。这会同时释放每个保留的属性，同时将其设置为 nil，以避免由于 EXC_BAD_ACCESS 导致的某些崩溃。

请注意，我设置了 self.delegate = nil;，即使该属性被声明为 (nonatomic, allocate)。这项任务并不是绝对必要的。事实上，我可以完全取消我的 (nonatomic, allocate) 对象的属性，但我再次发现，在所有实例变量中一致地应用这个习惯用法可以让我的大脑减少思考，并进一步减少了我因一些粗心错误而产生错误的机会。如果有必要，我可以简单地将属性从（非原子，分配）翻转为（非原子，保留），而无需触及任何内存管理代码。我喜欢这样。

人们还可以使用一致性作为综合私有标量变量属性的参数，正如您的示例在 BOOL storageCharacterData; 的情况下所做的那样。这种做法确保每个实例变量赋值都类似于 self.foo = bar;。我通常不会自己创建私有标量属性，但我可以看到这种做法的一些理由。

Answer 2

为什么都是私有ivars
合成的？当你看着
项目作为一个整体，仅
使用 NSMutableArray *workingArray
通过外部课程。所以没有一个
其他 ivars 应该有设置器和
吸气剂。

没有真正的需要；如果您要直接访问所有 ivars，则不需要 @synthesize。

为什么 ivars 非常敏感
合成的？其一，现在 id
delegate 有一个setter，用户
该对象可以切换委托
XML 解析的中间，一些东西
这没有道理。另外，NSData
*dataToParse 是从网络检索的原始 XML 数据。现在它有一个
setter，该对象的用户可以
损坏数据。

没有任何 setter/getter 被公开声明。如果类的客户端想要通过在中间切换委托来破坏事物，他们必须破坏封装才能做到这一点。

所以，最终，这不是问题。

标记所有内容有什么意义
标题中的私有内容？由于所有伊瓦尔
被合成为具有
getter/setter，它们实际上是
民众。您可以将它们设置为任何内容
你想要并且可以获得它们的价值
只要你愿意。

请注意，在该示例中甚至不需要声明 ivars；编译器会根据@property声明自动合成它们。

传统上，@private 可以防止有人直接从外部将 ivar 欺骗到类的实例。

请注意，anInstance->ivar 或 self->ivar 几乎从未使用过（并且，使用时，几乎总是出于错误的原因）。它有用途，但很少见。