Tuesday Brown Bag Inversion of Control with Howard Abrams Or why the Factory Pattern is Bad 1/17/2019

Presentation Contents Theory behind Inversion of Control What it is and why you should use it How IoC has been implemented: Pico and Nano Containers Spring Framework Google’s Guice Ways to role yer own with scripts Alternatives 1/17/2019

OOP Failure Objects are seldom reusable Objects usually have direct dependencies Unit testing some times involves starting other objects … or even the entire application! Fault of “object normalization” Objects often can’t be replaced even if both versions adhere to the same interface 1/17/2019

The Problem Separation of code through an API Client is dependent on implementation Difficult to unit test the client without server Client Server Aserver s = new Aserver(); s.doIt(); public class Aserver { public doIt() { ... } 1/17/2019

Use an Interface Client works through an Interface Client is still dependent on implementation Still can’t unit test the client without server Client Server Interface Server public class Aserver implements Iserver { public doIt() { ... } Iserver s = new Aserver(); s.doIt(); interface Iserver { public doIt(); } 1/17/2019

Factory Pattern Create a Factory class Mediates between the client and server Can test the client with mock objects public class ServerFactory { boolean testing = false; public static Iserver getInstance() { if (testing) return new MockServer(); else return new Aserver(); } 1/17/2019

Inversion of Control Factory works for simple situations IoC works better for large applications Client does not retrieve a server instance Client is given a server instance public class Client { Iserver server; public void setServer (Iserver s) { this.server = s; } ... It is now clear from the Client’s API what the client code depends on. IoC is also called Dependency Injection Also called the Hollywood Principle or "Don't call us we'll call you”, since the client now does not reach out to find herself a service but instead is provided one 1/17/2019

IoC Package Layout Client ServerInterface Server ... Iserver server; void setServer( Iserver s) { server = s; } public class Aserver implements Iserver { public doIt() { ... } interface Iserver { public doIt(); } Unit Tests MockServer void testClient { Client client = new Client(); Iserver ts = new MockSvr(); Client.setServer(ts); ... } public class MockSvr implements Iserver { public doIt() { ... } 1/17/2019

Hooking up Client / Server Can simply create a binding class Dependency is now higher (application level) All bindings need to be explicit However, some bindings are obvious A client could require a MailServer instance, but if only one class that implements the interface is given, why require an explicit binding? Could create a client factory, but now you have same amount of code without IoC 1/17/2019

IoC Container Frameworks Build applications by binding independent components together Components are POJOs (esp. JavaBeans) Each framework binds them differently: Bindings using special Java code Specify bindings with XML or scripting lang Describe bindings with Java annotations 1/17/2019

Why use IoC Framworks? Modularize how dependencies between parts of your application are laced up To improve the testability of your code To improve component configuration Less code due to automatic binding Components have a chance at being reused It is common having the dependencies of your application components/modules scattered all over. 1/17/2019

Pico Container Uses Java code to do the bindings: The application goes through container: MutablePicoContainer pico = new DefaultPicoContainer(); pico.registerComponentImplementation(Client.class); pico.registerComponentImplementation(Interface.class, Server.class); Client c = (Client) pico.getComponentInstance(Client.class); See www.picocontainer.org 1/17/2019

See nanocontainer.codehaus.org Builds on top of Pico Container Component binding is not compiled: Done by class name (using reflection) Done by scripting languages (Groovy, Ruby) builder = new org.nanocontainer.script.groovy.NanoContainerBuilder() nano = builder.container { component(class:Girl) component(class:Boy) } See nanocontainer.codehaus.org 1/17/2019

Spring Framework Component bindings (and configuration) done using XML: <beans> <bean id=”myclient” class=”Client"> <property name="username" value="someone" /> </bean> <bean id=”myserver” class=”Server”/> </beans> http://www.theserverside.com/tt/articles/article.tss?l=SpringFramework http://www.theserverside.com/tt/articles/content/RodJohnsonInterview/JohnsonChapter4.pdf See www.springframework.org 1/17/2019

Google’s Guice Component bindings done via annotations: Default implementations of an Interface: public class Client { private final IServer service; @Inject public Client(IServer service) { this.service = service; } Annotations make it dependent on Java 5+ @ImplementedBy(ServiceImpl.class) public interface IServer { ... } See http://code.google.com/p/google-guice/ 1/17/2019

IoC Container Comparison Spring is the most complete / mature The XML file becomes unwieldy Has great web application solution Guice is young, but promising Requires Java 5 All code is in Java, however Nano’s scripting capabilities intrigue me Pico is only IoC and component lifecycle These are my own perspectives of writing quite a few Spring apps, but not using any of the others much at all. Spring is in the process of retiring the XML file for annontations as well (http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/) http://code.google.com/p/google-guice/wiki/SpringComparison 1/17/2019

Roll Yer Own - Scripts Bind components in scripts with Java 6 Component instantiation in one file, and bindings are in another (the script) ScriptEngineManager m = new ScriptEngineManager(); ScriptEngine engine = m.getEngineByName("jruby"); engine.getContext().setAttribute( ”client", new Client() ); engine.getContext().setAttribute( ”server", new Server() ); engine.eval(bindingScript, context); $client.setServer ( $server ); ... $client.doIt(); 1/17/2019

Other Options Plugin interfaces (built with Reflection) Components are built against a particular API Service Locator (e.g. JNDI) Built against API Distributed Configuration/deployment can be a nightmare JINI Really only makes sense if it is distributed 1/17/2019