PicoContainer

namibiancurrishInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 3 χρόνια και 10 μήνες)

88 εμφανίσεις

Inversion of Control for dummies!

Jon Tirs
en

Aslak Hellesoy

Inversion of Control (IoC) is about software components
doing what they are told, when they are told. Your OO
application could well become unmaintainable without it.

-

Paul Hammant, ThoughtWorks


IoC is not the silver bullet


Copyright ThoughtWorks, Inc.® 2003

4

Content


Inversion of Control


PicoContainer


Code!


Summary

Copyright ThoughtWorks, Inc.® 2003

5

A simple system


A Girl that kisses a Boy


How does the Girl get to know the Boy?

Girl

Boy

?

Copyright ThoughtWorks, Inc.® 2003

6

“Do it yourself”


Girl creates her own Boy…


Girl

Boy

Make

boy

Copyright ThoughtWorks, Inc.® 2003

7

Singleton or Factory


Girl asks someone else to create a Boy


Singleton is static and global


So is the kind of Boy it creates


Handier than “do it yourself”, but not flexible enough

BoyFactory

Boy

Make

boy

Girl

Make me

a boy

Copyright ThoughtWorks, Inc.® 2003

8

Inversion of Control


It’s no longer up to the Girl to find a Boy


The Girl is
given

a Boy by someone else


Thus,
Inversion of Control…


…also known as The Hollywood principle:


“Don’t call us, we call you”

Girl

Boy

Here is

a Boy,

Girlie

I want
someone
to kiss!

Copyright ThoughtWorks, Inc.® 2003

9

So The First Principle of IoC…


Components do not reach out to the rest of the system
to get dependencies



Instead, they are handed their dependencies by an
external entity

Copyright ThoughtWorks, Inc.® 2003

10

Second principle: Service/Implementation Separation


Another principle of IoC that favours loose coupling


Components should be split in two parts


Service
, a declaration of offered functionality


Implementation
, a specific implementation of a service



This makes multiple runtime coupling combinations easy

Use this one when testing

Use this one in production

Use this one tomorrow

Service

Implementation

Service

Dependency

Copyright ThoughtWorks, Inc.® 2003

11

So…


If the Girls’ primary concern is to have someone to
kiss


she should declare that she needs a
Kissable

instead of a Boy


A Girl can be fed a Boy, a Grandmother or a Kitten


Flexibility!

Girl

I want
someone
to kiss!

Boy

Kitten

Grandmother

Copyright ThoughtWorks, Inc.® 2003

12

IoC Containers


They play the Hollywood role


They are reusable


PicoContainer


Avalon


XWork

1. Register components

2. Materialize and lace the components

Copyright ThoughtWorks, Inc.® 2003

13

Benefits of IoC


Testing

becomes easy


You can test the component in isolation by stubbing out entire parts of
your application (using for example mock objects or dynamic proxies)


Maintenance

becomes easy


Loose coupling facilitates more local refactorings


Configuration

becomes easy


Component and service lacing is defined in one place


Reuse

becomes easy


A loosely coupled component can be reused outside its initial context

IoC

Copyright ThoughtWorks, Inc.® 2003

14

IoC types

Type 1

Dependencies fetched from a
ServiceManager or JNDI

Avalon, EJB/J2EE

Type 2

JavaBean setters with or without
interfaces

Spring Framework,
WebWork/XWork

Type 3

Dependencies passed in
constructor

PicoContainer,
HiveMind

Copyright ThoughtWorks, Inc.® 2003

15

IoC type 0


No IoC

Dependencies are just created

public class Girl implements Servicable {


Kissable kissable;


public void service(ServiceManager mgr) {




kissable = new Boy();


}


public void kissYourKissable() {



kissable.kiss();


}

}

No meta data, but you can’t change the dependencies


Copyright ThoughtWorks, Inc.® 2003

16

IoC type 1


Avalon example

Dependencies are fetched from a ServiceManager

public class Girl implements Servicable {


Kissable kissable;


public void service(ServiceManager mgr) {




kissable = (Kissable) mgr.lookup(“kissable”);


}


public void kissYourKissable() {



kissable.kiss();


}

}

And meta
-
data needs to be provided to hook it up


<container>


<classloader> <classpath> … </classpath> </classloader>


<component name=“kissable“ class=“Boy">





<configuration> … </configuration>


</component>


<component name=“girl" class=“Girl" />

</container>

Copyright ThoughtWorks, Inc.® 2003

17

IoC type 2


Spring example

Dependencies provided by JavaBean setters

public class Girl {


Kissable kissable;


public void setKissable(Kissable kissable) {




this.kissable = kissable;


}


public void kissYourKissable() {



kissable.kiss();


}

}

Meta
-
data or interfaces needs to be provided

<beans>


<bean id=“boy" class=“Boy"/>


<bean id=“girl“ class=“Girl">



<property name=“kissable"> <ref bean=“boy"/> </property>


</bean>

</beans>

Copyright ThoughtWorks, Inc.® 2003

18

IoC type 3


PicoContainer example

Dependencies passed to the constructor


public class Girl {


Kissable kissable;


public Girl(Kissable kissable) {




this.kissable = kissable;


}


public void kissYourKissable() {



kissable.kiss();


}

}

Meta
-
data or interfaces not needed (but supported)

PicoContainer container = new DefaultPicoContainer();

container.registerComponentImplementation(Boy.class);

container.registerComponentImplementation(Girl.class);

Girl girl = (Girl) container.getComponentInstance(Girl.class);

girl. kissYourKissable();

Copyright ThoughtWorks, Inc.® 2003

19

IoC type 3


Dependant services provided through
constructor


Meta
-
data provided by
reflection only


Some configuration may be needed at
deployment
time

configuration


All components can always be used
without a
container

Copyright ThoughtWorks, Inc.® 2003

20

Who “invented” IoC type 3?


Rachel Davies

(London
-
based Agile/XP celebrity) left
a Fermatical margin note when reviewing a chapter in
Joe Walnes
’ new book about WebWork IoC
implementation:

“Why not just use the constructor?”



She wasn’t aware of her impact until PicoContainer
was well into beta
-
release


A little bit romantic maybe…


IoC type 3 ties into a much older pattern…

Copyright ThoughtWorks, Inc.® 2003

21

IoC type 3 is based on the Good Citizen Pattern


Good Citizen Pattern

“An object is a
Good Citizen

if it is always
in a consistent state”


An IoC type 3 component
can’t

be in a inconsistent
state since all the dependencies are provided in the
constructor…


…regardless whether the component is used
within

a
container or
outside



This is almost an
architectural pattern

(not an idiom)


systems designed around this pattern are easy to read,
maintain and extend, there are no special cases in the code

Copyright ThoughtWorks, Inc.® 2003

22

Why the constructor?


It is a very
effective

way to declare your dependencies


It harmonizes perfectly with the
intuitive

notion of a
constructor


“If I give you all you need to exist, I will get back an instance
that I can immediately use”


Compile time language support for ensuring all
dependencies provided


when component is used outside container


You don’t need a container to use it


chances are
you are already doing IoC type 3

Copyright ThoughtWorks, Inc.® 2003

23

So what about PicoContainer?


PicoContainer is the
simplest

container for IoC


Pico implements
IoC type 3


Pico components are assembled by
registration


Pico components can optionally implement
lifecycle

methods (start, stop, dispose)


(oh, btw, PicoContainer is also reaaally
extensible
)

Copyright ThoughtWorks, Inc.® 2003

24

PicoContainer is simple to use

public interface Kissable {




void kiss();

}


public class Girl implements Startable {


Kissable kissable;


public Girl(Kissable kissable) {




this.kissable = kissable;


}


public void start() {



kissable.kiss();


}

}



PicoContainer container = new DefaultPicoContainer();

container.registerComponentImplementation(Boy.class);

container.registerComponentImplementation(Girl.class);



((Startable) container.getMulticaster()).start();




Specify service






Implement component




Declare dependencies





Implement lifecycle



Use dependency







Create container



Register components





Call lifecycle method


Copyright ThoughtWorks, Inc.® 2003

25

Extended Example

FlowerTicker

FlowerMarket

TulipTrader

Listens to

price changes

Place buy and

sell bids

Copyright ThoughtWorks, Inc.® 2003

26

Extensions to PicoContainer


AOP with Nanning


Pico GUI


Configuration via XML


NanoContainer


WebWork (1&2) integration


Copyright ThoughtWorks, Inc.® 2003

27

Quotes


“I expected a

Copyright ThoughtWorks, Inc.® 2003

28

Key points to remember


IoC favours


Reusability


Maintainability


Testability


Configurability


IoC can be assisted with IoC containers


Systems that show symptoms of:


Poor code reuse


Hard to maintain


Hard to test


Hard to configure

Copyright ThoughtWorks, Inc.® 2003

29

Where to learn more?


PicoContainer
-

http://picocontainer.org/


Avalon
-

http://avalon.apache.org/


Spring Framework
-

http://www.springframework.org/



Questions?