3

デスクトップアプリ用のプラグインアーキテクチャがあります。Appleのコードローディングガイドを使用して、かなり標準的な方法で実装しました。

プラグインのインスタンスが応答できる、または応答する必要があるすべてのメソッドを定義する単一のプロトコルがあります。

唯一の問題は、このプロトコルが約80のメソッドを定義していることです。これらの方法のうち約10個のみが必須であり、残りはオプションです。一部のプラグインは80のメソッドすべてを実装しますが、他のプラグインは基本的な10のみを実装します。

プラグインバンドルがホストアプリケーションにインスタンス化するクラスを通知する通常の方法はNSPrincipalClass、Info.plistファイルのキーを使用することです。これは単一のキーであるため、インスタンス化できるのは単一のクラスのみです。

プラグインプロトコルは単一のファイルであり、この単一のクラスで使用されることが期待されています。

私の質問は、この単一のプロトコル内の機能をおそらく複数のプロトコルに分割すると同時に、プラグインライターがより柔軟な実装を行えるようにするための最良の方法は何ですか？

現在、私の既存のプラグインのプリンシパルクラスには次のものがあります。

- (BOOL)respondsToSelector:(SEL)selector {
    return [self forwardingTargetForSelector:selector] ? YES : NO;
}

- (id)forwardingTargetForSelector:(SEL)selector {
    id target = nil;
    if ([self.instanceOne respondsToSelector:selector]) {
        target = self.instanceOne;
    } else if ([self.instanceTwo respondsToSelector:selector]) {
        target = self.instanceTwo;
    } else if ([self.instanceThree respondsToSelector:selector]) {
        target = self.instanceThree;
    }

    return target;
}

しかし、プラグインライターにこのようなアドホックシステムを定義するのではなく、アプリケーションのプラグインフレームワークがより柔軟なソリューションに対応できるようにしたいと思います。

4

1 に答える 1

1

80個のメソッドを実用的な機能のチャンクに分割できる場合は、それらをいくつかのプロトコル（、、FooProtcolなどBarProtocol）に分割し、プライマリプロトコルでそれらを実装するオブジェクトへの参照を返すオプションのプロパティを定義できます。例えば：

@protocol PluginPrimaryProtocol <NSObject>
@required
/* ... */
@optional
@property (readonly) id<FooProtocol> fooDelegate;
@property (readonly) id<BarProtocol> barDelegate;
/* ... */
@end
于 2012-06-12T12:18:01.887 に答える