|
| 1 | +//: [Previous: Shared Instances](@previous) |
| 2 | + |
| 3 | +import UIKit |
| 4 | +import Dip |
| 5 | + |
| 6 | +let container = DependencyContainer() |
| 7 | +/*: |
| 8 | + |
| 9 | +### Auto-Injection |
| 10 | + |
| 11 | +If you follow Single Responsibility Principle chances are very high that you will end up with more than two collaborating components in your system. Let's say you have a component that depends on few others. Using _Dip_ you can register all of the dependencies in a container as well as that component itself and register a factory that will create that component and feed it with the dependencies resolving them with a container: |
| 12 | +*/ |
| 13 | + |
| 14 | +protocol Service: class { |
| 15 | + var logger: Logger? { get set } |
| 16 | + var tracker: Tracker? { get set } |
| 17 | +} |
| 18 | + |
| 19 | +class ServiceImp: Service { |
| 20 | + var logger: Logger? |
| 21 | + var tracker: Tracker? |
| 22 | +} |
| 23 | + |
| 24 | +container.register() { TrackerImp() as Tracker } |
| 25 | +container.register() { LoggerImp() as Logger } |
| 26 | + |
| 27 | +container.register() { ServiceImp() as Service } |
| 28 | + .resolveDependencies { container, service in |
| 29 | + service.logger = try! container.resolve() as Logger |
| 30 | + service.tracker = try! container.resolve() as Tracker |
| 31 | +} |
| 32 | + |
| 33 | +let service = try! container.resolve() as Service |
| 34 | +service.logger |
| 35 | +service.tracker |
| 36 | + |
| 37 | +/*: |
| 38 | +Not bad so far. Though that `resolveDependencies` block looks heavy. It would be cool if we can get rid of it. Alternatively you can use _constructor injection_ here, which is actually more prefereable by default but not always possible (see [circular dependencies](Circular%20dependencies)). |
| 39 | +Now let's say that you have a bunch of components in your app that require `Logger` or `Tracker` too. You will need to resolve them in a factory for each component again and again. That can be a lot of boilerplate code, simple but still duplicated. |
| 40 | + |
| 41 | +That is one of the scenarios when auto-injection can be usefull. It works with property injection and with it the previous code will transform to this: |
| 42 | +*/ |
| 43 | + |
| 44 | +class AutoInjectedServiceImp: Service { |
| 45 | + private var injectedLogger = Injected<Logger>() |
| 46 | + var logger: Logger? { get { return injectedLogger.value } set { injectedLogger.value = newValue } } |
| 47 | + |
| 48 | + private var injectedTracker = Injected<Tracker>() |
| 49 | + var tracker: Tracker? { get { return injectedTracker.value } set { injectedTracker.value = newValue } } |
| 50 | +} |
| 51 | + |
| 52 | +container.register() { AutoInjectedServiceImp() as Service } |
| 53 | + |
| 54 | +let autoInjectedService = try! container.resolve() as Service |
| 55 | +autoInjectedService.logger |
| 56 | +autoInjectedService.tracker |
| 57 | + |
| 58 | +/*: |
| 59 | +The same you can do if you already have an instance of service and just want to resolve its dependencies: |
| 60 | +*/ |
| 61 | + |
| 62 | +let providedService = AutoInjectedServiceImp() |
| 63 | +container.resolveDependencies(providedService) |
| 64 | +providedService.logger |
| 65 | +providedService.tracker |
| 66 | + |
| 67 | +/*: |
| 68 | +As you can see we added two private properties to our implementation of `Service` - `injectedLogger` and `injectedTracker`. Their types are `Injeceted<Logger>` and `Injected<Tracker>` respectively. Note that we've not just defined them as properties of those types, but defined them with some initial value. `Injected<T>` is a simple _wrapper class_ that wraps value of generic type and provides read-write access to it with `value` property. This property is defined as optional, so that when we create instance of `Injected<T>` it will have `nil` in its value. There is also another wrapper - `InjectedWeak<T>` - which in contrast to `Injected<T>` holds a week reference to its wrapped object, thus requiring it to be a _reference type_ (or `AnyObject`), when `Injected<T>` can also wrap value types (or `Any`). |
| 69 | + |
| 70 | +What is happening under the hood is that after concrete instance of resolved type is created (`Service` in that case), container will iterate through its properties using `Mirror`. For each of the properties wrapped with `Injected<T>` or `InjectedWeak<T>` it will search a definition that can be used to create an instance of wrapped type and use it to create and inject a concrete instance in a `value` property of a wrapper. The fact that wrappers are _classes_ or _reference types_ makes it possible at runtime to inject dependency in instance of resolved type. |
| 71 | + |
| 72 | +Another example of using auto-injection is circular dependencies. Let's say you have a `Server` and a `ServerClient` both referencing each other. Standard way to register such components in `DependencyContainer` will lead to such code: |
| 73 | +*/ |
| 74 | + |
| 75 | +protocol Server: class { |
| 76 | + weak var client: ServerClient? {get set} |
| 77 | +} |
| 78 | + |
| 79 | +protocol ServerClient: class { |
| 80 | + var server: Server? {get} |
| 81 | +} |
| 82 | + |
| 83 | +class ServerImp: Server { |
| 84 | + weak var client: ServerClient? |
| 85 | +} |
| 86 | + |
| 87 | +class ServerClientImp: ServerClient { |
| 88 | + var server: Server? |
| 89 | + |
| 90 | + init(server: Server) { |
| 91 | + self.server = server |
| 92 | + } |
| 93 | +} |
| 94 | + |
| 95 | +container.register(.ObjectGraph) { |
| 96 | + ServerClientImp(server: try! container.resolve()) as ServerClient |
| 97 | +} |
| 98 | + |
| 99 | +container.register(.ObjectGraph) { ServerImp() as Server } |
| 100 | + .resolveDependencies { container, server in |
| 101 | + server.client = try! container.resolve() as ServerClient |
| 102 | +} |
| 103 | + |
| 104 | +let client = try! container.resolve() as ServerClient |
| 105 | +client.server |
| 106 | + |
| 107 | +/*: |
| 108 | +With auto-injection you will have the following code: |
| 109 | +*/ |
| 110 | + |
| 111 | +class InjectedServerImp: Server { |
| 112 | + private var injectedClient = InjectedWeak<ServerClient>() |
| 113 | + var client: ServerClient? { get { return injectedClient.value } set { injectedClient.value = newValue }} |
| 114 | +} |
| 115 | + |
| 116 | +class InjectedClientImp: ServerClient { |
| 117 | + private var injectedServer = Injected<Server>() |
| 118 | + var server: Server? { get { return injectedServer.value} } |
| 119 | +} |
| 120 | + |
| 121 | +container.register(.ObjectGraph) { InjectedServerImp() as Server } |
| 122 | +container.register(.ObjectGraph) { InjectedClientImp() as ServerClient } |
| 123 | + |
| 124 | +let injectedClient = try! container.resolve() as ServerClient |
| 125 | +injectedClient.server |
| 126 | +injectedClient.server?.client === injectedClient //circular dependencies were resolved correctly |
| 127 | + |
| 128 | +/*: |
| 129 | +You can see that component registration looks much simpler now. But on the otherside it requires some boilerplate code in implementations, also tightly coupling them with Dip. |
| 130 | + |
| 131 | +There is one more use case when auto-injection can be very helpfull - when you don't create instances by yourself but system creates them for you. It can be view controllers created by Storyboards. Let's say each view controller in your application requires logger, tracker, data layer service, router, etc. You can end up with code like this: |
| 132 | +*/ |
| 133 | +container.register() { RouterImp() as Router } |
| 134 | +container.register() { DataProviderImp() as DataProvider } |
| 135 | + |
| 136 | +class ViewController: UIViewController { |
| 137 | + var logger: Logger? |
| 138 | + var tracker: Tracker? |
| 139 | + var dataProvider: DataProvider? |
| 140 | + var router: Router? |
| 141 | + |
| 142 | + //it's better not to access container directly in implementation but that's ok for illustration |
| 143 | + func injectDependencies(container: DependencyContainer) { |
| 144 | + logger = try! container.resolve() as Logger |
| 145 | + tracker = try! container.resolve() as Tracker |
| 146 | + dataProvider = try! container.resolve() as DataProvider |
| 147 | + router = try! container.resolve() as Router |
| 148 | + } |
| 149 | +} |
| 150 | + |
| 151 | +let viewController = ViewController() |
| 152 | +viewController.injectDependencies(container) |
| 153 | +viewController.router |
| 154 | + |
| 155 | +/*: |
| 156 | +With auto-injection you can replace that with something like this: |
| 157 | +*/ |
| 158 | + |
| 159 | +class AutoInjectedViewController: UIViewController { |
| 160 | + |
| 161 | + var logger = Injected<Logger>() |
| 162 | + var tracker = Injected<Tracker>() |
| 163 | + var dataProvider = Injected<DataProvider>() |
| 164 | + var router = Injected<Router>() |
| 165 | + |
| 166 | + func injectDependencies(container: DependencyContainer) { |
| 167 | + container.resolveDependencies(self) |
| 168 | + } |
| 169 | +} |
| 170 | + |
| 171 | +let autoViewController = AutoInjectedViewController() |
| 172 | +autoViewController.injectDependencies(container) |
| 173 | +autoViewController.router.value |
| 174 | + |
| 175 | +/*: |
| 176 | +In such scenario you will need to use property injection anyway, so the overhead of adding additional properties for auto-injection is smaller. Also all the boilerplate code of unwrapping injected properties (if you need that) can be moved to extension, cleaning implementation a bit. |
| 177 | + |
| 178 | +So as you can see there are certain advantages and disadvatages of using auto-injection. It makes your definitions simpler, especially if there are circular dependencies involved, and lets you get rid of giant constructors overloaded with arguments. But it requires additional properties and some boilerplate code in your implementations, makes your implementatios tightly coupled with Dip. It has also some limitations like that it requires factories for auto-injected types that accept no runtime arguments and have no associated tags to be registered in a container. |
| 179 | + |
| 180 | +So you should decide for yourself whether you prefer to use auto-injection or "the standard" way. At the end they let you achieve the same result. |
| 181 | +*/ |
| 182 | + |
| 183 | +//: [Next: Testing](@next) |
0 commit comments