Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

Learn the DI Magic by Mind Map: Learn the DI Magic
5.0 stars - 1 reviews range from 0 to 5

Learn the DI Magic

Michelle Yaiser - Presenter


Adobe Dev Connection

Wrote a ton of content on actionscript 3 documentation

Apache Flex Committer

Taught interactive development for 10 years

Object Oriented Initial Teaching

House Example

Object Structure, House, Bedroom, Dresser, Bed, Bathroom, Toilet, Sink, Faucet, Tub

To add a purple bed, new house, new bedroom, new bed to change one thing, Bad, Open closed principle, object should be open for extension but closed for modification, Single responsibility principle, a class should never have more than one responsibilty, Lots of code duplicated, Code bcomes difficult to maintain, reusability is limited

Real house doesn't build iteslef, contractor does, he finds all the requirements, all the configurations needs it, and builds all the pieces to put it together

Race Car Example

starter busted, if the car had to build all of its own pieces it would have required to buy a whole new car

Sweater Example

button popped off, have to create a whole new sweater



seams are where objects join each other

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

Factory Pattern

each factory only produces a specific object so a factory is needed for every class, seems weird to have a factory for one instance, lots of additional code to be tested, lots of additional code to be maintained

Dependency upon the factory

negative, still has dependency on the factory, real world objects don't always call to a factory for a replacement peice

Service Locator

kind of factory that can create any object rather than a specific one, reduces amount of code to maintain

uses lots of conditional logic

negative, still has a dependency on the service locator, real world objects don't know who to call to fix their dependencies

Inversion of Control

Control is inverted

framework calls me rather me calling the framework

Hollywood principle

don't call us we'll call you

Dependency Injection

Object does not call the injector

object doesn't even know about the injecor

Things are installed

passed in

Loose coupling of objects via seams

Only the root object is returned by the injector

Injectors can be context/scope specific


more flexibile

more reusable

more easily maintained

Where to inject?

Constructor injection

required dependencies should be injected in the constructor

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

Setter injection

Optional dependencies should be njected in a setter

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

Manual injection

you are the injector

you need to understand the full object graph to know all of the dependencies, knowing the object graph violates encapsulation, violating encapsulation is really problematic when code is used by many clients

you have to manage a lot



deal with all the pain of manual injection

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

Fled Frameworks, Spring ActionScript, SwiftSuspenders, Swiz, SmartyPants, RobotLegs, Parsely