| Start |
|---|
Dependency Injection with View Controllers Dependenct Injection IntroAn application is composed of many objects that collaborate with each other. Objects usually depend on other objects to perform some task. When an object is responsible for referencing its own dependencies it leads to a highly coupled, hard-to-test and hard-to-change code. Dependency injection is a software design pattern that implements inversion of control for resolving dependencies. An injection is passing of dependency to a dependent object that would use it. This allows a separation of client's dependencies from the client's behaviour, which allows the application to be loosely coupled. Not to be confused with the above definition - a dependency injection simply means giving an object its instance variables. It's that simple, but it provides a lot of benefits:
There are three most commonly used ways Dependency Injection (DI) can be implemented in an application:
There is an interesting article (opens new window) with links to more articles about Dependency Injection so check it out if you want to dig deeper into DI and Inversion of Control principle. Let's show how to use DI with View Controllers - an every day task for an average iOS developer. Example Without DIWe'll have two View Controllers: LoginViewController and TimelineViewController. LoginViewController is used to login and upon successful loign, it will switch to the TimelineViewController. Both view controllers are dependent on the FirebaseNetworkService. LoginViewController TimelineViewController FirebaseNetworkService This example is very simple, but let's assume you have 10 or 15 different view controller and some of them are also dependent on the FirebaseNetworkService. At some moment you want to change Firebase as your backend service with your company's in-house backend service. To do that you'll have to go through every view controller and change FirebaseNetworkService with CompanyNetworkService. And if some of the methods in the CompanyNetworkService have changed, you'll have a lot of work to do. Unit and UI testing is not the scope of this example, but if you wanted to unit test view controllers with tightly coupled dependencies, you would have a really hard time doing so. Let's rewrite this example and inject Network Service to our view controllers. Example with Dependancy InjectionTo make the best out of the Dependency Injection, let's define the functionality of the Network Service in a protocol. This way, view controllers dependent on a network service won't even have to know about the real implementation of it. Add an implementation of the NetworkService protocol: Let's change LoginViewController and TimelineViewController to use new NetworkService protocol instead of FirebaseNetworkService. LoginViewController TimelineViewController Now, the question is: How do we inject the correct NetworkService implementation in the LoginViewController and TimelineViewController? Since LoginViewController is the starting view controller and will show every time the application starts, we can inject all dependencies in the AppDelegate. In the AppDelegate we are simply taking the reference to the first view controller (LoginViewController) and injecting the NetworkService implementation using the property injection method. Now, the next task is to inject the NetworkService implementation in the TimelineViewController. The easiest way is to do that when LoginViewController is transitioning to the TimlineViewController. We'll add the injection code in the prepareForSegue method in the LoginViewController (if you are using a different approach to navigate through view controllers, place the injection code there). Our LoginViewController class looks like this now: We are done and it's that easy. Now imagine we want to switch our NetworkService implementation from Firebase to our custom company's backend implementation. All we would have to do is: Add new NetworkService implementation class: Switch the FirebaseNetworkServiceImpl with the new implementation in the AppDelegate: That's it, we have switched the whole underlaying implementation of the NetworkService protocol without even touching LoginViewController or TimelineViewController. As this is a simple example, you might not see all the benefits right now, but if you try to use DI in your projects, you'll see the benefits and will always use Dependency Injection. |
| Dependency Injection Types This example will demonstrate how to use Dependency Injection (DI) design pattern in Swift using these methods:
Example Setup without DIInitializer Dependency InjectionAs the name says, all dependencies are injected through the class initializer.
To inject dependencies through the initializer, we'll add the initializer to the Train class now looks like this: When we want to create an instance of the Train class we'll use initializer to inject a specific Engine implementation: NOTE: The main advantage of the initializer injection versus the property injection is that we can set the variable as private variable or even make it a constant with the Properties Dependency InjectionDI using properties is even simpler that using an initializer. Let's inject a PassengerCar dependency to the train object we already created using the properties DI: That's it. Our train's Method Dependency InjectionThis type of dependency injection is a little different that the previous two because it won't affect the whole object, but it will only inject a dependency to be used in the scope of one specific method. When a dependency is only used in a single method, it's usually not good to make the whole object dependent on it. Let's add a new method to the Train class: Now, if we call the new Train's class method, we'll inject the |
Read Article
https://develop.horje.com/learn/1434/reference