Skip to content

Sequential Coupling

Bind the correctness or availability of one interface operation to a prior call sequence, creating a temporal dependency that is safe only when the protocol is explicit, enforceable, and aligned with the object's state machine.

Version
v2 · 2026-09-06 · History
Domain-specific #
2757
Origin domain
computer science
Subdomain
software engineering
Aliases
Temporal coupling, Call-order coupling

Core Idea

Sequential coupling is a software dependency in which an operation behaves correctly only if one or more other operations have already occurred in a required order. The interface exposes calls that appear individually available, but the object's hidden or weakly represented state makes some call sequences illegal. initialize before execute, begin before commit, or open before read are familiar shapes. If the contract is absent or unenforced, a caller can compile successfully yet encounter an exception, silent no-op, corrupt result, or delayed failure.

Scope of Application

Sequential coupling is literal in stateful APIs and components where correctness depends on client-visible operation order.

  • Initialization APIs. Configuration or setup calls must precede use.
  • Transactions. Begin, update, commit, and rollback have explicit legal states.
  • Resource lifecycles. Open/use/close or acquire/use/release protocols.
  • Builders. Some setters or phases must occur before materialization.
  • Streaming parsers and writers. Header, body, and finalization calls may be ordered.
  • UI and workflow controllers. Commands become legal only after state transitions.
  • Distributed service protocols. Authentication, negotiation, and request phases constrain messages, while network timing remains a separate concern.
  • Legacy refactoring. Detecting implicit call-order contracts from tests, exceptions, and state mutations.

Clarity

Name the component, operations, required partial or total order, state predicate established by each call, legal and illegal traces, and exact failure behavior. Separate order from wall-clock timing and concurrency. State whether the sequence is domain-essential. Show where the contract is expressed and enforced. A method name that suggests order is evidence of a possible dependency, not proof; tests or state semantics must establish that later behavior actually relies on the earlier call.

Manages Complexity

Naming sequential coupling converts scattered order bugs into a trace-and-state problem. A small state machine can enumerate legal phases, and type-level or constructor-level designs remove many invalid sequences from the caller's choice set. The model can become unwieldy if optional operations create state explosion. In those cases, grouping independent configuration, separating capabilities, and using explicit transition objects can preserve the relevant order without encoding every incidental history.

Abstract Reasoning

  1. List public operations and the state each reads or changes. 2. Generate representative call traces rather than inspect methods in isolation. 3. Identify preconditions supplied only by earlier calls. 4. Distinguish essential protocol states from accidental partial initialization. 5. Make invalid traces fail at the earliest enforceable boundary. 6. Choose constructor, factory, combined operation, runtime guard, typestate, or state-machine repair. 7. Test both legal and illegal traces, including retries and repeated calls.

Knowledge Transfer

The strict parent is Dependency: a later operation relies on a prior state-establishing operation being present and compatible, with a specifiable failure when the precondition is unmet. Sequencing describes deliberate arrangement of steps but does not by itself express that one API operation's correctness depends on another. State and State Transition helps model the protocol but is not the dependency relation itself.

Relationships to Other Abstractions

Local relationship map for Sequential CouplingParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Sequential CouplingDOMAINPrime abstraction: Dependency — is a kind ofDependencyPRIME

Current abstraction Sequential Coupling Domain-specific

Parents (1) — more general patterns this builds on

  • Sequential Coupling is a kind of Dependency Prime

    Dependency is the strict parent because the later operation relies on the prior operation's state contribution and has a concrete failure mode when it is absent.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Sequential Coupling sits in a sparse region of the domain-specific corpus (86th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08