# Modifiability Tactic

**In short:** Modifiability tactics are design decisions that keep the cost of changes low. They fall into three groups: increase cohesion, reduce coupling, and defer binding.

## Explanation

A tactic is a design decision that adjusts the parameters of a quality model. Modifiability tactics apply this idea to the cost of changing a system. They form three categories: increase cohesion, reduce coupling, and defer binding.

**Increase cohesion.** Cohesion describes how well the responsibilities of a module belong together (see Coupling and Cohesion). If a module mixes unrelated responsibilities, changing it will likely cost a lot. The *split module* tactic addresses this. See Split Module.

**Reduce coupling.** Coupling describes how much modules depend on each other (see Reduce Coupling). Two tactics stand out:

- *Encapsulation* adds an explicit interface to an element. The interface hides the element's implementation details.
- *Restrict dependencies* limits which modules a given module may interact with or depend on.

**Defer binding.** Binding means fixing a value or functionality in the system. These tactics differ in how late in the life cycle the binding happens:

- At compile or build time: component replacement, compile-time parameterization, and aspects.
- At deployment, startup, or initialization time: configuration-time binding and resource files.
- At runtime: discovery, interpreting parameters, shared repositories, and polymorphism.

The same SEI report also covers architectural patterns and their variants. See Architectural Tactic and Relationship between Tactics and Architectural Styles/Patterns.

## Example

A team runs an online shop. One module handles orders, invoices, and email templates. Every template change puts order logic at risk. The team splits the module so each responsibility has its own module. Each new module gets a small interface that hides its internals. Only the modules that need to talk to each other are allowed to do so. Later, the team could choose to bind some values, such as template text, at startup through a resource file instead of fixing them in code.

The three categories of modifiability tactics.

```mermaid
mindmap
  root((Modifiability tactics))
    Increase cohesion
      Split module
    Reduce coupling
      Encapsulation
      Restrict dependencies
    Defer binding
      Compile or build time
      Deployment or startup
      Runtime
```

## Checks

- The document names which modifiability tactic categories (increase cohesion, reduce coupling, defer binding) the design uses.
- Modules that mix non-cohesive responsibilities are identified and split, or the document explains why not.
- Key modules expose an explicit interface that hides implementation details.
- The document states which modules a given module may depend on.
- For each deferred-binding choice, the document states when the binding happens (build, deployment or startup, or runtime).

## Related

- [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md)
- [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md)
- [Increase Cohesion](https://arc.fuet.ch/concepts/tactics/increase-cohesion.md)
- [Reduce Coupling](https://arc.fuet.ch/concepts/tactics/reduce-coupling.md)
- [Split Module](https://arc.fuet.ch/concepts/tactics/split-module.md)
- [Coupling and Cohesion](https://arc.fuet.ch/concepts/principles/coupling-and-cohesion.md)
- [Modifiability Scenario](https://arc.fuet.ch/concepts/quality-attributes/modifiability-scenario.md)
- [Relationship between Tactics and Architectural Styles/Patterns](https://arc.fuet.ch/concepts/tactics/tactics-vs-architectural-styles-and-patterns.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-09