【问题标题】:Naming conventions for BOOL Obj-C 2 properties?BOOL Obj-C 2 属性的命名约定?
【发布时间】:2009-04-30 13:29:38
【问题描述】:

我有一个只读的 BOOL 属性。这里的主要命名模式是什么?

背景:对于普通的旧方法声明,可接受的模式

- (BOOL)isEditable;
- (void)setEditable:(BOOL)flag;

在@property 世界中,这通常表示为

@property(getter=isEditable) BOOL editable;

但是,也有相反的例子。比如在 CalStore/CalCalendar.h

@property(readonly) BOOL isEditable;

(这里的 CalCalendar 是错误的吗,或者这也是只读 BOOL 属性的可接受命名模式?)

我有一个管理视图的控制器,它可以调整大小,也可以不调整大小。该属性是只读的。

@property(readonly) BOOL viewIsResizable;
@property(readonly) BOOL isViewResizable;
@property(readonly, getter=isViewResizable) BOOL viewResizable;

哪种图案最自然或最像可可?

【问题讨论】:

  • 我觉得不得不写 calendar.isEditable 而不是 calendar.editable 似乎很尴尬。我认为你的第三个选择是最“可可”和自然的。这主要是一个意见问题,但这是我的偏好,因为它与 Cocoa 的其他部分最一致。
  • 这不是意见问题,而是正确的问题。话虽如此,亚历克斯绝对是对的:第三个是要走的路。
  • Alex 似乎自相矛盾 - 不是第三个答案会导致“calendar.isEditable”,即所谓的“尴尬”
  • 大黄:没有;第三个答案是@property(readonly, getter=isViewResizable) BOOL viewResizable;

标签: objective-c cocoa


【解决方案1】:

引自ADC

如果属性表示为 形容词,格式为:

- (void)setAdjective:(BOOL)flag;
- (BOOL)isAdjective;

例如:

- (void)setEditable:(BOOL)flag;
- (BOOL)isEditable; 

如果属性表示为动词,格式为:

- (void)setVerbObject:(BOOL)flag; 
- (BOOL)verbObject;

例如:

- (void)setShowsAlpha:(BOOL)flag;
- (BOOL)showsAlpha; 

动词应该是一般现在时。

|K

【讨论】:

【解决方案2】:

我认为这并不重要,因为 KVO 会同时查看 is<Key><Key>

查看 iPhone 类,我见过的最常见的模式是:

@property(nonatomic, getter=isHidden) BOOL 隐藏;

这让您可以通过以下方式访问该属性:

obj.hidden = YES; // (1)
BOOL hidden = obj.hidden; // (2)
BOOL hidden = [obj isHidden]; // (3)

但不是:

BOOL hidden = obj.isHidden; // (4)

CalStore 不遵循该约定。您将不得不使用第 4 行而不是第 2 行。

【讨论】:

  • 这里有趣的区别(是否重要是另一回事)是 CalStore 中的属性是只读的。 obj.hidden = YES 自然读取,而 obj.isHidden = YES 则不那么自然。但是在只读的情况下,你永远不会分配状态,只是查询它。
【解决方案3】:

您会想要使用与 KVO、KVC 和绑定等一起使用的那个。

我记得在 KVO 等人的文档中读到了这一点。将寻找is<i>&lt;key&gt;</i>set<i>&lt;key&gt;</i> 以及get<i>&lt;key&gt;</i> 和许多其他人,例如countOf&lt;<i>key&gt;</i>

KVC Compliance Checklist 解释得比我做得更好。

【讨论】:

    【解决方案4】:

    CalStore 示例似乎违反了约定。我会坚持属性名称(而不是方法名称)中没有“is”的位置。

    【讨论】:

      【解决方案5】:

      约定绝对是为 BOOL getter 做is...。您在 CalStore 中看到这样的属性集的原因很可能是因为它是只读的,并且为了头文件的基本可读性而以这种方式编写,因为:

      @property(readonly) isEditable;
      

      通常比以下内容更容易阅读:

      @property(readonly, getter=isEditable) editable;
      

      对于第一种类型的属性,在您的实现中,您可以执行以下任一操作:

      @synthesize isEditable = editable;
      

      或者简单地定义访问器:

      - (BOOL)isEditable(void) { return editable; }
      

      这使得接口文件(标题)更容易被潜在用户读取。

      【讨论】:

      • 在情况 2 和 3 中,getter 将被命名为 isViewResizable。这只是属性名称的问题。 [控制器 isViewResizable];但是 controller.isViewResizable 或 controller.viewResizable 后者读起来好笑,但与 [button isEditable] -> button.editable 一致(本身与 CalCalendar 不一致)
      • @property(readonly) isEditable;不等同于 @property(readonly, getter=isEditable) 可编辑;因为在前一种情况下,属性是使用 foo.isEditable 访问的,而在后一种情况下是使用 foo.editable 访问的。它与标题的可读性无关,它完全是错误的。使用综合语句将 ivar 改回可编辑状态不会更改属性名称。
      • @NickLockwood 他在询问约定,有些人更喜欢通过“is”样式获取器访问他们的只读属性。在第二个示例中,您绝对可以使用foo.isEditable 访问editable 属性。显然,您可以以第一种样式访问它。合成到 ivar editable 并不是试图更改属性名称......显然isEditable 是为了更改 ivar,以便在实际类中设置它的代码仍然遵循 setter 约定。无论哪种方式,我个人只会使用第二个。
      • 很公平 - 您的回答似乎有点误导,因为它暗示 1) 只是一种更易读的书写方式 2),而不是生成不同的方法名称。
      猜你喜欢
      • 2015-11-21
      • 1970-01-01
      • 2012-12-03
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2020-06-23
      • 2016-08-31
      相关资源
      最近更新 更多