# Increase Cohesion

**In short:** Increase Cohesion is one of three groups of modifiability tactics. It keeps related responsibilities together and separates unrelated ones, so future changes cost less.

## Explanation

Modifiability tactics fall into three groups: Increase Cohesion, Reduce Coupling, and Defer Binding. The SEI report motivates them with the ideas of coupling, cohesion and cost. See Coupling and Cohesion for those terms, and Modifiability Tactic for the full set.

Increase Cohesion targets one problem. A module may hold responsibilities that do not belong together. When that module must change, modification costs will likely be high.

**Split Module** is the tactic for this case. The team refactors the module to separate its responsibilities. The expected result is a lower average cost for future changes. See Split Module and Refactoring.

A practitioner summary of the SEI taxonomy places two more tactics in the cohesion group: Maintain Semantic Coherence and Abstract Common Services. Abstract Common Services hides similar services behind a common abstraction. Another source files that tactic under Reduce Coupling instead. Check which grouping a document uses.

## Example

A single "order" module handles pricing rules and also prints invoices. Any change to invoice layout risks breaking pricing. The team splits it into a pricing module and an invoicing module. Later invoice changes touch only one of them.

## Trade-offs

Structuring for modifiability can carry a runtime cost. Layered structures show this: every interaction that crosses layers pays a performance penalty. Splitting modules may add similar overhead where the pieces must now interact. Weigh that cost against the expected drop in the average cost of change. See Tactic Trade-off Balancing.



## Checks

- Modules that mix unrelated responsibilities are identified, and splitting them is considered.
- The document states which modifiability tactic group (cohesion, coupling, binding time) each tactic belongs to.
- Runtime overhead from added structure, such as layer crossings, is acknowledged.

## Related

- [Split Module](https://arc.fuet.ch/concepts/tactics/split-module.md)
- [Modifiability Tactic](https://arc.fuet.ch/concepts/tactics/modifiability-tactics.md)
- [Reduce Coupling](https://arc.fuet.ch/concepts/tactics/reduce-coupling.md)
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- [High Cohesion](https://arc.fuet.ch/concepts/principles/high-cohesion.md)
- [Refactoring](https://arc.fuet.ch/concepts/fundamentals/refactoring.md)
- [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md)
- [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md)

## Sources

- [3.5 Design Concepts to Support Modifiability | Making Design Decisions | InformIT](https://www.informit.com/articles/article.aspx?p=3197432&seqNum=5) — informit.com, accessed 2026-11-09
- [Modifiability Tactics | CMU Software Engineering Institute](https://www.sei.cmu.edu/library/modifiability-tactics/) — sei.cmu.edu, accessed 2026-11-08
- [Brad Appleton's ACME Blog: Software Modifiability Tactics](http://bradapp.blogspot.com/2008/03/software-modifiability-tactics.html) — bradapp.blogspot.com, accessed 2026-11-09