Robert McNallyによる「The Code Commandments：Best Practices for Objective-C Coding」という謙虚に名付けられた記事を2年ほど前に読んだ後、Objective-Cクラスのほとんどすべてのデータメンバーにプロパティを使用するという慣習を採用しました（ 2012年5月の第3の戒め）。マクナリーはそうするためのこれらの理由をリストします（私の強調）：
- プロパティはアクセス制限を強制します（読み取り専用など）
- プロパティはメモリ管理ポリシーを適用します（強い、弱い）
- プロパティは、カスタムセッターとゲッターを透過的に実装する機会を提供します。
- カスタムセッターまたはゲッターを持つプロパティを使用して、スレッドセーフティ戦略を実施できます。
- インスタンス変数にアクセスする単一の方法があると、コードが読みやすくなります。
私はほとんどの物件をプライベートカテゴリに分類しているので、1と4は通常、私が遭遇する問題ではありません。引数3と5はより「やわらかい」ものであり、適切なツールと他の一貫性があれば問題にならない可能性があります。最後に、私にとってこれらの議論の中で最も影響力があったのは、2番目のメモリ管理でした。それ以来、私はこれを続けています。
@property (nonatomic, strong) id object; // Properties became my friends.最後のいくつかのプロジェクトでは、ARCを使用するように切り替えました。そのため、ほとんどすべてのプロパティを作成することは、それでも良いアイデアなのか、それとも少し不必要なのか疑問に思いました。ARCは、Objective-Cオブジェクトのメモリ管理を担当してくれます。ほとんどのstrongメンバーにとって、ivarを宣言するだけで問題なく機能します。とにかく、ARCの前後に手動で管理する必要があったCタイプであり、weakプロパティはほとんどパブリックプロパティです。
もちろん、クラスの外部からのアクセスが必要なものには、まだプロパティを使用していますが、ほとんどのプロパティはほんの一握りのプロパティであり、ほとんどのデータメンバーは、実装ヘッダーの下にivarとしてリストされています。
@implementation GTWeekViewController
{
UILongPressGestureRecognizer *_pressRecognizer;
GTPagingGestureRecognizer *_pagingRecognizer;
UITapGestureRecognizer *_tapRecognizer;
}
実験として、私はこれをもう少し厳密に行っており、すべてのプロパティから離れると、いくつかの良い肯定的な副作用があります。
- データメンバーコードの要件（
@property/@synthesize）は、ivar宣言だけに縮小されます。 - 私の
self.something参照のほとんどは、ちょうどにクリーンアップされました_something。 - プライベート（ivars）とパブリック（プロパティ）のデータメンバーは簡単に区別できます。
- 最後に、これはAppleがプロパティを意図した目的であるように「感じている」が、それは主観的な推測である。
質問に移ります。私は徐々にダークサイドに向かってスライドしており、implementation-ivarsを優先して、使用するプロパティを減らしています。すべてのプロパティを使用することに固執する必要がある理由について少し説明してください。または、必要な場合にのみivarを増やし、プロパティを減らす理由について、現在の一連の考えを確認してください。どちらか一方の最も説得力のある答えが私のマークを受け取ります。
編集：マクナリーはTwitterで、「プロパティにこだわる主な理由は、すべてを実行する1つの方法、すべてを実行する1つの方法（KVC / KVOを含む）だと思います」と言います。