Month: April 2014

Dependency Injection with Google Guice

One of the problems that we get in software development, specifically in the design of software classes, is that of the connection between classes. If one class uses another directly, even though it works, this can cause problems later on and is known as “close coupling”. Here is a mundane example:

//a really dumb message sending class
public class MessageSender {
    public void sendMessage(String message) {
        System.out.println(message);
    }
}

//another dumb class that uses the message sender
public class MessageUser {
    //a reference to the sender object
    private MessageSender messageSender;
    //the message sender object is created in the constructor
    public MessageUser() {
        this.messageSender = new MessageSender();
    }
    //send the message via the sender
    public void sendMessage(String message) {
        messageSender.sendMessage(message);
    }
}

//the main class that uses the message classes
public class MessageMain {
    public static void main(String[] args) {
        MessageUser messageUser = new MessageUser();
        messageUser.sendMessage("This is a test");
    }
}

OK, this is really mundane, but can see that MessageUser cannot use any other way of sending messages. If you want to use another means, say email, you’d have to either change what MessageSender does or change MessageUser to use a different class, call it EMailSender. However, we can now use an interface instead of a class:

public interface MessageSender {
    public void sendMessage(String message);
}

//an implementation of the interface
public class SystemMessageSender implements MessageSender {
    public void sendMessage(String message) {
        System.out.println(message);
    }
}

You still have to change MessageUser, but to use an interface given to, or “injected” into, the MessageUser object via the constructor:

public class MessageUser {
    //a reference to the interface
    private MessageSender messageSender;
    //the interface is sent to the object using the constructor
    public MessageUser(MessageSender messageSender) {
        this.messageSender = messageSender;
    }
    
    public void sendMessage(String message) {
        messageSender.sendMessage(message);
    }
}

This works if we then, in the main class, create the object that implements the MessageSender and pass it to, or inject it into, the MessageUser object:

public class MessageMain {
    public static void main(String[] args) {
        SystemMessageSender messageSender = new SystemMessageSender();
        MessageUser messageUser = new MessageUser(messageSender);
        messageUser.sendMessage("This is a test");
    }
}

Now if we want to have MessageUser send emails we create a class which also implements the MessageSend interface:

//an implementation of the interface
public class EMailMessageSender implements MessageSender {
    public void sendMessage(String message) {
        EMail.textMessage(message);
    }
}

All that then has to be done is create an object of this class in the main class and then pass it to MessageUser, as before:

        EMailMessageSender messageSender = new EMailMessageSender();
        MessageUser messageUser = new MessageUser(messageSender);
        messageUser.sendMessage("This is a test");

This technique, known as Dependency Injection, is quite an important design pattern and is mandatory in certain frameworks, such as Spring.

Introducing Google Guice

So far, so good, and it’s difficult to see how this can be really improved upon. However, Guice (pronounced with a J rather than a G) does for dependency injection what Mockito does for unit testing. To introduce Guice into the above example, we have to create another class, an extension of Guice’s AbstractModule class:

public class MessageModule extends AbstractModule {
    protected void configure() {
        bind(MessageSender.class).to(SystemMessageSender.class);
    }
}

You can sort-of see what’s going on. The module is responsible for creating the class that implements the interface, so whenever the interface is used, the object is bound to it. The magic happens in the Injector, used in the main class:

        Injector injector = Guice.createInjector(new MessageModule());
        MessageUser messageUser = injector.getInstance(MessageUser.class);
        messageUser.sendMessage("This is a test");

Notice that the module hasn’t been told about MessageUser, so the Injector is figuring out it’s dependencies from the constructor of the class, and this also has to change using the @Inject annotation:

    @Inject
    public MessageUser(MessageSender messageSender) {
        this.messageSender = messageSender;
    }

Now all this doesn’t seem like a big deal, if anything we’ve added lines and classes, but if now want to change it to send emails, all you have to do is change the Module:

public class MessageModule extends AbstractModule {
    protected void configure() {
        bind(MessageSender.class).to(EMailMessageSender.class);
    }
}

This concentrates the dependecy injection in one place, the module, which is acting as a sophisticated class factory. Guice is useful if you’ve got a lot of classes with umpteen dependencies and can save you a lot of work.

Mockito Spies

That is the collective noun, not the verb, although I suppose Mockito is spying…

Spies are used to make existing classes into Mockito classes. Say your class under test hooks into a Java listener, so you want some kind of dummy listener for it to hook into. You can’t do this with Mockito (at least I can’t find a way), but you can make your own:


//listener interface
public interface SomethingListener {
    //change that sends the event
    public void somethingChanged(EventObject e);
}

//our little dummy listener provider
public class DummyListenerProvider {

    private SwitchListener listener;

    //this is used by the class under test
    public void addSwitchListener(SwitchListener listener) {
        this.listener = listener;
    }

    //send event, saying the class is the source
    public void triggerEvent() {
        this.listener.somethingChanged(new EventObject(this));
    }

    //used by the event consumer when the event occurs
    public void switchMeOn(boolean isTrue) {
    }
}

Cool, but you still want all the nice little trinkets that come with the Mockito objects. This is where spies come in. You just wrapper the class using spy instead of mock:


DummyListenerProvider spyListenerProvider = spy(new DummyListenerProvider());

ClassUnderTest underTest = new ClassUnderTest(spyListenerProvider);

spyListenerProvider.triggerEvent();

verify(spyListenerProvider).switchMeOn(true);

Mockito – An Elegant Stub for a More Civilised Age

In software development, we make use of something called “stubs”. These are bits of code that don’t do anything at the moment, but allow us to continue coding elsewhere as if they do. They are also used in testing to substitute for more complex objects, and this is where “mocking” (creating “mock” objects) has been developed in object-oriented programming and test-driven development.

As an extension to the college work I’ve been doing, I’ve been looking into using mock libraries for unit testing and I’ve come across Mockito:

The mock objects it creates are, well, amazing to say the least. Say we’ve got an interface that, in turn, allows us to create a read I/O stream and a write I/O stream, for networking. The interface would look something like this:

//simple interface wrapper around a network socket
public interface MySocket {
    //creates a read I/O stream
    public BufferedReader getBufferedReader() throws IOException;
    //creates a write I/O stream
    public PrintWriter getPrintWriter() throws IOException;
    //indicates that a connection has been successfully made
    public boolean isConnected();
    //closes the connection
    public void close() throws IOException;
}

Now I can actually mock this interface with Mockito in the unit test:

import static org.mockito.Mockito.*;
...
MySocket socket = mock(MySocket.class);

You can now use this mock socket interface in whatever need the interface, so:

SocketThread socketThread = new SocketThread(socket);

Now, unfortunately, the mock doesn’t really do anything other than just record what happens to it. Say SocketThread calls socket.close internally when it runs:

//this is in SocketThread.run
socket.close();
...
//if this isn't true, you'll get an exception
verify(socket).close();

Useful, but it becomes a bit more powerful when we add mocks for the input and output streams:

PrintWriter printWriter = mock(PrintWriter.class);
BufferedReader bufferedReader = mock(BufferedReader.class);
when(socket.getBufferedReader()).thenReturn(bufferedReader);
when(socket.getPrintWriter()).thenReturn(printWriter);

You can control exactly what the mock does and when it does it. Very useful for unit testing (and I haven’t even begun to use all it’s capabilities).