Upgrade to Pro — share decks privately, control downloads, hide ads and more …

4. Dependency Injection. Providers and Injectors

iliya
February 15, 2017
78

4. Dependency Injection. Providers and Injectors

iliya

February 15, 2017
Tweet

Transcript

  1. Today's Schedule 1. Cohesion and Coupling 2. S.O.L.I.D 3. Dependency

    Injection Pattern 4. Angular 2 Dependency Injection 5. Services 6. Http Service
  2. Tight Coupling • A change in one module usually forces

    changes in other modules. • Assembly of modules might require more effort and time due to the increased inter-module dependency. • A particular module might be harder to reuse and test because dependent modules must be included.
  3. S.O.L.I.D • Single Responsibility Principle • Open/Closed Principle • Liskov

    Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle
  4. Single Responsibility Principle A class should have one and only

    one reason to change, meaning that a class should have only one job.
  5. Liskov Substitution Principle Let q(x) be a property provable about

    objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
 
 Every subclass should be substitutable for their parent class.
  6. Interface Segregation Principle A client should never be forced to

    implement an interface that it doesn’t use. Clients shouldn’t be forced to depend on methods they do not use.
  7. Dependency Inversion Principle High level modules must not depend on

    the low level modules. Both should depend on abstractions.
  8. Dependency Injection It's a coding pattern in which a class

    receives its dependencies from external sources rather than creating them itself. Easy to reuse in different environments => Easy Testing
  9. DI Maintenance We have to update everywhere we want to

    use the logger and all of our tests.
  10. DI Container (no maintenance) We don't have information about the

    dependencies anymore, so we don't need to maintain the main function.
  11. NG DI • Provider - The provider knows how to

    create the objects. It takes a token and maps it to a factory function that creates the object. • Injector - The injector relies on the providers to create the instances of the dependencies our components need.
  12. Providers • Providers can be defined in a ngModule or

    inside a Component. • Providers registered in the ngModule will be available to all components within the module. • Providers registered within the Component will be available only to the Component and its children.
  13. Injectors • Each Component has its own Injector. • A

    provider lookup is performed on the parent Injector if a provider is not found.
 
 (When a Component is set as host the lookup will stop there)
  14. OpaqueToken • OpaqueToken is a preferable way to use strings

    as tokens because of possible collisions caused by multiple providers using the same string as two different tokens. https://github.com/angular/angular/blob/d169c2434e3b5cd5991e38ffd8904e0919f11788/ modules/%40angular/core/src/di/injection_token.ts#L10
  15. Services • We use them to extract functionality and maintain

    data that is needed in multiple places in our applications. • This way we keep the components focused on supporting the view. • It also makes it easier to unit test the component with a mock service.