In the previous posts, we introduced the Connascence model as a model of coupling and elaborated connascence by name, type, meaning, position, algorithm, execution order, timing, and value. In this post, we will discuss Connascence by Identity.
Connascence is a model for reasoning about coupling and defines three dimensions of coupling: strength, degree and distance, as the picture below shows.
Connascence by Identity
Connascence by Identity means that two elements need to agree on the identity of something, i.e. they need to make sure they are using the exact same thing or instance.
When we create a new object and subsequently use that object, we have Connascence by Identity between the creation and usage parts of the code. The code shown below knows exactly which instance it is using, namely the one it has created itself.
1
2
3
var p = new Person();
p.doSomething();
return p;
Another example: the this or self reference in instance methods always refers to the object the method was invoked on. This coupling to identity is inevitable in this case, but also quite harmless because it is local - all contained within the same class.
These examples show that there will always be some Connascence by Identity in our code: the identity of a variable is known within its scope. If we keep the scope small, the impact is low and the connascence is well manageable. The larger the scope, the nastier it gets. This makes global variables for example problematic from a coupling point of view.
Singletons
Over-usage of the Singleton design pattern is an example of Connascence by Identity getting tricky. The intent of this pattern is to ensure there is only a single instance of a specific object. The solution is to make it difficult or impossible to create multiple instances.
Most of the code using the instance does not care about what specific instance it is using. It just wants to do its thing on whatever instance it receives. It should not know about creation of the instances and the singleton requirement. In practice, we see that singletons are accessed all over the place, introducing a lot of unnecessary identity coupling.
The example below shows code using the singleton construct directly, because it needs a TrackingCache instance. It uses the singleton as a global variable, not having to think about how dependencies are injected.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class VehicleMessageDecoder : MessageDecoder
{
public void handleMessage(byte identification, byte[] message, int length)
{
switch (decodingState) {
case WAITING_FOR_INITIALFRAME:
if (message[Protocol.FrameTypeIndex] == Protocol.FullFrame) {
currentEntry = TrackingCache.getInstance().createCacheEntry(decoderId);
// ...
}
break;
}
}
}
This introduces unnecessary, tight coupling, specifically increasing the degree of coupling on the singleton instance. Code that does not care about the specific instance gets burdened with this knowledge, making it hard to test.
Managing Connascence by Identity
To reduce Connascence by Identity in a component, we apply dependency injection, by either wiring through the constructor or passing the dependency as a function parameter.
This works well e.g. with Hexagonal Architecture. Instantiating services and adapters takes place in one place, in a main function or some Spring configuration code. These are injected into the rest of the code, which takes these as explicit dependencies. This reduces the identity coupling to a single place in the code.
Whenever Connascence by Identity is unavoidable, we try to reduce scope and keep it local, within a module, class or function.
What’s next
This post is part of a series on connascence and coupling. In the next post, we will focus on what we can to manage connascence and coupling in our software.
- Part 1 - Introduction
- Part 2 - Connascence by Name and Type
- Part 3 - Connascence by Meaning
- Part 4 - Connascence by Position
- Part 5 - Connascence by Algorithm
- Part 6 - Connascence by Execution Order
- Part 7 - Connascence by Timing
- Part 8 - Connascence by Value
- Part 9 - Connascence by Identity
- Part 10 - Heuristics for managing coupling
Credits: spiderweb thumbnail Photo by George Rosema on Unsplash
RSS feed