別々の.mファイルでiPhone/iPadイベントハンドラを分離し、#importationでそれらをインポートすることは合理的ですか？

Question

iPhone/iPadの開発では初心者の方が多いので、これが奇妙な質問のようであれば私を許してください。の@implementation後

、その後、別の.mファイルにコールバックをUIViewController内のビュー内のほとんどのオブジェクト（またはオブジェクトのグループ）は、イベントのコールバックが定義されている必要があり、それがグループに合理的と思われることを考えると#importそれらをviewcontroller？

この方法では、標準的な方法、私nitWithNibName:、-viewDidLoad、shouldAutoRotateInterfaceOrientation:、didReceiveMemoryWarning:、-viewDidUnloadと（Xcodeのによって提供される）にdeallocは、あなたのviewcontroller.mファイルで定義された唯一の方法だろう。 viewcontroller.mファイルは、このイベント・コールバックのモノリシックな怪物にならず、メンテナンスも簡単です。私はあなたがあなたの@synthesize店の後ろに置くと思っています。

思考？

Answer 1

モノリシックなファイルを作成しているように見えるかもしれませんが、ViewControllerは実際にはこのすべての場所です。あなたが提案したことをすれば（それは完全に可能です）、あなたはほとんど何もしないファイルの束で終わるでしょう。大きなファイルで整理維持する

一つの方法は、そのようなプラグママークとメソッドの別々のグループにある：

#pragma mark lifecycle methods 

-(void)dealloc{} 
-(id)init{} 
-(id)initWithCoder: 

#pragma mark target-action 

-(id)doSomethingAction:(id)sender{} 
-(id)doSometingElse:(id)sender{} 

Xcodeはプラグママークやグループにプルダウン項目バーにあなたのためのメソッドを解析します簡単にアクセスできます。このリストのメソッドもアルファベット順にリストされています。

Answer 2

はここで、これはにObjCカテゴリを使用して、一つの代替の実例です：

/* File: Header A */ 
@interface MONViewController : NSViewController 
{ 
    unsigned anIvar; 
} 

@property (nonatomic, readonly) unsigned anIvar; 

- (id)initWithNibName:(NSString *)nibName bundle:(NSBundle *)bundle; 
- (void)dealloc; 

- (void)viewDidLoad; 
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation; 

/* (continued) */ 

@end 

/* File: Header A or Header B, depending on how you want to organize it */ 

@interface MONViewController (EventCallbacks) 

- (IBAction)triviaButtonWasPressed:(id)sender; 

/* (continued) */ 

@end 

/* File: Imp A */ 
@implementation MONViewController 

- (id)initWithNibName:(NSString *)nibName bundle:(NSBundle *)bundle { /* ... */ } 
- (void)dealloc { /* ... */ } 
- (unsigned)anIvar { /* ... */ } 

- (void)viewDidLoad { /* ... */ } 
- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation { /* ... */ } 

/* (continued) */ 

@end 

/* File: Imp A or Imp B, depending on how you want to organize it */ 

@implementation MONViewController (EventCallbacks) 

- (IBAction)triviaButtonWasPressed:(id)sender { /* ... */ } 

/* (continued) */ 

@end 

幸い、コンパイラはカテゴリがクラスで実行されるので、定義されたときにすべてのあなたの宣言を定義したことを確認します。プロトコルのような適切なクラス実装で定義されなければならないものがいくつかあります。

これを1トンの小さなファイルに分割すると気をつけます。ビルド時間が実際に苦しんでいる可能性があります。また、このケースでは（あなたのサブクラス化から）、いくらか避けられないが、この点に関するスケーラビリティの問題は、インターフェイス/クラスがあまりにも多くのことを試みていることを通知する役割を果たすため、小さなコンポーネントに分割する必要があります。がんばろう！

Answer 3

私はそれらを分けて見ている問題は、ほとんどのコールバックはクラスローカル変数で動作する必要があり、あなたが作業している@implementationのための対応するヘッダーファイルでそれらを宣言するのが手軽だということです。私には、ビューコントローラにイベント処理のものを残して、他の機能をいくつかの別のファイルに移しておく方が理にかなっています...

しかし、何かブレークアウトする場合も同じクラスインスタンス変数これは、あなたが他にはないかもしれないいくつかのクラス変数をpublicにしなければならないかもしれないことを意味します。

ジャスティンでは、この問題を解決しましたが、技術的に「見る」ことができないクラスインスタンス変数を使用することで、私は奇妙に思えます。