Шаблон плагина какао

У меня есть архитектура плагина для моего настольного приложения. Я реализовал это довольно стандартным способом, используя Руководство по загрузке кода от 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;
}

Но вместо того, чтобы навязывать разработчику подключаемого модуля определение специальной системы, подобной этой, я хотел бы, чтобы структура подключаемого модуля приложения соответствовала более гибкому решению.


objective-c cocoa plugins appkit cocoa-design-patterns
person firstresponder    schedule 12.06.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Если вы можете разделить свои 80 методов на осмысленные фрагменты функциональности, вы можете разделить их на несколько протоколов (FooProtcol, BarProtocol и т. д.) и определить необязательные свойства, которые возвращают ссылки на объекты, реализующие их в основном протоколе. Например:

@protocol PluginPrimaryProtocol <NSObject>
@required
/* ... */
@optional
@property (readonly) id<FooProtocol> fooDelegate;
@property (readonly) id<BarProtocol> barDelegate;
/* ... */
@end
person 一二三    schedule 12.06.2012