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

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

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

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

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

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

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

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

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

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

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

12. 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
1/17/2019

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

14. 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>
See
1/17/2019

15. 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
1/17/2019

16. 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 (
1/17/2019

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

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