プロパティを公開するカスタム クラスがありNSString
ます。title
Interface Builder で、 のNSButton
をカスタム クラスのプロパティにバインドしました。
NSButton
カスタム クラス内からインスタンスへの参照を取得することはできますか?
基本的に、カスタム クラスのプロパティにバインドされているすべてのユーザー インターフェイス要素を見つけようとしています。
プロパティを公開するカスタム クラスがありNSString
ます。title
Interface Builder で、 のNSButton
をカスタム クラスのプロパティにバインドしました。
NSButton
カスタム クラス内からインスタンスへの参照を取得することはできますか?
基本的に、カスタム クラスのプロパティにバインドされているすべてのユーザー インターフェイス要素を見つけようとしています。
一般に、これはアンチパターンおよび/または悪い考えのように聞こえます。とはいえ、留意すべき点がいくつかあります。複数のオブザーバーをプロパティにバインドできます。addObserver:forKeyPath:options:context:
and removeObserver:forKeyPath:
(and ) をオーバーライドremoveObserver:forKeyPath:context:
して、独自のオブザーバーの配列を維持できます。そのアプローチでは、配列がオブザーバーを保持しないようにするために余分な努力が必要になる場合があることに注意してください。これは、伝統的に KV 観測では観測オブジェクトが保持されず、保持を開始するとリーク/ヒープの成長に遭遇する可能性があるためです。それらを に入れますNSArray
。
オーバーライドに関するもう 1 つの落とし穴は、かなりの余分な作業がなければ、観測がバインディングのためのものなのか、それ以外のもの (たとえばaddObserver:...
、removeObserver:...
依存する keyPath 通知など) のためのものなのかがわからないことです。考えられる回避策の 1 つは、を使用して、後の runloop パスでinfoForBinding:
on allを介してオブザーバーに問い合わせることです。(これを提案するために、口の中で少し吐いただけだと思います。)exposedBindings
performSelector:afterDelay:
KVO システムのプライベートな実装の詳細に依存することは、目的が単に KVO のしくみをよりよく理解することでない限り、良いアプローチではない可能性がありますが、実際に何かを達成しようとしているように思えます。
本当に、このアプローチ全体が災害のレシピのように感じます. 最初からMVC違反のように聞こえます。モデルオブジェクトがビューオブジェクトについて知る必要があるのはなぜですか? ここで達成しようとしているものは、すべての UI 要素の IBOutlets とモデルのプロパティを持つ NSViewController サブクラスによって nib を所有することで、ほぼ確実に達成されます。そのオブジェクトは、ビューとモデル オブジェクトの間の明らかに複雑な関係を、ランタイムのトリッキーなしでよりきれいに管理できるようになります。このトリックの最終的な目標について詳しく説明していないため、最善のアプローチが何であるかを言うのは困難です.