重複の可能性:
self.ivar と ivar の違い?
たとえば、Obj-C でインスタンス変数をプロパティとして定義すると、
@property (copy) NSString *str;
と
@synthesize str = _str;
インスタンスメソッド内でアクセスする必要があります
_str = @"ABC";
または、アクセサーを使用する必要があります。つまり、
[self setStr:@"ABC"];
これに関する一般的なガイドラインはありますか？
どうもありがとう！
クラス内からインスタンス変数を読み取っても問題ありません。
NSLog(@"str = %@", _str);
ただし、インスタンス変数を直接設定しないでください。
_str = @"ABC"; // No!
これにより、慎重にプロパティに配置したメカニズムがバイパスcopyされます。したがって、代わりに次のようにします。
[self setStr:@"ABC"]; // Ok
self.str = @"ABC"; // Ok, shorter
私は@Dietrichにそのような強硬な線を引くことに多少同意しません。プロパティの getter と setter を利用することは非常に効果的であり、キー値コーディングの自動サポートなどの利点として余分なものを提供しますが、余分なことを行うという欠点もあります。慣例として、外部オブジェクトがオブジェクトのメンバー変数に直接アクセスすることはありませんが、クラス内のメンバー変数に直接アクセスして設定するかどうかを制御および選択できます。
直接アクセスの長所:
1) 高速 - それほど多くないように見えるかもしれませんが、変数に直接アクセスする代わりにメソッドを使用するたびに、関数のオーバーヘッドが発生します - これをループで実行すると、コストは取るに足らないものではありません。
2) 明示的 - 変数を設定したときに何が変化するかを正確に知っています
直接アクセスの短所:
1) ゲッターとセッターのポリモーフィズムの喪失 - 変数に直接アクセスすることで、サブクラスがそれらのゲッターとセッターの機能を拡張する能力を失います。これは、OOP の観点からは望ましくない可能性があります (ただし、これも利点になる可能性があります)。アーキテクチャに応じて)
2) KVO の損失 (または少なくともそれを難しくする) - キー値の監視は、メンバー変数の値の変更をメソッド コールバックにバインドして、ある種のイベント駆動型の変更 (ほとんどの場合、プロパティのバインドなど) を引き起こすための非常にクールな方法です。 UI レイアウト/表示に)。ただし、KVO は万人向けではありません。
3) 自動同期の喪失 (アトミックとして宣言されている場合) - メンバー変数をスレッドセーフにする必要がある場合があります。これは、定型コードを削除することにより、プロパティにとって大きなメリットです。
最終的には、開発者であるあなた次第です。実際には、スレッドセーフにするか、拡張機能と KVO に対して構造的に堅牢にするオブジェクトを構築する場合を除いて、メンバー変数への直接アクセスに傾倒する傾向があります。
これがお役に立てば幸いです。選択はあなた次第です。:)