3

Objective-C の現在のバージョンでは、 と を使用して ivar を宣言するための公式の標準とベスト プラクティスは@property何@synthesizeですか? このトピックに関する投稿やリソースはたくさんありますが、それらのほとんどは 1、2 年前のものとはかなり時代遅れです。私は最近、OOP のカプセル化の原則が破られないように、クラスの実装のステートメント ブロックで ivar のみを宣言することを学びましたが、この日と年齢で ivar を宣言することさえ必要ですか? 実行する場合の可能なユースケースは何ですか:

@interface MyClass()
@property (nonatomic) NSString* data;
@end

@implementation MyClass{
    @private
        NSString* _data;
}
@end

必要です？それをさらに進めるために、使用する必要はあります@synthesizeか? 私の理解では、を使用@propertyすると、アクセサー メソッドとバッキング ivar の両方が自動合成されます。NSString* _data', I can still accessいくつかの実験を行ったところ、クラスの実装で _data' を宣言していないことに気付きました。つまり、ivar の宣言はスタイルの問題であり、プログラマーの裁量に委ねられるということですか? コードを要約して、実装のステートメント ブロック内のすべての ivar 宣言を削除@propertyし、プライベート インターフェイスで使用することはできますか? そうでない場合、ivar を明示的に宣言することの利点と欠点は何ですか?

最後に、@dynamic. 私が収集できることから、それはコンパイラーに対して、「コンパイラーさん、アクセサー メソッドを自動生成しないでください。実装が見つからなくても心配しないでください。実行時に提供します。 "。それはすべて@dynamicのために使用されていますか、それ以上のものがありますか?

さまざまな意見があり、必ずしも正しい答えが 1 つではないように思われるため、これらすべてを明確にしたいと思います。さらに、Objective-C が成長し進歩するにつれて、これらの答えは変化するため、簡潔で最新のガイドがあると便利です。みんな、ありがとう！（また、より適切に表現したり、より明確にしたりできることがあれば、お知らせください）

編集：

要約すると、私が求めているのは次のとおりです。

1) 最新の Objective-C で ivar を宣言する必要はありますか? 2) を使用するだけで、ivar と対応するプロパティを宣言するのと同じ効果を達成できます@propertyか? 3) @dynamic は何に使用されますか? 4) の使用を完全にやめることができますか、@synthesizeそれとも適切な使用例はありますか?

必要に応じて賛成票と反対票を投じてください。

4

3 に答える 3

6

ここで答えなければならないことがたくさんあります。私はそれを分解します：

ivar の宣言

ご指摘のとおり、最新バージョンのコンパイラは、宣言された @properties のバッキング インスタンス変数を合成します。これに対する例外は、壊れにくいインスタンス変数を含む最新の Objective-C ランタイムが利用できない 32 ビット Mac です。アプリケーションが 32 ビット OS X を対象としていないと仮定すると、@property.

ivar を対応する@propertyものなしで直接使用したい場合 (ほとんどの場合、これは悪い考えだと私は考えています) はもちろん、ivar を明示的に宣言する必要があります。

@動的

@dynamicあなたが言ったように、コンパイラに「このプロパティのアクセサを合成しないでください。実行時に自分で行います」と伝えることを意図しています。それほど頻繁には使用されません。使用される場所の 1 つはNSManagedObjectサブクラスです。ヘッダーでモデル化されたプロパティを宣言する場合、そのプロパティのアクセサーの実装がないことをコンパイラに訴えたり、アクセサー自体を生成したりしたくありません。NSManagedObject実行時にモデル化されたプロパティのアクセサーを生成します。カスタム CALayer サブクラスの場合も同様です。

@合成

@synthesizeアクセサー メソッドを合成するようにコンパイラに明示的に指示し、(iOS および 64 ビット Mac では) 指定されたプロパティに対応する ivar を生成します。それでも使用する必要がある主なケースは 3 つあります。

  1. 32 ビット Mac アプリ。
  2. 独自のカスタム セッターとゲッター (または読み取り専用プロパティのゲッター) を作成した場合。この場合、コンパイラはアクセサーを認識しているため、アクセサーを合成しません。ただし、バッキング ivar も合成しません。したがって、を使用@synthesize someProperty = _someProperty;して、ivar を合成するようにコンパイラに指示する必要があります。もちろん、まだアクセサメソッドを合成しません。または、バッキング ivar を明示的に宣言することもできます。@synthesizeこの場合に使用することをお勧めします。
  3. プロパティのバッキング ivar にデフォルトとは異なる名前を使用する場合 (プロパティ名にアンダースコア プレフィックスを追加)。これはまれです。私がそれを使用するために考えることができる主なケースは、ivar への直接アクセスを含み、ivar にアンダースコアが付けられていない、既存の古いコードを移行する場合です。
于 2013-11-07T18:07:15.330 に答える
1

まず、これらのシナリオでは @synthesize が使用されなくなりました。これ以上行う必要はありません。

次に、プライベート ivar ももう必要ありません。

したがって、本質的には、プロパティを実行するだけです。

アクセスを制御する方法は、MOC が廃止される前に一般的になったのと同じイディオムです。パブリック インターフェイスにプロパティを読み取り専用として配置し、プライベート インターフェイスで読み取り書き込みバージョンを作成します (上記で示したように、単に名前に開き括弧と閉じ括弧)。

また、過去にパブリック インターフェイスを散らかしていたものの多くは、プライベート インターフェイスにしか存在できないことに注意してください。たとえば、IBOutlets などです。これは、コントローラがそれらを処理する唯一のものになるためです。

CoreDate で生成されたエンティティ以外で @dynamic が使用されているのを見たことがありません。

C++ を最初に使用した人にとって、ヘッダー/インターフェイスはクラスのユーザーに必要なものを表示するだけで、他のすべての詳細は隠されることを常に夢見ていた人にとって、MOC (Modern Objective C) は夢の実現だと思います。

ところで、WWDC Modern Objective C (2012 年から) のイントロ セッションを強くお勧めします。今年のセッションも素晴らしかったです。

于 2013-11-07T17:58:24.643 に答える