2

(ivar に直接アクセスする代わりに) @synthesized セッターを使用する理由、保持/コピー メモリ管理、または KVO を使用する理由については、さまざまな理由があります。

foo = self.barしかし、 、 またはを使用した場合になぜ気にするかについての適切な議論は思いつきませんfoo = bar。

私が考えることができる唯一のことは、データの抽象化です... bar が宣言されたプロパティである場合、基になる実装が変更される可能性があり、他の誰も気にしません。(もちろん、この場合、おそらく @synthesized ゲッターを使用していないでしょう)

では、@synthesized ゲッターを使用する説得力のある理由はありますか? それを重要にするスレッドの問題はありますか？

さらに言えば、ivar を返すだけでなく、@synthesized コードは何をするのでしょうか?

4

2 に答える 2

2

正当な理由の 1 つはカプセル化です。アクセサーを通過すると、クラスはインターフェースの背後で必要なトリックを自由に実行できます（質問ですでに述べたように）。値は遅延してフェッチされるか、オンザフライで計算されるか、他のオブジェクトからフェッチされる可能性があります。とは言っても、クラスの実装内では、プロパティの実装が変更された場合にこれを自由に書き換えることができるため、通常はプレーンな ivar アクセスを使用します。(これは、サブクラスがそれらに直接アクセスできるように、プライベート ivar がパブリック ヘッダーで宣言されたときに、より大きな問題でした。)

スレッドに関しては、デフォルトの getter/setter の組み合わせはアトミックだと思います。つまり、setter の途中で getter が呼び出されて無効な値が取得されるというバグは発生しません。私はこの問題についてあまり読んだことがありませんnonatomic。プロパティ修飾子のドキュメントをチェックしてください。（またはこの関連する質問。）

于 2012-07-31T06:55:01.980 に答える
1

@propertyゲッターは、ステートメントで定義されているメモリ管理ルールにも準拠する必要があります。たとえば、retain使用する必要のある属性がある場合autorelease：

- (NSString *)name
{
    return [[_name retain ] autorelease];
}

また、合成することで、入力する必要がなくなります。さらに、ゲッターとセッターの両方を合成できることは、より完全なソリューションです。

于 2012-07-31T06:46:55.210 に答える