Learn the DI Magic

Get Started. It's Free
or sign up with your email address
Rocket clouds
Learn the DI Magic by Mind Map: Learn the DI Magic

1. Michelle Yaiser - Presenter

1.1. @MichelleYaiser

1.2. Adobe Dev Connection

1.3. [email protected]

1.4. Wrote a ton of content on adobe.com/devnet actionscript 3 documentation

1.5. Apache Flex Committer

1.6. Taught interactive development for 10 years

2. Object Oriented Initial Teaching

2.1. House Example

2.1.1. Object Structure

2.1.1.1. House

2.1.1.1.1. Bedroom

2.1.1.1.2. Bathroom

2.1.2. To add a purple bed

2.1.2.1. new house, new bedroom, new bed to change one thing

2.1.2.1.1. Bad

2.1.3. Real house doesn't build iteslef

2.1.3.1. contractor does

2.1.3.1.1. he finds all the requirements

2.1.3.1.2. all the configurations needs it

2.1.3.1.3. and builds all the pieces to put it together

2.2. Race Car Example

2.2.1. starter busted

2.2.1.1. if the car had to build all of its own pieces it would have required to buy a whole new car

2.3. Sweater Example

2.3.1. button popped off

2.3.1.1. have to create a whole new sweater

3. Seams

3.1. definition

3.1.1. seams are where objects join each other

3.1.2. are places where you can alter behavior in your program without editing that place

3.2. Factory Pattern

3.2.1. each factory only produces a specific object so a factory is needed for every class

3.2.1.1. seems weird to have a factory for one instance

3.2.1.2. lots of additional code to be tested

3.2.1.3. lots of additional code to be maintained

3.2.2. Dependency upon the factory

3.2.3. negative

3.2.3.1. still has dependency on the factory

3.2.3.2. real world objects don't always call to a factory for a replacement peice

3.3. Service Locator

3.3.1. kind of factory that can create any object rather than a specific one

3.3.1.1. reduces amount of code to maintain

3.3.2. uses lots of conditional logic

3.3.3. negative

3.3.3.1. still has a dependency on the service locator

3.3.3.2. real world objects don't know who to call to fix their dependencies

4. Inversion of Control

4.1. Control is inverted

4.1.1. framework calls me rather me calling the framework

4.2. Hollywood principle

4.2.1. don't call us we'll call you

5. Dependency Injection

5.1. Object does not call the injector

5.1.1. object doesn't even know about the injecor

5.2. Things are installed

5.2.1. passed in

5.3. Loose coupling of objects via seams

5.4. Only the root object is returned by the injector

5.5. Injectors can be context/scope specific

5.6. Benefits

5.6.1. more flexibile

5.6.2. more reusable

5.6.3. more easily maintained

6. Where to inject?

6.1. Constructor injection

6.1.1. required dependencies should be injected in the constructor

6.1.2. can't forget a dependency because the object can't be created without them

6.2. Setter injection

6.2.1. Optional dependencies should be njected in a setter

6.2.2. You can forget to call theh setter method which is okay because the dependencies are optional

6.3. Manual injection

6.3.1. you are the injector

6.3.2. you need to understand the full object graph to know all of the dependencies

6.3.2.1. knowing the object graph violates encapsulation

6.3.2.2. violating encapsulation is really problematic when code is used by many clients

6.3.3. you have to manage a lot

6.3.4. TEDIOUS

6.4. Frameworks

6.4.1. deal with all the pain of manual injection

6.4.2. if implemented correctly, you can easily switch between frameworks or manual injection

6.4.3. Fled Frameworks

6.4.3.1. Spring ActionScript

6.4.3.2. SwiftSuspenders

6.4.3.3. Swiz

6.4.3.4. SmartyPants

6.4.3.5. RobotLegs

6.4.3.6. Parsely