Dependency Injection in Swift

Transcript

1. DEPENDENCY INJECTION (DI) IN SWIFT ILYA PUCHKA (@ILYAPUCHKA) IOS DEVELOPER @HELLOFRESH
2. FUNCTIONAL OR OBJECT ORIENTED?
3. SOLID KISS DRY YAGNI RAP CQS DECORATOR FACADE ABSTRACT FACTORY STRATEGY ...
4. DI SOLID
5. WHAT IS DEPENDENCY INJECTION?
6. In software engineering, dependency injection is a software design pattern that implements inversion of control for resolving dependencies. — Wikipedia
7. “Dependency injection is really just passing in an instance variable. — James Shore
8. VOODO MAGIC SLOW FRAMEWORKS ONLY FOR TESTING OVERENGINEERING
9. > What is Dependency Injection? > How to do it? > How not to do it?
10. WHY DEPENDENCY INJECTION?
11. ABSTRACTIONS EVERYWHERE
12. LOOSE COUPLING
13. TEST EXTEND AND REUSE DEVELOP IN PARALLER MAINTAIN
14. NOT JUST UNIT TESTS BUT LOOSE COUPLING
15. FIRST STEP - PASSING INSTANCE VARIABLES
16. SECOND STEP - ? THIRD STEP - ?
17. PATTERNS CUSTRUCTOR INJECTION PROPERTY INJECTION METHOD INJECTION AMBIENT CONTEXT
18. CONSTRUCTOR INJECTION class NSPersistentStore : NSObject { init(persistentStoreCoordinator root: NSPersistentStoreCoordinator?, configurationName name: String?, URL url: NSURL, options: [NSObject: AnyObject]?) var persistentStoreCoordinator: NSPersistentStoreCoordinator? { get } }
19. EASY TO IMPLEMENT IMMUTABILITY
20. PROPERTY INJECTION extension UIViewController { weak public var transitioningDelegate: UIViewControllerTransitioningDelegate? }
21. LOCAL DEFAULT FOREIGN DEFAULT
22. OPTIONALS NOT IMMUTABLE THREAD SAFETY
23. METHOD INJECTION public protocol NSCoding { public func encodeWithCoder(aCoder: NSCoder) }
24. AMBIENT CONTEXT public class NSURLCache : NSObject { public class func setSharedURLCache(cache: NSURLCache) public class func sharedURLCache() -> NSURLCache }
25. CROSS-CUTTING CONCERNS > logging > analitycs > time/date > etc.
26. PROS: > does not pollute API > dependency always available CONS: > implicit dependency > global mutable state
27. SEPARATION OF CONCERNS > what concrete implementations to use > configure dependencies > manage dependencies' lifetime
28. WHERE DEPENDENCIES ARE CREATED?
29. COMPOSITION ROOT
31. VIPER EXAMPLE class AppDependencies { init() { configureDependencies() } func configureDependencies() { // Root Level Classes let coreDataStore = CoreDataStore() let clock = DeviceClock() let rootWireframe = RootWireframe() // List Module Classes let listPresenter = ListPresenter() let listDataManager = ListDataManager() let listInteractor = ListInteractor(dataManager: listDataManager, clock: clock) ... listInteractor.output = listPresenter listPresenter.listInteractor = listInteractor listPresenter.listWireframe = listWireframe listWireframe.addWireframe = addWireframe ... } }
32. VIPER EXAMPLE @UIApplicationMain class AppDelegate: UIResponder, UIApplicationDelegate { var window: UIWindow? let appDependencies = AppDependencies() func application( application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]?) -> Bool { appDependencies.installRootViewControllerIntoWindow(window!) return true } }
33. The biggest challange of properly implementing DI is getting all classes with dependencies moved to Composition Root — Mark Seeman
34. ANTI- PATTERNS
35. CONTROL FREAK class RecipesService { let repository: RecipesRepository init() { self.repository = CoreDataRecipesRepository() } }
36. init()
37. STABLE OR VOLATILE
38. VOLATILE DEPENDENCIES > dependency requires environment configuration (data base, networking, file system) > nondetermenistic behavior (dates, cryptography) > expected to be replaced > dependency is still in development
39. VOLATILE DEPENDENCIES DISABLE LOOSE COUPLING
40. BASTARD INJECTION class RecipesService { let repository: RecipesRepository init(repository: RecipesRepository = CoreDataRecipesRepository()) { self.repository = repository } }
41. FOREIGN DEFAULT
42. SERVICE LOCATOR let locator = ServiceLocator.sharedInstance locator.register( { CoreDataRecipesRepository() }, forType: RecipesRepository.self) class RecipesService { let repository: RecipesRepository init() { let locator = ServiceLocator.sharedInstance self.repository = locator.resolve(RecipesRepository.self) } }
43. Pros: > Extensibility > Testability > Parallel development > Separation of concerns
44. Cons: > Implicit dependencies > Hidden complexity > Tight coupling > Not reusable > Less maintainable
45. > DI enables loose coupling > 4 patterns, prefer constructor injection > Use local defaults, not foreign > Inject volatile dependencies, not stable > Avoid anti-patterns
46. EXPLICIT DEPENDENCIES COMPOSITION ROOT
47. SECOND STEP - ABSTRACTIONS
48. DEPENDENCY INVERSION PRINCIPLE (DIP)
49. !
50. !
51. DI = DI PATTERNS + DIP
52. Program to an interface, not an implementation — Design Patterns: Elements of Reusable Object-Oriented Software
53. PROGRAM TO AN INTERFACE ABSTRACTION
54. INTERFACES ARE NOT ABSTRACTIONS 1 1 http://blog.ploeh.dk/2010/12/02/Interfacesarenotabstractions/
55. DI = DI PATTERNS + DIP
56. THIRD STEP - INVERSION OF CONTROL
57. DI CONTAINERS
58. TYPHOON DIP
59. TYPHOON http://typhoonframework.org > a lot of features > good docs > well maintained > continuously improved
60. public class APIClientAssembly: TyphoonAssembly { public dynamic func apiClient() -> AnyObject { ... } public dynamic func session() -> AnyObject { ... } public dynamic func logger() -> AnyObject { ... } }
61. public dynamic func apiClient() -> AnyObject { return TyphoonDefinition.withClass(APIClientImp.self) { definition in definition.useInitializer(#selector(APIClientImp.init(session:))) { initializer in initializer.injectParameterWith(self.session()) } definition.injectProperty("logger", with: self.logger()) } }
62. public dynamic func session() -> AnyObject { return TyphoonDefinition.withClass(NSURLSession.self) { definition in definition.useInitializer(#selector(NSURLSession.sharedSession)) } } public dynamic func logger() -> AnyObject { return TyphoonDefinition.withClass(ConsoleLogger.self) { definition in definition.scope = .Singleton } }
63. let assembly = APIClientAssembly().activate() let apiClient = assembly.apiClient() as! APIClient
64. TYPHOON + SWIFT ! > Requires to subclass NSObject and define protocols with @objc > Methods called during injection should be dynamic > requires type casting > not all features work in Swift > too wordy API for Swift
65. DIP https://github.com/AliSoftware/Dip > pure Swift api > cross-platform > type-safe > small code base
66. REGISTER let container = DependencyContainer() container.register { try APIClientImp( session: container.resolve() ) as APIClient } .resolveDependencies { container, client in client.logger = try container.resolve() } container.register { NSURLSession.sharedSession() as NetworkSession } container.register(.Singleton) { ConsoleLogger() as Logger }
67. RESOLVE let apiClient = try! container.resolve() as APIClient
68. AUTO-WIRING class APIClientImp: APIClient { private let _logger = Injected<Logger>() var logger: Logger? { return _logger.value } }
69. AUTO-WIRING class APIClientImp: APIClient { init(session: NetworkSession) { ... } } container.register { APIClientImp(session: $0) as APIClient }
70. Typhoon Dip Constructor, property, method injection ✔ ✔ Lifecycle management ✔ ✔ Circular dependencies ✔ ✔ Runtime arguments ✔ ✔ Named definitions ✔ ✔ Storyboards integration ✔ ✔ ----------------------------------------------------------- Auto-wiring ✔ ✔ Thread safety ✘ ✔ Interception ✔ ✘ Infrastructure ✔ ✘
71. WHY SHOULD I BOTHER? > easy integration with storyboards > manage components lifecycle > can simplify configurations > allow interception (in Typhoon using NSProxy) > provides additional features
72. DI ≠ DI CONTAINER
73. DEPENDENCY INJECTION IS A MEANS TO AN END
74. LINKS > "Dependency Injection in .Net" Mark Seeman > Mark Seeman's blog > objc.io Issue 15: Testing. Dependency Injection, by Jon Reid > "DIP in the wild" > Non-DI code == spaghetti code?
75. THANK YOU! @ILYAPUCHKA HTTP://ILYA.PUCHKA.ME