Signals a code smell that suggests refactoring to improve cohesion and reduce parameter lists.

Alerts developers to consider refactoring scattered related data into a cohesive class or structure.

When the same group of variables appears together across multiple method signatures, class fields, or local variable declarations.

Software engineering, code reviews, refactoring sessions, object-oriented design.

detect data clump → create a value object or parameter object → replace multiple parameters with the new object

• parameter list
• method signature
• field declaration
• refactoring

• parameter object
• data clump

Ignoring the clump and passing variables separately, leading to scattered logic; over‑engineering by creating unnecessary classes.

Similar to Long Parameter List; contrasted with Primitive Obsession (focus on primitive types) and Feature Envy (methods using data from another class).

Coming from JavaScript: often use a plain object literal to pass many related values, which can hide data clumps but doesn't provide type safety → prefer defining a class or interface.

• Feature Envy
• Long Parameter List
• Primitive Obsession
• Switch Statements

Do not extract a class when the grouped variables are only coincidentally used together in a few methods; extracting adds unnecessary abstraction. There is no runtime performance impact, but excessive objects can increase memory usage in tight loops. The boundary condition is that the clump must appear in multiple places or evolve together; a one‑off grouping does not merit refactoring.

Eliminating data clumps improves code readability, reduces the chance of parameter ordering bugs, and makes future extensions easier.

Data clumps are like a tangled set of cords that should be bundled into a single cable.

Data clumps often signal a missing cohesive abstraction; refactoring to a value object also enables easier unit testing of related data.

Refactor using Extract Class or Introduce Parameter Object to eliminate the data clump.