Кто должен владеть объектами Dependency Injected в приложениях iOS?

Question

Это, вероятно, фундаментальный вопрос для опытного разработчика iOS, но, исходя из опыта Java, где у нас есть много вкусностей Dependency Injection (DI) (например, Spring), у меня возникли проблемы с выяснением, кто должен владеть DI объекты. К сожалению, я обнаруживаю, что создаю кучу синглетонов, которыми становится довольно неприятно управлять.

Например, у нас есть некоторые Configuration, к которым другие классы хотели бы получить доступ. В настоящее время у нас есть только одно экземпляра для конфигурации, что делает тестирование немного сложным. Технически мы решаем эту проблему, используя метод Swizzling в OCMock.

В Java / Spring есть некоторый контейнер, который создает / владеет этими объектами. В iOS я думаю, что самые близкие вещи, которые у меня есть к контейнеру, это UIApplication и UIApplicationDelegate. Имеет ли смысл для этих вещей создавать / владеть этими объектами, которые в конечном итоге будут внедрены в другие объекты?

Если это так, какова подходящая стратегия для доступа к этим объектам? Например, создайте категорию на UIApplication или UIApplicationDelegate для доступа к этим объектам, например: [[UIApplication sharedApplication] configuration] или [[[UIApplication sharedApplication] delegate] configuration]

Answer 1

Я начинаю свою оценку структуры DI Objective-C, которая называется Возражение .Он вдохновлен Google Guice для Java.

Пример использования из возражений README

@class Engine, Brakes;

@interface Car : NSObject
{
  Engine *engine;
  Brakes *brakes;
  BOOL awake;  
}

// Will be filled in by objection
@property(nonatomic, retain) Engine *engine;
// Will be filled in by objection
@property(nonatomic, retain) Brakes *brakes;
@property(nonatomic) BOOL awake;

@implementation Car
objection_register(Car)
objection_requires(@"engine", @"brakes")
@synthesize engine, brakes, awake;
@end

Answer 2

Действительно, DI, кажется, не то, что люди обычно используют в iOS, как мы делаем в Java или C #.

Лично я, как правило, создаю свой собственный синглтон под названием «Приложение», который содержит все службы и информацию для приложения.Таким образом, я получаю простоту простого синглтона, без особого подключения к iOS (хотя obj-c не может быть использован практически где-либо еще).Так что в моих приложениях у меня обычно есть:

[[Application sharedInstance] configuration]
[[Application sharedInstance] authService]

Так что единственный класс, который должен быть одноэлементным, - это класс Application (не связанный с UIApplication), и он создает все службы в методе init.