Sequential Coupling

Sequential Coupling is a class whose methods must be called in a specific sequence to work — for example a strict prepare() then execute() then cleanup() protocol — where the ordering is part of the contract but is enforced only by documentation or habit. It is closely related to temporal coupling, but framed as a deliberate multi-step usage protocol baked into a class's design.

Why It Happens

Classes that manage resources or multi-phase operations naturally have setup, work, and teardown phases. Exposing each phase as a public method gives callers flexibility, and the author assumes callers will follow the intended order. Frameworks and legacy components often encode such protocols (open/read/close, begin/commit). Over time the protocol becomes an implicit rule that every caller must learn.

Why It Hurts

Callers — especially new ones — skip a step or reorder calls, causing failures that depend on usage sequence and are hard to diagnose. A leaked resource from a missed cleanup(), or undefined behavior from execute() before prepare(), surfaces far from the mistake. The protocol is invisible in the type signature, so the compiler offers no help. Each caller reimplements the correct sequence, duplicating it and multiplying the chances of getting it wrong.

Warning Signs

• A documented 'usage protocol' of methods that must run in order.
• Setup/use/teardown methods all exposed publicly and independently.
• Errors when a step is skipped or invoked out of order.
• The same call sequence copied into many call sites.

Better Alternatives

Encapsulate the sequence so callers cannot get it wrong. The Template Method Pattern lets the class run the steps in the correct order internally while exposing one entry point and optional hooks. A Facade can offer a single high-level method that performs the whole protocol. The Builder Pattern handles ordered construction. Resource protocols are best wrapped so setup and teardown are automatic (try-with-resources, context managers, RAII), removing the chance to skip a phase.

How to Refactor Out of It

Collapse the multi-step protocol behind a single method that performs prepare, execute, and cleanup in order, exposing only the variation points callers genuinely need. For resource lifecycles, adopt the language's scoped-cleanup mechanism so teardown always runs. Where callers duplicate the sequence, replace each copy with the new single call. Hide or remove the individual phase methods from the public API. Add tests for the consolidated operation, including failure paths, to confirm cleanup always happens and ordering is no longer the caller's burden.