Category
Bloaters
Smells where methods, classes and parameter lists grow too large to read, test or change safely, usually one small addition at a time.
What these smells share
Bloaters are code that grew past the size a reader can hold in their head. No single commit caused them. Each change added a few lines or one more argument, and each was reasonable alone. The result is a method, class or signature that does too much, or a set of loose values that should have been one type.
Bloat raises the cost of every later change: more to read, more to test, more places for a bug to hide. It also hides duplication, because nobody spots the same logic in two 300-line methods.
Members
- Long Method: a function long enough that you need comments or scrolling to follow it.
- Large Class: a class with too many fields, methods or responsibilities to describe in one sentence.
- Primitive Obsession: domain concepts such as money, email or status are passed around as raw strings and numbers.
- Long Parameter List: a function takes four or more arguments, often several of the same type.
- Data Clumps: the same group of values travels together through fields and signatures without its own type.
How to choose within this category
- Start from the unit you are looking at. A function that is too long is Long Method. A type that is too wide is Large Class.
- If a signature is too long, check whether the arguments always appear together. If they do, the root cause is Data Clumps, and the long list is a symptom.
- If the clumped values are primitives that carry rules (a currency code, a range that must be ordered), the deeper smell is Primitive Obsession. Introducing a value type fixes both.
- Fix the smallest unit first. Extracting methods from a long method often reveals which fields belong together, which then shows how to split the large class.
Typical treatments
- Extract Method and Replace Method with Method Object for long functions.
- Extract Class and Extract Subclass for wide classes.
- Introduce Parameter Object and Preserve Whole Object for long signatures and clumps.
- Replace Data Value with Object for primitives that carry rules.
For agents
- Size thresholds are prompts to look, not rules. A 60-line table of constants is not a long method.
- Split by responsibility, not by line count. Each extracted piece needs a name that says what it does.
- Run the tests after each extraction. Bloated code often has hidden ordering dependencies.
See also
- DispensablesSmells where code, comments or abstractions add nothing, and removing them makes the program shorter and clearer with no loss of behavior.
- Change PreventersSmells where one change forces edits in many places, or one class changes for many unrelated reasons, making every edit slow and risky.
- Extract MethodMove a coherent fragment of a long function into its own well-named function and call it from the original place.
- Extract ClassSplit a class that does two jobs by moving one job's fields and methods into a new class it holds a reference to.
- Introduce Parameter ObjectReplace a group of parameters that always travel together with one object type, then move behavior on that group into it.
Original writing and examples. Topic coverage follows Refactoring.Guru, which explains this topic with its own illustrations.