In a small piece of code
Tags: webdev, connascence, refactoring, beginners
Published: 2018-08-28 14:46:34

---
title: In a small piece of code
published: true
description: Discussing examples of Connascence of Position and Meaning. 
tags: 
  - webdev
  - connascence
  - refactoring
  - beginners
canonical_url: https://www.codesai.com/2017/08/cop-builders-and-fluid-interfaces
cover_image: https://thepracticaldev.s3.amazonaws.com/i/wi9f1vlg1v6lo8w4x95i.jpeg
---

In a [previous post](https://dev.to/trikitrok/about-connascence-17ko) 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:

```java
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<a href="#nota1"><sup>[1]</sup></a> refactoring technique, [Introduce Parameter Object](https://refactoring.com/catalog/introduceParameterObject.html), that can **transform CoP into CoN**. In this example, we introduced the *ClusteringParameters* object:

```java
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:

```java
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](https://dev.to/trikitrok/two-examples-of-connascence-of-position-42gg) for *named parameters*, we have to be careful of not accidentally sweeping hidden CoM in the form of [data clumps](http://www.informit.com/articles/article.aspx?p=1400866&seqNum=8) under the rug when we use the [Introduce Parameter Object](https://refactoring.com/catalog/introduceParameterObject.html) 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](https://en.wikipedia.org/wiki/Fluent_interface)<a href="#nota2"><sup>[2]</sup></a> which is a technique that is much more common than you think. Let's have a look at the following small piece of code:

```java
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](https://en.wikipedia.org/wiki/Fluent_interface) 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](http://wiki.c2.com/?BuilderPattern) using a *fluent interface*<a href="#nota3"><sup>[3]</sup></a>.

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

Applying the *builder pattern* provides a very specific<a href="#nota4"><sup>[4]</sup></a> [internal DSL](https://martinfowler.com/bliki/InternalDslStyle.html) 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:

```java
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:

```java
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:

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

This assertion using [hamcrest](https://code.google.com/archive/p/hamcrest/wikis/Tutorial.wiki) is so simple that the [JUnit](http://junit.org/junit5/) alternative is much clearer:

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

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

```java
//...
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:

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

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

Thanks to the semantics introduced by *hamcrest*<a href="#nota6"><sup>[6]</sup></a>, 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<a href="#nota7"><sup>[7]</sup></a>. 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](https://jasmine.github.io/):

```javascript
///...
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*:

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

This is [Mockito](http://site.mockito.org/)'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:
<div class="foot-note">
  <a name="nota1"></a> [1] See <a href="https://martinfowler.com/">Martin Fowler</a>'s <a href="https://martinfowler.com/books/refactoring.html">Refactoring, Improving the Design of Existing Code</a> book.
</div>

<div class="foot-note">
  <a name="nota2"></a> [2] Of course, <i>fluent interfaces</i> are also great in languages that provide <i>named parameters</i>.
</div>

<div class="foot-note">
  <a name="nota3"></a> [3] Curiosly there're alternative ways to implement the <i>builder pattern</i> that use <a href="https://aphyr.com/posts/321-builders-vs-option-maps">options maps</a> or <a href="https://stackoverflow.com/questions/12633670/whats-the-clojure-way-to-builder-pattern">named parameters</a>. Some time ago we wrote about an example of using the second way: <a href="https://www.codesai.com/2016/10/refactoring-tests-using-builder-functions-in-clojure-clojureScript">Refactoring tests using builder functions in Clojure/ClojureScript</a>.
</div>

<div class="foot-note">
  <a name="nota4"></a> [4] The only purpose of that DSL is creating one specific type of object.
</div>

<div class="foot-note">
  <a name="nota5"></a> [5] For us the best explanation of the <i>builder pattern</i> and how to use it to create maintanable tests is in chapter 22, <b>Constructing Complex Test Data</b>, of the wonderful <a href="http://www.growing-object-oriented-software.com/">Growing Object-Oriented Software Guided by Tests book</a>.
</div>

<div class="foot-note">
  <a name="nota6"></a> [6] <i>hamcrest</i> is a framework for writing matcher objects allowing 'match' rules to be defined declaratively. We love it!
</div>

<div class="foot-note">
  <a name="nota7"></a> [7] See our <a href="https://dev.to/trikitrok/two-examples-of-connascence-of-position-42gg">previous post about CoP</a>.
</div>

---------------------------------------

##### References.

*Books.*
* [Refactoring: Improving the Design of Existing Code](https://martinfowler.com/books/refactoring.html), Martin Fowler
* [Growing Object-Oriented Software Guided by Tests](http://www.growing-object-oriented-software.com/), Nat Pryce and Steve Freeman.
* [Refactoring Ruby](https://martinfowler.com/books/refactoringRubyEd.html), Jay Fields, Kent Beck, Martin Fowler, Shane Harvie

*Posts.*
* [Refactoring Ruby: Bad Smells in Code](http://www.informit.com/articles/article.aspx?p=1400866), Jay Fields, Kent Beck, Martin Fowler, Shane Harvie
* [Builders vs option maps](https://aphyr.com/posts/321-builders-vs-option-maps), Kyle Kingsbury
* [Refactoring tests using builder functions in Clojure/ClojureScript](https://www.codesai.com/2016/10/refactoring-tests-using-builder-functions-in-clojure-clojureScript), Manuel Rivero
* [Remove data structures noise from your tests with builders](https://www.codesai.com/2015/07/remove-data-structures-noise-from-your-tests-with-builders), Carlos Blé
* [Two examples of Connascence of Position](https://dev.to/trikitrok/two-examples-of-connascence-of-position-42gg), Manuel Rivero, Fran reyes
* [About Connascence](https://dev.to/trikitrok/about-connascence-17ko), Manuel Rivero