Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Cohesion Cohesion measures the strength of relationship between pieces of functionality within a given module / class

Slide 4

Slide 4 text

Cohesive Modules / Classes • Represent a single entity • They have a well defined role

Slide 5

Slide 5 text

The goal is high cohesion

Slide 6

Slide 6 text

Coupling A measure of how closely connected two modules are.

Slide 7

Slide 7 text

The goal is loose coupling

Slide 8

Slide 8 text

Tight vs Loose 
 Coupling

Slide 9

Slide 9 text

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.

Slide 10

Slide 10 text

S.O.L.I.D.

Slide 11

Slide 11 text

S.O.L.I.D • Single Responsibility Principle • Open/Closed Principle • Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle

Slide 12

Slide 12 text

Single Responsibility Principle A class should have one and only one reason to change, meaning that a class should have only one job.

Slide 13

Slide 13 text

Open/Closed Principle Objects or entities should be open for extension, but closed for modification.

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

Dependency Inversion Principle High level modules must not depend on the low level modules. Both should depend on abstractions.

Slide 17

Slide 17 text

Dependency Injection

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

DI Wiring

Slide 20

Slide 20 text

DI Maintenance We have to update everywhere we want to use the logger and all of our tests.

Slide 21

Slide 21 text

DI Container (no maintenance) We don't have information about the dependencies anymore, so we don't need to maintain the main function.

Slide 22

Slide 22 text

NG Dependency Injection

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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)

Slide 26

Slide 26 text

NG ReflectiveInjector https://github.com/angular/angular/blob/c33fda260726f5c050a75fc01fbd7a74800f8e37/ modules/%40angular/core/src/di/reflective_injector.ts#L54

Slide 27

Slide 27 text

Inject Decorator https://github.com/angular/angular/blob/f5c8e0989d85bc064f689fc3595207dfb29413f4/ modules/%40angular/core/src/di/metadata.ts#L17

Slide 28

Slide 28 text

NG DI Example

Slide 29

Slide 29 text

https://github.com/angular/angular/blob/b5c4bf1c59c56d48b8a536aa61c7bd72d94c99fc/ modules/%40angular/core/src/linker/element_injector.ts https://github.com/angular/angular/blob/b5c4bf1c59c56d48b8a536aa61c7bd72d94c99fc/ modules/%40angular/core/src/linker/view.ts#L118 1. Check for property in current Injector 2. If not found check parent Injector NG DI Example Steps

Slide 30

Slide 30 text

Providing a class ( using type annotations )

Slide 31

Slide 31 text

Providing a class (short way) ( using type annotations )

Slide 32

Slide 32 text

Alternative class provider ( using annotations )

Slide 33

Slide 33 text

More About Providers https://github.com/angular/angular/blob/ a378aab9aabd57387c9469db0d78765572216770/modules/ %40angular/core/src/di/provider.ts

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

OpaqueToken

Slide 36

Slide 36 text

Injectable Decorator https://github.com/angular/angular/blob/ f5c8e0989d85bc064f689fc3595207dfb29413f4/modules/%40angular/core/src/di/ metadata.ts#L114 If a class requires dependencies to get injected we need to make it available to the Injector

Slide 37

Slide 37 text

@Injectable

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

Services are just classes that we provide via DI

Slide 40

Slide 40 text

Demo

Slide 41

Slide 41 text

Http Service https://github.com/angular/angular/blob/master/modules/%40angular/http/src/http.ts#L103

Slide 42

Slide 42 text

Questions?