Dependency Injection in Swift

Transcript

1. 1.

   DEPENDENCY INJECTION (DI) IN SWIFT ILYA PUCHKA (@ILYAPUCHKA) IOS DEVELOPER

   @HELLOFRESH
2. 2.

   FUNCTIONAL OR OBJECT ORIENTED?

3. 3.

   SOLID KISS DRY YAGNI RAP CQS DECORATOR FACADE ABSTRACT FACTORY

   STRATEGY ...
4. 4.

   DI SOLID

5. 5.

   WHAT IS DEPENDENCY INJECTION?

6. 6.

   In software engineering, dependency injection is a software design pattern

   that implements inversion of control for resolving dependencies. — Wikipedia
7. 7.

   “Dependency injection is really just passing in an instance variable.

   — James Shore
8. 8.

   VOODO MAGIC SLOW FRAMEWORKS ONLY FOR TESTING OVERENGINEERING

9. 9.

   > What is Dependency Injection? > How to do it?

   > How not to do it?
10. 10.

    WHY DEPENDENCY INJECTION?

11. 11.

    ABSTRACTIONS EVERYWHERE

12. 12.

    LOOSE COUPLING

13. 13.

    TEST EXTEND AND REUSE DEVELOP IN PARALLER MAINTAIN

14. 14.

    NOT JUST UNIT TESTS BUT LOOSE COUPLING

15. 15.

    FIRST STEP - PASSING INSTANCE VARIABLES

16. 16.

    SECOND STEP - ? THIRD STEP - ?

17. 17.

    PATTERNS CUSTRUCTOR INJECTION PROPERTY INJECTION METHOD INJECTION AMBIENT CONTEXT

18. 18.

    CONSTRUCTOR INJECTION class NSPersistentStore : NSObject { init(persistentStoreCoordinator root: NSPersistentStoreCoordinator?,

    configurationName name: String?, URL url: NSURL, options: [NSObject: AnyObject]?) var persistentStoreCoordinator: NSPersistentStoreCoordinator? { get } }
19. 19.

    EASY TO IMPLEMENT IMMUTABILITY

20. 20.

    PROPERTY INJECTION extension UIViewController { weak public var transitioningDelegate: UIViewControllerTransitioningDelegate?

    }
21. 21.

    LOCAL DEFAULT FOREIGN DEFAULT

22. 22.

    OPTIONALS NOT IMMUTABLE THREAD SAFETY

23. 23.

    METHOD INJECTION public protocol NSCoding { public func encodeWithCoder(aCoder: NSCoder)

    }
24. 24.

    AMBIENT CONTEXT public class NSURLCache : NSObject { public class

    func setSharedURLCache(cache: NSURLCache) public class func sharedURLCache() -> NSURLCache }
25. 25.

    CROSS-CUTTING CONCERNS > logging > analitycs > time/date > etc.

26. 26.

    PROS: > does not pollute API > dependency always available

    CONS: > implicit dependency > global mutable state
27. 27.

    SEPARATION OF CONCERNS > what concrete implementations to use >

    configure dependencies > manage dependencies' lifetime
28. 28.

    WHERE DEPENDENCIES ARE CREATED?

29. 29.

    COMPOSITION ROOT

30. 30.

    None
31. 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. 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. 33.

    The biggest challange of properly implementing DI is getting all

    classes with dependencies moved to Composition Root — Mark Seeman
34. 34.

    ANTI- PATTERNS

35. 35.

    CONTROL FREAK class RecipesService { let repository: RecipesRepository init() {

    self.repository = CoreDataRecipesRepository() } }
36. 36.

    init()

37. 37.

    STABLE OR VOLATILE

38. 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. 39.

    VOLATILE DEPENDENCIES DISABLE LOOSE COUPLING

40. 40.

    BASTARD INJECTION class RecipesService { let repository: RecipesRepository init(repository: RecipesRepository

    = CoreDataRecipesRepository()) { self.repository = repository } }
41. 41.

    FOREIGN DEFAULT

42. 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. 43.

    Pros: > Extensibility > Testability > Parallel development > Separation

    of concerns
44. 44.

    Cons: > Implicit dependencies > Hidden complexity > Tight coupling

    > Not reusable > Less maintainable
45. 45.

    > DI enables loose coupling > 4 patterns, prefer constructor

    injection > Use local defaults, not foreign > Inject volatile dependencies, not stable > Avoid anti-patterns
46. 46.

    EXPLICIT DEPENDENCIES COMPOSITION ROOT

47. 47.

    SECOND STEP - ABSTRACTIONS

48. 48.

    DEPENDENCY INVERSION PRINCIPLE (DIP)

49. 49.

    !

50. 50.

    !

51. 51.

    DI = DI PATTERNS + DIP

52. 52.

    Program to an interface, not an implementation — Design Patterns:

    Elements of Reusable Object-Oriented Software
53. 53.

    PROGRAM TO AN INTERFACE ABSTRACTION

54. 54.

    INTERFACES ARE NOT ABSTRACTIONS 1 1 http://blog.ploeh.dk/2010/12/02/Interfacesarenotabstractions/

55. 55.

    DI = DI PATTERNS + DIP

56. 56.

    THIRD STEP - INVERSION OF CONTROL

57. 57.

    DI CONTAINERS

58. 58.

    TYPHOON DIP

59. 59.

    TYPHOON http://typhoonframework.org > a lot of features > good docs

    > well maintained > continuously improved
60. 60.

    public class APIClientAssembly: TyphoonAssembly { public dynamic func apiClient() ->

    AnyObject { ... } public dynamic func session() -> AnyObject { ... } public dynamic func logger() -> AnyObject { ... } }
61. 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. 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. 63.

    let assembly = APIClientAssembly().activate() let apiClient = assembly.apiClient() as! APIClient

64. 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. 65.

    DIP https://github.com/AliSoftware/Dip > pure Swift api > cross-platform > type-safe

    > small code base
66. 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. 67.

    RESOLVE let apiClient = try! container.resolve() as APIClient

68. 68.

    AUTO-WIRING class APIClientImp: APIClient { private let _logger = Injected<Logger>()

    var logger: Logger? { return _logger.value } }
69. 69.

    AUTO-WIRING class APIClientImp: APIClient { init(session: NetworkSession) { ... }

    } container.register { APIClientImp(session: $0) as APIClient }
70. 70.

    Typhoon Dip Constructor, property, method injection ✔ ✔ Lifecycle management

    ✔ ✔ Circular dependencies ✔ ✔ Runtime arguments ✔ ✔ Named definitions ✔ ✔ Storyboards integration ✔ ✔ ----------------------------------------------------------- Auto-wiring ✔ ✔ Thread safety ✘ ✔ Interception ✔ ✘ Infrastructure ✔ ✘
71. 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. 72.

    DI ≠ DI CONTAINER

73. 73.

    DEPENDENCY INJECTION IS A MEANS TO AN END

74. 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. 75.

    THANK YOU! @ILYAPUCHKA HTTP://ILYA.PUCHKA.ME