In a previous post we talked about positional parameters and how they can suffer from Connascence of Position, (CoP). Then we saw how, in some cases, we might introduce named parameters to remove the CoP and transform it into Connascence of Name, (CoN), but always being careful to not hiding cases of Connascence of Meaning, (CoM). In this post we'll focus on languages that don't provide named parameters and see different techniquess to remove the CoP.

Let's see an example of a method suffering of CoP:

public class RotamerGroups {
    public Clusters generateClusters(
        List<Double> cutoffs,
        List<Double> resolutions,
        double kT,
        double entropicEnergyConstant) {
        // clustering!!
    }
}

// Usage in some other part of the code
Clusters clusters = rotamerGroups.generateClusters(
    cutoffs,
    resolutions,
    kT,
    entropicEnergyConstant);

In languages without named parameters (the example is written in Java), we can apply a classic^[1] refactoring technique, Introduce Parameter Object, that can transform CoP into CoN. In this example, we introduced the ClusteringParameters object:

public class ClusteringParameters {
    private List<Double> cutoffs;
    private List<Double> resolutions;
    private double kT;
    private double entropicEnergyConstant;

    public ClusteringParameters(List<Double> cutoffs, List<Double> resolutions,
                                double kT, double entropicEnergyConstant) {
        this.cutoffs = new ArrayList<Double>(cutoffs);
        this.resolutions = new ArrayList<Double>(resolutions);
        this.kT = kT;
        this.entropicEnergyConstant = entropicEnergyConstant;
    }

    public List<Double> cutoffs() {
        return Collections.unmodifiableList(cutoffs);
    }

    public List<Double> resolutions() {
        return Collections.unmodifiableList(resolutions);
    }

    public double kT() {
        return kT;
    }

    public double entropicEnergyConstant() {
        return entropicEnergyConstant;
    }
}

which eliminates the CoP transforming it into CoN:

public class RotamerGroups {
    public Clusters generateClusters(
        ClusteringParameters clusteringParameters) {
        // clustering!!
    }
}

// Usage in some other part of the code
Clusters clusters = rotamerGroups.generateClusters(clusteringParameters);

In this particular case, all the parameters passed to the function were semantically related, since they all were parameters of the clustering algorithm, but in many other cases all the parameters aren't related. So, as we saw in our previous post for named parameters, we have to be careful of not accidentally sweeping hidden CoM in the form of data clumps under the rug when we use the Introduce Parameter Object refactoring.

In any case, what it's clear is that introducing a parameter object produces much less expressive code than introducing named parameters. So how to gain semantics while removing CoP in languages without named parameters?

One answer is using fluent interfaces^[2] which is a technique that is much more common than you think. Let's have a look at the following small piece of code:

public class AlarmShould {
    private Alarm alarm;

    @Test
    public void be_on_when_probed_value_is_too_low() {
        alarm = anAlarm().
            usingSensor(thatProbes(5.0)).
            and(aSafetyRange().
                withLowerThreshold(5.5).
                withHigherThreshold(21)).
            build();

        alarm.check();

        assertThat(alarm.isAlarmOn(), is(true));
    }

    // more tests... 

    protected Sensor thatProbes(double value) {
        Sensor sensor = mock(Sensor.class);
        doReturn(value).when(sensor).probe();
        return sensor;
    }
}

This is just a simple test. However, just in this small piece of code, we can find two examples of removing CoP using fluent interfaces and another example that, while not removing CoP, completely removes its impact on expressiveness. Let's look at them with more detail.

The first example is an application of the builder pattern using a fluent interface^[3].

//...
alarm = anAlarm().
    usingSensor(thatProbes(5.0)).
    and(aSafetyRange().
        withLowerThreshold(5.5).
        withHigherThreshold(21)).
    build();
//...

Applying the builder pattern provides a very specific^[4] internal DSL that we can use to create a complex object avoiding CoP and also getting an expressiveness comparable or even superior to the one we'd get using named parameters.

In this case we composed two builders, one for the SafetyRange class:

public class SafetyRangeBuilder {
    private double lowerThreshold;
    private double higherThreshold;

    public static SafetyRangeBuilder aSafetyRange() {
        return new SafetyRangeBuilder();
    }

    public SafetyRangeBuilder withLowerThreshold(double lowerThreshold) {
        this.lowerThreshold = lowerThreshold;
        return this;
    }

    public SafetyRangeBuilder withHigherThreshold(double higherThreshold) {
        this.higherThreshold = higherThreshold;
        return this;
    }

    public SafetyRange build() {
        return new SafetyRange(lowerThreshold, higherThreshold);
    }
}

and another for the Alarm class:

public class AlarmBuilder {
    private SafetyRangeBuilder safetyRangeBuilder;
    private Sensor sensor;

    public static AlarmBuilder anAlarm() {
        return new AlarmBuilder();
    }

    public AlarmBuilder usingSensor(Sensor sensor) {
        this.sensor = sensor;
        return this;
    }

    public AlarmBuilder and(SafetyRangeBuilder safetyRangeBuilder) {
        this.safetyRangeBuilder = safetyRangeBuilder;
        return this;
    }

    public Alarm build() {
        return new Alarm(sensor, safetyRangeBuilder.build());
    }
}

Composing builders you can manage to create very complex objects in a maintainable and very expressive way.

Let's see now the second interesting example in our small piece of code:

//...
assertThat(alarm.isAlarmOn(), is(true));
//...

This assertion using hamcrest is so simple that the JUnit alternative is much clearer:

//...
assertTrue(alarm.isAlarmOn());
//...

but for more than one parameter the JUnit interface starts having problems:

//...
AsserEqual("hola", "hola");
//...

Which one is the expected value and which one is the actual one? We never manage to remember...

Using hamcrest removes that expressiveness problem:

///...
assertThat("hola", is(equalTo("hola")));

assertThat("hola", is("hola")); // a less verbose way
///...

Thanks to the semantics introduced by hamcrest^[6], it's very clear that the first parameter is the actual value and the second parameter is the expected one. The internal DSL defined by hamcrest produces declarative code with high expressiveness. To be clear hamcrest is not removing the CoP, but since there are only two parameters, the degree of CoP is very low^[7]. The real problem of the code using the JUnit assertion was its low expressiveness and using hamcrest fixes that.

For us it's curious to see how, in trying to achieve expressiveness, some assertion libraries that use fluent interfaces have (probably not being aware of it) eliminate CoP as well. See this other example using Jasmine:

///...
expect(findPositionsOfCapitalLetters("BAsrwQMPaZ")).toEqual([0, 1, 5, 6, 7, 9]);
///...

Finally, let's have a look at the last example in our initial small piece of code which is also using a fluent interface:

//...
doReturn(value).when(sensor).probe();
//...

This is Mockito's way of defining a stub for a method call. It's another example of fluent interface which produces highly expressive code and avoids CoP.

Summary.

We started seeing how, in languages that don't allow named parameters, we can remove CoP by applying the Introduce Parameter Object refactoring and how the resulting code was much less expressive than the one using the Introducing Named Parameters refactoring. Then we saw how we can leverage fluent interfaces to remove CoP while writing highly expressive code, mentioned internal DSLs and showed you how this technique is more common that one can think at first by examining a small piece of code.

Footnotes:

[1] See Martin Fowler's Refactoring, Improving the Design of Existing Code book.

[2] Of course, fluent interfaces are also great in languages that provide named parameters.

[3] Curiosly there're alternative ways to implement the builder pattern that use options maps or named parameters. Some time ago we wrote about an example of using the second way: Refactoring tests using builder functions in Clojure/ClojureScript.

[4] The only purpose of that DSL is creating one specific type of object.

[5] For us the best explanation of the builder pattern and how to use it to create maintanable tests is in chapter 22, Constructing Complex Test Data, of the wonderful Growing Object-Oriented Software Guided by Tests book.

[6] hamcrest is a framework for writing matcher objects allowing 'match' rules to be defined declaratively. We love it!

[7] See our previous post about CoP.

References.

Books.

• Refactoring: Improving the Design of Existing Code, Martin Fowler
• Growing Object-Oriented Software Guided by Tests, Nat Pryce and Steve Freeman.
• Refactoring Ruby, Jay Fields, Kent Beck, Martin Fowler, Shane Harvie

Posts.

• Refactoring Ruby: Bad Smells in Code, Jay Fields, Kent Beck, Martin Fowler, Shane Harvie
• Builders vs option maps, Kyle Kingsbury
• Refactoring tests using builder functions in Clojure/ClojureScript, Manuel Rivero
• Remove data structures noise from your tests with builders, Carlos Blé
• Two examples of Connascence of Position, Manuel Rivero, Fran reyes
• About Connascence, Manuel Rivero