# Bloaters

> Smells where methods, classes and parameter lists grow too large to read, test or change safely, usually one small addition at a time.

- kind: category
- category: refactoring
- canonical: https://aipatterns.dev/refactoring/smells/bloaters
- inspired-by: https://refactoring.guru/refactoring/smells/bloaters

## 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](https://aipatterns.dev/refactoring/smells/long-method.md): a function long enough that you need comments or scrolling to follow it.
- [Large Class](https://aipatterns.dev/refactoring/smells/large-class.md): a class with too many fields, methods or responsibilities to describe in one sentence.
- [Primitive Obsession](https://aipatterns.dev/refactoring/smells/primitive-obsession.md): domain concepts such as money, email or status are passed around as raw strings and numbers.
- [Long Parameter List](https://aipatterns.dev/refactoring/smells/long-parameter-list.md): a function takes four or more arguments, often several of the same type.
- [Data Clumps](https://aipatterns.dev/refactoring/smells/data-clumps.md): 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](https://aipatterns.dev/refactoring/smells/long-method.md). A type that is too wide is [Large Class](https://aipatterns.dev/refactoring/smells/large-class.md).
- If a signature is too long, check whether the arguments always appear together. If they do, the root cause is [Data Clumps](https://aipatterns.dev/refactoring/smells/data-clumps.md), 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](https://aipatterns.dev/refactoring/smells/primitive-obsession.md). 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](https://aipatterns.dev/refactoring/techniques/extract-method.md) and [Replace Method with Method Object](https://aipatterns.dev/refactoring/techniques/replace-method-with-method-object.md) for long functions.
- [Extract Class](https://aipatterns.dev/refactoring/techniques/extract-class.md) and [Extract Subclass](https://aipatterns.dev/refactoring/techniques/extract-subclass.md) for wide classes.
- [Introduce Parameter Object](https://aipatterns.dev/refactoring/techniques/introduce-parameter-object.md) and [Preserve Whole Object](https://aipatterns.dev/refactoring/techniques/preserve-whole-object.md) for long signatures and clumps.
- [Replace Data Value with Object](https://aipatterns.dev/refactoring/techniques/replace-data-value-with-object.md) 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.