Есть ли сильный аргумент против того, чтобы сделать мою TyphoonAssembly одиночной? Если да, то почему? Если нет, есть ли рекомендуемый способ сделать это?

Question

Я начинаю с Typhoon и нахожу, что досадно продолжать писать конструкторы с дополнительными аргументами assembly. Так что соблазнительно просто сделать мой TyphoonAssembly синглтон. Но я еще не видел, что это сделано в любых примерах, и я вижу примеры, когда для сборки сборки используется конструктор или вложение свойств. Так что, может быть, есть случай против этого - это выглядит плохо, но как плохо, я не знаю.

Так что мои вопросы:

1. Есть веские аргументы против того, чтобы мой TyphoonAssembly одноплодной?
2. Есть ли способ сделать это в рамках, или я должен просто сделать это своим обычным способом?

Edit: Я только начинаю, но скажу, у меня есть один (на данный момент) ApplicationAssembly, который используется следующим образом:

- (NavigationController *)customDefaultNavigationController { 
    return [TyphoonDefinition withClass:[NavigationController class] 
      configuration:^(TyphoonDefinition *definition) { 
       [definition useInitializer:@selector(init)]; 
      }]; 
} 

- (id<IRootWireframe>)rootWireframe { 
    return [TyphoonDefinition withClass:[RootWireframe class] 
      configuration:^(TyphoonDefinition *definition) { 
       [definition useInitializer:@selector(init)]; 
      }]; 
} 

Ничего стоит даже упоминать, но дело в том, что У меня есть по крайней мере три или четыре клиента этой сборки в моем новом приложении, которое все еще находится на уровне «Hello World».

Идти вперед, если мне нужно писать инициализаторы с параметрами сборки, я сделаю это, но если мне удастся просто сделать мой ApplicationAssembly синглтон (или область с объектом, который есть), то я это сделаю.

Answer 1

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

. , после запуска мы продолжаем использовать интерфейсы сборки, поэтому нам не нужно прибегать к «магическим строкам», но это просто приводит к отправке сообщения Objective-C через метод componentForKey TyphoonComponentFactory.

Вы можете самонастройки тайфуна (или библиотеки, и т.д.) в одном из двух следующих способов:

Использование plist integration

Это означает, что вы будете иметь один экземпляр TyphoonComponentFactory в вашем приложении.

Manually

Для примера:

MiddleAgesAssembly *mainAssembly = [[MiddleAgesAssembly new] 
    activateWithCollaboratingAssemblies:@[ 
     [QuestsAssembly new] 
    ]]; 

В этом случае, его до вас, чтобы сохранить TyphoonComponentFactory столько, сколько необходимо, и в случае приложения, было бы вообще быть на протяжении всего жизненного цикла приложения. Пока я рекомендую сохранить его в делегате приложения, хотя, как только вам станет удобно, вы увидите, что он может быть неявно сохранен через proceeding from one object graph to another.

Таким образом, для любого подхода к загрузке Typhoon нет ничего сложного в том, что сборка является синглом. (На самом деле для стиля интеграции plist это просто игнорируется).