内部访问实例变量时应该使用属性还是直接引用? [英] Should I use properties or direct reference when accessing instance variables internally?

问题描述

说我有一个像这样的课程:

Say I have a class like this:

@interface MyAwesomeClass : NSObject
{
@private
    NSString *thing1;
    NSString *thing2;
}
@property (retain) NSString *thing1;
@property (retain) NSString *thing2;
@end

@implementation MyAwesomeClass
@synthesize thing1, thing1;
@end

在内部访问thing1和thing2 时(即，在MyAwesomeClass的实现内)，使用属性还是直接引用实例变量(假设大小写)是更好的选择其中我们在自定义"访问或更改程序中不做任何工作，也就是说，我们只是设置并获取变量).在目标C 2.0之前，我们通常只直接访问ivars，但是现在常见的编码风格/最佳实践是什么?如果实例变量/属性是私有的并且根本无法在类外部访问，则此建议是否会更改?您应该为每个ivar创建一个属性(即使它们是私有的)还是仅为面向公众的数据创建一个属性?如果我的应用程序不使用键值编码功能(因为KVC仅会触发属性访问)怎么办?

When accessing thing1 and thing2 internally (i.e, within the implementation of MyAwesomeClass), is it better to use the property, or just reference the instance variable directly (assuming cases in which we do not do any work in a "custom" access or mutator, i.e., we just set and get the variable). Pre-Objective C 2.0, we usually just access the ivars directly, but what's the usual coding style/best practice now? And does this recommendation change if an instance variable/property is private and not accessible outside of the class at all? Should you create a property for every ivar, even if they're private, or only for public-facing data? What if my app doesn't use key-value coding features (since KVC only fires for property access)?

我有兴趣了解底层技术细节以外的内容.例如，给定的(次优)代码如下:

I'm interested in looking beyond the low-level technical details. For example, given (sub-optimal) code like:

@interface MyAwesomeClass : NSObject
{
    id myObj;
}
@proprety id myObj;
@end

@implementation MyAwesomeClass
@synthesize myObj;
@end

我知道myObj = anotherObject在功能上与self.myObj = anotherObj相同.

I know that myObj = anotherObject is functionally the same as self.myObj = anotherObj.

当然，属性不仅仅是用于指示编译器为您编写访问器和变异器的语法.它们也是更好地封装数据的一种方法，即，您可以更改类的内部实现，而无需重写依赖于那些属性的类.我对解决类本身的内部代码时解决此封装问题的重要性的答案感兴趣.此外，正确编写的属性可以触发KVC通知，但是直接进行ivar访问不会；如果我的应用程序现在不使用KVC功能 now ，以防万一将来可能会使用 ，这有关系吗?

But properties aren't merely fancy syntax for instructing the compiler to write accessors and mutators for you, of course; they're also a way to better encapsulate data, i.e., you can change the internal implementation of the class without rewriting classes that rely on those properties. I'm interested in answers that address the importance of this encapsulation issue when dealing with the class's own internal code. Furthermore, properly-written properties can fire KVC notifications, but direct ivar access won't; does this matter if my app isn't utilizing KVC features now, just in case it might in the future?

推荐答案

我认为任何方式都不是更好"的选择.您会看到两种样式都通用，因此现在甚至没有平常/最佳实践.以我的经验，所使用的样式对我正在寻找的某些实现文件的消化程度影响很小.在查看其他人的代码时，您当然希望对这两种样式(以及两者之间的任何一种)都感到满意.

I don't think any way is 'better'. You see both styles in common use, so there isn't even a usual/best practice now. In my experience, the style used has very little impact on how well I digest some implementation file I am looking. You certainly want to be comfortable with both styles (and any in between) when looking at other people's code.

就维护而言，为每个内部ivar使用属性可能会有点过头.我已经做到了，它增加了一笔微不足道的工作，我认为这并没有为我带来回报.但是，如果您强烈希望/OCD能够在任何地方看到一致的代码，例如self.var，并且每次查看类时都将其隐藏在脑海中，那么请使用它.不要轻视feeling的感觉可能对生产力产生的影响.

Using a property for every internal ivar might be going slightly overboard, in terms of maintenance. I've done it, and it added a non-trivial amount of work that I don't think paid off for me. But if you have a strong desire/OCD for seeing consistent code like self.var everywhere, and you have it in the back of your mind every time you look at a class, then use it. Don't discount the effect that a nagging feeling can have on productivity.

例外-显然，对于自定义getter(例如惰性创建)，您没有太多选择.另外，当确实方便时，我会为内部的setter创建并使用一个属性(例如，使用所有权语义设置对象).

Exceptions- Obviously, for custom getters (e.g. lazy creation), you don't have much of a choice. Also, I do create and use a property for internal setters when it makes it more convenient (e.g. setting objects with ownership semantics).

以防万一"，可能"并不是在没有更多数据的情况下做某事的有说服力的理由，因为实现它所需的时间不为零.一个更好的问题可能是，某个类中的所有私有ivar在将来而不是现在需要KVC通知的概率是多少?对于我自己的大多数类，答案都非常低，因此我现在避免了为每个私有ivar创建属性的硬性规定.

"just in case", "might" is not be a compelling reason to do something without more data, since the time required to implement it is non-zero. A better question might be, what is the probability that all the private ivars in some class will require KVC notifications in the future, but not now? For most of my own classes, the answer is exceedingly low, so I now avoid a hard rule about creating properties for every private ivar.

我发现，在处理内部实现时，我很快就掌握了如何访问每个ivar的好方法.

I've found that when dealing with internal implementations, I quickly get a good handle on how each ivar should be accessed regardless.

如果您有兴趣，我自己的方法是这样:

If you are interested, my own approach is this:

• 读取ivars:直接访问，除非有自定义的getter(例如惰性创建)
• 书写Ivars:直接在alloc/dealloc中.在其他地方，通过私有财产(如果存在).

• Reading ivars: Direct access, unless there is a custom getter (e.g. lazy creation)
• Writing ivars: Directly in alloc/dealloc. Elsewhere, through a private property if one exists.

这篇关于内部访问实例变量时应该使用属性还是直接引用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！