Data clumps, primitive obsession and hidden tuples
Tags: connascence, refactoring, codesmells, webdev
Published: 2022-11-03 11:43:11

---
title: Data clumps, primitive obsession and hidden tuples
published: true
description: 
tags: 
  - Connascence
  - Refactoring
  - CodeSmells 
  - webdev
canonical_url: https://codesai.com/posts/2018/08/hidden-tuples
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xa02op1rmfxbakmo7wkh.jpg
# Use a ratio of 100:42 for best results.
# published_at: 2022-11-02 16:49 +0000
---

During the writing of [one of our posts about connascence](https://dev.to/trikitrok/two-examples-of-connascence-of-position-42gg) some of us were discussing whether we could consider a [data clump](http://www.informit.com/articles/article.aspx?p=1400866&seqNum=8) a form of [Connascence of Meaning](https://dev.to/trikitrok/about-connascence-17ko) (CoM) or not. In the end, we agreed that data clumps are indeed a form of CoM and that introducing a class for the missing abstraction reduces their _connascence_ to [Connascence of Type](https://dev.to/trikitrok/about-connascence-17ko) (CoT).

I had wondered in the past why we use a similar refactoring to eliminate both [primitive obsession](http://www.informit.com/articles/article.aspx?p=1400866&seqNum=9) and _data clump_ smells. Thinking about them from the point of view of _connascence_ has helped me a lot to understand why. It also gave me an alternative path to get to the same conclusion, in which a _data clump_ gets basically reduced to _an implicit form of primitive obsession_. The reasoning is as follows:

The concept of _primitive obsession_ might be extended to consider the collections that a given language offers as primitives. In such cases, [encapsulating the collection](http://garajeando.blogspot.com.es/2013/06/encapsulating-collections.html) reifies a new concept that might attract code that didn't have where to "live" and thus was scattered all over. From the point of view of _connascence_, _primitive obsession_ is a form of CoM that we transform into CoT by introducing a new type and then we might find [Connascence of Algorithm](https://dev.to/trikitrok/about-connascence-17ko) (CoA) that we'd remove by moving the offending code inside the new type. The composing elements of a data clump only make sense when they go together. This means that **they're conceptually (but implicitly) grouped**. In this sense _a data clump could be seen as a **"hidden or implicit tuple"**_.

Having this **"hidden or implicit tuple"** in mind is now easier to see how closely related the data clump and primitive obsession smells are. In this sense, when we refactor a data clump **_what we do is removing the data clump by encapsulating a collection which is its "hidden or implicit tuple", inside a new class_**. Again, from the point of view of _connascence_, this encapsulation reduces CoM to CoT and might make evident some CoA that will make us move some behavior into the new class that becomes a [value object](https://martinfowler.com/bliki/ValueObject.html).

This **_"hidden or implicit tuple" concept_** helped me to make more explicit the mental process that was leading me to end up doing very similar refactorings to remove both code smells. I think that CoM unifies both cases much more easily than relating the two smells. The fact that the collection (the grouping of the elements of a data clump) is implicit also makes it more difficult to recognize a data clump as CoM in the first place. That's why I think that **_a data clump is a more implicit example of CoM than primitive obsession_**, and, thus, we might consider **_its CoM to be stronger than the one in primitive obsession_**.