Inversion of Control for dummies! Jon Tirs en Aslak Hellesoy

1. Inversion of Control for dummies! Jon Tirsen Aslak Hellesoy

2. 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

3. IoC is not the silver bullet

4. Content • Inversion of Control • PicoContainer • Code! • Summary

5. A simple system • A Girl that kisses a Boy • How does the Girl get to know the Boy? Girl Boy ?

6. “Do it yourself” • Girl creates her own Boy… Girl Boy Make boy

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 Girl Make me a boy Make boy

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” Boy Here is a Boy, Girlie I want someone to kiss! Girl

9. So The First Principle of IoC… • Components do not reach out to the rest of the system to get dependencies new new • Instead, they are handed their dependencies by an external entity

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 Service Dependency Implementation Service • This makes multiple runtime coupling combinations easy Use this one when testing Use this one in production Use this one tomorrow

11. Boy Kitten Grandmother 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! I want someone to kiss! Girl

12. IoC Containers • They play the Hollywood role • They are reusable • PicoContainer • Avalon • XWork 1. Register components 2. Materialize and lace the components

13. Benefits of IoC IoC new new • 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

14. IoC types

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

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>

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>

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();

19. IoC type 3 • Dependant services provided through constructor • Meta-data provided by reflection only • Some configuration may be needed at deployment timeconfiguration • All components can always be used without a container

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…

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

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

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)

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

25. Extended Example FlowerMarket FlowerTicker Place buy and sell bids Listens to price changes TulipTrader

26. Extensions to PicoContainer • AOP with Nanning • Pico GUI • Configuration via XML • NanoContainer • WebWork (1&2) integration

27. Quotes • “I expected a

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

29. Where to learn more? • PicoContainer - http://picocontainer.org/ • Avalon - http://avalon.apache.org/ • Spring Framework - http://www.springframework.org/

30. Questions?