NSString 속성을 제공하는 사용자 지정 클래스가 있습니다. Interface Builder에서는 title이 NSButton 인 것을 내 사용자 정의 클래스의 속성에 바인딩했습니다.역방향 코코아 바인딩 및 바인딩 대상 뷰를 식별 하시겠습니까?
내 맞춤 클래스 내에서 NSButton 인스턴스에 대한 참조를 가져올 수 있습니까?
기본적으로 내 사용자 지정 클래스에서 속성에 바인딩 된 모든 사용자 인터페이스 요소를 찾으려고합니다.
일반적으로 이것은 안티 패턴 및/또는 나쁜 아이디어처럼 들립니다. 즉, 염두에 두어야 할 것이 있습니다. 여러 관찰자가 귀하의 재산에 묶일 수 있습니다. addObserver:forKeyPath:options:context:과 removeObserver:forKeyPath: (및 removeObserver:forKeyPath:context:)을 무시한 다음 자신 만의 옵저버 배열을 유지할 수 있습니다. 이 방법을 사용하면 관측자를 유지하지 않도록 추가 노력을해야 할 수도 있습니다. 관측 대상을 유지하지 않는 KV 관측과 유지를 시작하면 누수/힙 증가가 발생할 가능성이 있습니다. 그들 NSArray에 넣어 그들을.
addObserver:...과 removeObserver:...을 오버라이드 한 다른 문제는 관찰이 바인딩 또는 다른 것 (예 : 종속 키 경로 알림)에 대한 것인지 여부는 알지 못합니다. 가능한 한 가지 해결 방법은 infoForBinding:을 통해 을 사용하여 나중에 runloop 단계에서 모두 exposedBindings을 통해 관찰자에게 질문하는 것입니다. (제 생각에는 방금 입을 막 튀 겼던 것 같습니다.)
KVO 시스템의 개인 구현 세부 정보에 의존하는 것은 좋은 접근 방법이 아닙니다. KVO 작동하지만 실제로 뭔가를 달성하려고하는 것처럼 들립니다.
정말이 모든 접근 방식은 재앙을위한 처방처럼 느껴집니다. MVC 위반과 같이 들립니다. 모델 객체가 뷰 객체에 대해 알아야하는 이유는 무엇입니까? 여기에서 성취하고자하는 것은 모든 UI 요소를위한 IBOutlets와 모델의 속성을 가진 NSViewController 서브 클래스가 펜촉을 소유하게함으로써 거의 확실하게 더 잘 수행 될 것입니다. 그 객체는 런타임 트릭없이보기와 모델 객체 사이의 명백하게 복잡한 관계를보다 깔끔하게 관리 할 수있는 위치에있게됩니다. 이 속임수의 궁극적 인 목표에 대해 자세히 설명하지 않았으므로 최선의 접근 방식이 무엇인지 말할 수 없습니다.
나는 완벽한 해결책이 없지만'-addObserver : forKeyPath : options : context :'를 재정의 할 것을 제안한다. 나는 바운드 컨트롤러에서 그렇게해야한다고 생각합니다. – paulmelnikow
달성하려는 목표는 무엇입니까? 어쩌면 다른 바인딩, 뷰 서브 클래스 또는 KVO를 활용하는 또 다른 방법이있을 수 있습니다. – paulmelnikow
'- (void *) observationInfo'도 유용한 정보를 얻을 수 있습니다. 확실하지 않습니다. – Vervious