カテゴリやプロトコルを使用する代わりに、サブクラス化を検討しなかったのはなぜですか?ここでは、パネルアニメーションメソッドを定義するAbstractViewControllerクラス(UIViewControllerから継承)を作成し、抽象コントローラーから独自の具象コントローラー(PanelAViewController、PanelBViewControllerなど)を派生させることができます。
抽象クラスはメソッドを定義し、最終的には実装内のいくつかのスタブを定義します(PanelAとPanelBがsuperを呼び出すかどうかはあなた次第です)。これは、抽象クラスに与えたい抽象度によって異なります。以下のコード例を参照してください。
プロトコル、サブクラス、またはデリゲートメカニズムを使用する方がよいかどうかが明確でない場合があります。ほとんどの場合、境界は明確ではなく、最終的な決定は、「体系化された」アーキテクチャルールよりもプログラマーの好みに依存します。通常、プロトコルを使用するのは、さまざまなオブジェクトに特定のタスクで共通の動作を持たせる場合です(たとえば、複雑なエンティティセットがあり、これらのエンティティの1つをマップアノテーションとして使用する必要があります。このような場合は、この特定のエンティティを指定するだけです。 MKAnnotationプロトコルの互換性); デリゲートは主に、クラスをサブクラス化せずに、または最終ユーザーにサブクラス化する可能性を与えずにクラスを拡張する場合に使用されます。あなたの場合、すべてのクラスが厳密に同じクラス階層の一部であるため、サブクラス化が最も適切な選択だと思います。
//
// AbstractViewController.h
//
#import
@interface AbstractViewController : UIViewController
-(void)doAnimate;
-(void)didAnimate;
@end
//
// AbstractViewController.m
//
#import "AbstractViewController.h"
@interface AbstractViewController ()
@end
@implementation AbstractViewController
-(void)doAnimate {
NSLog(@"Abstract do animate");
}
-(void)didAnimate {
NSLog(@"Abstract did animate");
}
//
// ConcreteViewController.h
//
#import "AbstractViewController.h"
@interface ConcreteViewController : AbstractViewController
@end
//
// ConcreteViewController.m
//
#import "ConcreteViewController.h"
@interface ConcreteViewController ()
@end
@implementation ConcreteViewController
-(void)doAnimate {
[super doAnimate];
NSLog(@"Subclass do animate");
}