8

派生プロパティが読み取り専用の場合、一時属性をモデル化する理由はありますか? カスタマイズしたクラスでプロパティを宣言し、その場で getter で値を計算する方がはるかに簡単に思えます。これを keyPathsForValuesAffecting と組み合わせて、オブザーバーに変更を通知します。キャッシュが必要な場合は、プロパティに ivar を追加し、基になる値の 1 つが変更されるたびにリセットします (この質問への回答で提案されているように)。

これを一時的な属性としてモデル化する利点はありますか?

4

1 に答える 1

7

Core Data Programming Guide からのこの引用のために、私は実際にまさにこれを行っていました。これは良いことだという考えにたどり着いたと私は信じています。

ただし、「(実際には fullName 属性がキャッシュされる可能性は低いかもしれませんが、例は理解しやすいです)」と言い続けており、これは実際に彼らが説明していたことの単なる例に過ぎないことを私に知らせています。しかし、おそらく良い実装ではありません。

そのため、一時的なプロパティとその使用目的について詳しく読んだ後、これはおそらく悪い使用方法であることに気付きました。実装のためにキャッシュしても何のメリットもありません。オブジェクトにメッセージを送信する代わりに「ドット」表記を使用する機能 (プロパティであるため) は気に入りましたが、それを使用してもパフォーマンスが向上するとは思いません。

さらに重要なことは、管理対象オブジェクトのコンテキストが追跡しなければならないプロパティにすることのオーバーヘッドが、実際には悪いことだと私は信じています。

そのため、アプリをリファクタリングして、これらの単純なインスタンス メソッドを managedObject エンティティのサブクラスに作成し、結果を返すだけにします。これらを一時的なプロパティにするメリットは見当たらないからです。

これらのいずれかを使用する理由は、managedObject タイプのいずれにも適合しないものを実際に永続化する必要がある場合です。ただし、基本的には 2 つのプロパティを作成します。1 つは一時的で、オブジェクトの真の表現であり、そのためにゲッターとセッターを記述します。もう 1 つは、他のオブジェクトの値を永続化するためにコア データ エンティティ サブクラスによって内部的にのみ使用されるバイナリ データ型である可能性が最も高いものです。 (s) ストレージ オブジェクト内。

少なくともこれは、これがどのように機能するかについての私の理解です。私も非常に混乱しているので、これが間違っている場合はコメントを大歓迎します。

于 2012-01-19T00:44:22.070 に答える