When following an iterative development methodology compilation time is a concern. In order to safely make a rapid series of small transformations to a program you need to regularly recompile and test the changes you are making. Using an IDE which can do incremental compilation is very helpful, but more complex programs with code and resource generation phases, when using languages without that kind of compilation support, and when verifying that the CI build will work, still require a fast full automated build and test cycle.

In a previous article I discussed a design principal that can be used to try to minimise the amount of time required to do a full compile of all the code in an application.

It is also possible to select design principals which will reduce the amount of recompilation required by any given code change. Conveniently it turns out that same abstract layering approach can be used here too.

We return to the example simple application;

How long is required to compile if a change is made in each component, if each component takes “m” time to compile?

If we calculate the instability of each module taking into account transitive dependencies. Abusing the definitions slightly we get:

instability = (Ce/(Ca+Ce))

Comparing the instability with the compilation time is interesting. Less stable packages should have lower compilation times, which we see here:

Reducing Recompilation Time

We can restructure our application using the dependency inversion principal. We split each layer into an abstract (interface) layer and a concrete implementation layer.

The application module becomes responsible for selecting the concrete implementation of each layer and configuring the layers of the application. This design pattern is known as Inversion of Control.

Taking into account the ability of a multi-core machine to compile modules in parallel, we get the following minimum compilation times:

The compilation time for the abstract modules is uniformly 3m, and the compilation time for the concrete modules is uniformly 2m. The application itself is always the last to be compiled so is 1m as before.

How has the design change affected the stability of the modules?

Again we see that the less stable a module is the lower its compilation time:

This example is quite simple, so we see the instability metric of the modules being dominated by the application. It does illustrate however how we can use dependency inversion to help establish an upper bound on the recompilation time for any given change in a concrete module. I will examine a more realistic example in a future article.

On a modern computer with multiple cores the total compile time of an application is related to the longest path though the dependency graph of the application.

In a statically type checked language that supports separate compilation of application components (into, for example jars or assemblies), it is generally necessary to compile the dependencies of an application or library before compiling the application or library itself.

A typical layered application might look like this:

The compile order for such an application would be library4 then library3 then library2 then library1 then application. The longest path through the dependency graph is 5.

Assuming, for simplicity, that the compile time for each module is approximately the same (m) the total compile time for the application (t) is 5m.

t = 5m

Taking Advantage of Parallel Compilation

We can restructure our application using the dependency inversion principal. We split each layer into an abstract (interface) layer and a concrete implementation layer.

The application module becomes responsible for selecting the concrete implementation of each layer and configuring the layers of the application. This design pattern is known as Inversion of Control.

The compile order for such an application is much more flexible than that of the earlier design allowing some modules to be compiled in parallel.

The longest path through the dependency graph is 3.

Assuming again, that the compile time for each module is approximately the same (m) the minimum compile time for the application (t) is 3m.

t = 3m

What is a Dependency

For the purposes of this discussion a class A has a dependency on another class B, iff you cannot compile class A without class B.

Example

class A {B b;}
class B { }

We have to compile class B before (or at the same time as) class A.

Other kinds of Dependency

Anywhere the name “B” appears in class A creates a dependency. Some other examples of dependencies are:

class A extends B { }
class A implements B { }
class A { void method(B b) { } }

Transitive Dependencies

If a class A depends on another class B which itself has dependencies then the dependencies of class B are effectively dependencies of class A

Example:

class A { B b; }
class B { C c; } 
class C { }

We have to compile class C before (or at the same time as) class B and class A.

The Problem

When class C changes, we have to recompile and retest both class A and class B. In a large system this can take a very long time. It also means that you have to know about class C in advance; you cannot decide on class C after deciding on class A.

If class C is a more concrete class then it might change more frequently than class A. This will cause class A to be recompiled/tested much more frequently than it otherwise would need to be.

The Solution

Inverting Dependencies

Have class A and class B both depend on an abstraction I. This inverts the direction of the dependency arrow on class B.

interface I { }
class A { I i; }
class B implements I { }

Breaks Transitive Dependency

The really helpful effect of this inversion is that it also breaks the transitive dependency from class A onto class B

interface I{ }
class A { I i; }
class B implements I{ C c; }
class C { }

Dependency Inversion Principle

This is an application of the Dependency Inversion Principle:

• High level modules should not depend on low level modules. Both should depend on abstractions.
• Abstractions should not depend upon details. Details should depend upon abstractions.

This article is going to look at how to implement a parameterizable algorithm so it can both conform generally to the open/closed principal and also most effectively be tested.

A common pattern for code reuse, implementation selection, or extension, is to use class inheritance and the template method pattern. This is an example of an implementation of the template method pattern with two different variations B and C:

abstract class A {
    public void doSomething() {
        doP();
        doQ();
        doR();
    }
 
    protected abstract void doP();
    protected abstract void doQ();
    protected abstract void doR();
}
 
class B extends A {
    @Override protected void doP() { /* do P the B way */}
    @Override protected void doQ() { /* do Q the B way */}
    @Override protected void doR() { /* do R the B way */}
}
 
class C extends A {
    @Override protected void doP() { /* do P the C way */}
    @Override protected void doQ() { /* do Q the C way */}
    @Override protected void doR() { /* do R the C way */}
}

Refactoring template method pattern to Strategy Pattern

We can always convert this template method pattern to a compositional pattern by performing a refactoring in the following steps (if you have member variable access there are a couple more steps, but I’ll cover them in a follow up article):

Step 1; encapsulate the construction of the B and C strategies:

abstract class A {
    public void doSomething() {
        doP();
        doQ();
        doR();
    }
 
    protected abstract void doP();
    protected abstract void doQ();
    protected abstract void doR();
}
 
class B extends A {
    public static A createB() {
        return new B();
    }
 
    @Override protected void doP() { /* do P the B way */}
    @Override protected void doQ() { /* do Q the B way */}
    @Override protected void doR() { /* do R the B way */}
}
 
class C extends A {
    public static A createC() {
        return new C();
    }
 
    @Override protected void doP() { /* do P the C way */}
    @Override protected void doQ() { /* do Q the C way */}
    @Override protected void doR() { /* do R the C way */}
}

Step 2; extract an interface for the strategy methods:

interface S {
    void doP();
    void doQ();
    void doR();
}
 
abstract class A implements S {
    private final S s = this;
 
    public void doSomething() {
        s.doP();
        s.doQ();
        s.doR();
    }
}
 
class B extends A {
    public static A createB() {
        return new B();
    }
 
    @Override public void doP() { /* do P the B way */}
    @Override public void doQ() { /* do Q the B way */}
    @Override public void doR() { /* do R the B way */}
}
 
class C extends A {
    public static A createC() {
        return new C();
    }
 
    @Override public void doP() { /* do P the C way */}
    @Override public void doQ() { /* do Q the C way */}
    @Override public void doR() { /* do R the C way */}
}

Step 3; pass the strategies into the superclass instead of using this:

interface S {
    void doP();
    void doQ();
    void doR();
}
 
final class A {
    private final S s;
 
    public A(final S s) {
        this.s = s;
    }
 
    public void doSomething() {
        s.doP();
        s.doQ();
        s.doR();
    }
}
 
class B implements S {
    public static A createB() {
        return new A(new B());
    }
 
    public void doP() { /* do P the B way */}
    public void doQ() { /* do Q the B way */}
    public void doR() { /* do R the B way */}
}
 
class C implements S {
    public static A createC() {
        return new A(new C());
    }
 
    public void doP() { /* do P the C way */}
    public void doQ() { /* do Q the C way */}
    public void doR() { /* do R the C way */}
}

Advantage of the compositional style

Less fragile

Changes to A such as new methods are much less likely to break the strategies in the compositional style.

Easier to Test

In the compositional style, class A can be tested by itself using Mocks. As can class B and class C. In the inheritance style class B and class C cannot be tested without also testing class A. This leads to duplication in the tests, as features of class A are re-tested for every subclass.

Easier to Reuse

In the compositional style class B and class C can be reused in other contexts where A is not relevant. In the inheritance style this type of reuse is not possible.

Emergent Model/Domain concepts

If class B or class C are reused in a different context, it may turn out that during subsequent refactoring they develop a new role within the system. I may even discover an important new domain concept.