Inversion of Control

Since probably from Tuesday I will be busy studying Spring and other technologies, I’d like to dive in a bit and see what are the foundations of this platform. Probably this topic will gain deepness with time, but now let’s start really simple and watch one feature that makes Spring different from EJB: the Inversion of Control pattern.

Imagine to have two classes, Door and Handle. The Door has a private variable that is its Handle, and when it is instantiated with new Door(), it will build a new Handle() inside its constructor as seen in the following diagram.

If we set up things in this way, there is a tight coupling between Door and Handle, and probably every change to the Handle class (for example, adding a parameter to the constructor) will affect even the Door class: to prevent this high coupling (class Door is responsible even for the creation of the Handle), we could have a IoC framework, that will have the responsibility to inject the instance of class Handle to the class Door, confining changes of class Door to the IoC framework. Class Door will only have a private variable Handle and a method setHandle(Handle h) to get the reference from the IoC framework.

In this case, class Door and Handle are independent, since the IoC framework uses the public method of class Door to set up the Handle.However, there are three different ways to implement the IoC pattern, and every web framework uses its implementation.

Setter-based IoC: like in the example I showed before, we use a setter method to inject the referred object (Handle) in the referring object (Door). In this way, even if Handles change a lot during its lifetime in the development, we prevent Doors from changing: the main drawback is that we expose the internal variables with setter methods, violating the key OO principle of classes, that is encapsulation of data.

Constructor-based IoC: we use a constructor to set the reference of the object, so that only the creator knows about the referenced object.

Interface-based IoC: objects have to implement a specific interface of the IoC framework, so that the framework will be able to properly inject the objects. In this way there is no need for an external configuration file with the objects’ references. This locks your application to a specific IoC framework.

I am sure this approach has a lot of advantages, most of all when you don’t know much about the referred class and how it will change in the application lifecycle, but i think that in order to fully understand its potential it should be seen in a well defined context, comparing the same web application written with EJB and with Spring that accompanies the IoC pattern with principles of Aspect Oriented Programming. Hope to learn this in the future.

Filed under: Patterns, Programming, EJB, frameworks, spring

By reference or by value?

Since this is my first post, i will start really small and build from there in the future.

I’d like to show some code about how java passes arguments between functions. In the first example we will use primitive types (int, float, etc), while in the second we will use instances of some class.

First example:

public void testModifiedString() {
String originalString = "first string";
int originalNumber = 10;
StringModifier test = new StringModifier(originalString, originalNumber);
String beforeMethodOne = test.string + " " + test.number;
System.out.println(beforeMethodOne);
StringModifier.methodOne(test.string, test.number);
String afterMethodOne = test.string + " " + test.number;
System.out.println(afterMethodOne);
assertEquals(afterMethodOne, beforeMethodOne);
}

Where StringModifier has two public fields, string and number, and methodOne(String s, int number) is:

public static void methodOne(String s, int number) {
s = "string modified by methodOne";
number = 0;
}


Everyone can guess the output of this test, right? It will print out

first string 10
first string 10

suggesting us that, in Java, the primitive types are passed by value: methodOne will work on copies of its parameters, not affecting the original ones.

Let’s go one step further, and let’s try this with classes. Let’s take a look at the following short test case:

public void testMoveCircle() {
int origin = 0;
Circle myCircle = new Circle(origin, origin);
int delta = 10;
myCircle.printCoordinates();
CircleMover circleMover = new CircleMover();
circleMover.moveCircle(myCircle, delta, delta);
myCircle.printCoordinates();
assertEquals(origin + delta, myCircle.getX());
assertEquals(origin + delta, myCircle.getY());
}


We build a new Circle in the origin (0, 0) and print its coordinates. Then, we build an object CircleMover that will try to move myCircle to a new place (10, 10) and reprint the coordinates.
The output will be:

coordinates: x = 0 y = 0
coordinates: x = 10 y = 10

as we could guess from the test. But if we look inside the moveCircle‘s body, we notice something we didn’t expect:

public void moveCircle(Circle circle, int deltaX, int deltaY) {
circle.setX(circle.getX() + deltaX);
circle.setY(circle.getY() + deltaY);

//code that tries to assign a new reference to circle
circle = new Circle(0, 0);
circle = null;
}

This means that the method changes the circle’s coordinates, but also tries to modify the reference to the object passed, building a new Circle. Seeing that we can’t overwrite the reference circle, we guess that it is just a pointer passed by value to the function.

I published a gist on github if you want to let you see and download the files and/or add tests. Contact me if you find errors or want to share some ideas.

Filed under: Programming, java, parameters passing, Programming, reference