別のUIViewControllerのプロパティとしてUIViewControllerを設定するのは悪い考えですか？

Question

たとえば、私はRootViewControllerクラスとAnotherViewControllerクラスを持っていて、私はのプロパティをAnotherViewControllerから変更する必要があります。AnotherViewController.hにそのRootViewControllerプロパティを持つことは安全ですか？変数）？

@interface AnotherViewController : UIViewController { 
    RootViewController *rootViewController; 
} 

@property (nonatomic, retain) RootViewController *rootViewController; 
@end 

@implementation AnotherViewController 

@synthesize rootViewController; 

- (void)someMethod { 
    // set the data was added flag, so the rootViewController knows to scroll to the bottom of the tableView to show the new data 
    self.rootViewController.dataWasAdded = YES; 

    // if the user came in via a search result, make the search controller's tableView go away 
    self.rootViewController.searchDisplayController.active = NO; 
} 

これは良い考えではない場合は、誰でも理由を説明できますか？

上記のコードでは、私はプロトコル/デリゲートを使って同じことを処理できたと思います。しかし、私が読んだ本やその他の資料は、実際にこれについて議論していません。

私は、自分のアプリを普遍的なものにするプロセスを進めており、UISplitViewControllerを使用していることがわかりました。ユーザが頻繁に「マスタービュー」を更新する必要があることがわかりました。 "詳細ビュー"。だから、簡単なルートのように見えて、プロパティとしてUIViewControllersを設定し始めましたが、メモリリークや時折クラッシュを追跡するのが難しいです。私は "循環参照"について何かを読んで、それが問題の一部であるかどうか疑問に思います（私はUIViewControllersが互いの特性として設定されているいくつかの場所を持っています）。

ありがとうございましたか、またはこれをカバーする参考資料へのポインタをありがとうございます。

Answer 1

より安全な代替手段があるので、私はこれを習慣化しないでください。プロトコル/デリゲートを使用することは、クラス間でデータを管理するAppleの推奨方法です。あるクラスから別のクラスにデータ/イベントを送信/トリガーするようにNSNotificationsを設定することもできます。 Key Value Observing（KVO）は、変化を聴くためのまともな方法です。

MVCの構造化では、子ビューと下流のコントローラは、実際には親のアイデア（別名、保持参照）を持たないはずです。それは、親が管理し、子供を追跡しているところで、常に逆の方法で動作するはずです。