Choosing Patterns Without Overengineering
Choosing patterns without overengineering means buying an abstraction for a specific problem you can explain. Start with the simplest implementation that preserves the required behavior and ownership. Add a pattern when it isolates real variation, clarifies a lifecycle, or reduces a demonstrated change cost.
The question is not whether patterns are good or bad. It is which responsibility the additional structure carries and what evidence would show that the structure helps. A design name cannot substitute for a clear boundary.
TL;DR
- Name the current variation or ownership problem before selecting a pattern.
- Compare a small direct implementation with the proposed abstraction.
- Evaluate change paths, invariants, failure handling, and reader effort.
- Avoid treating output equivalence as proof of maintainability.
- Revisit the boundary when requirements become clearer.
Quick Example
This Python example compares a callable-based implementation with a wrapper object for a tiny formatting task. Both produce the same declared outputs under three policies.
The checks establish output equivalence for these examples. They do not measure developer comprehension, runtime speed, or maintenance cost. The wrapper adds structure without carrying additional state or lifecycle responsibility here; another requirement could change that judgment.
Core Concepts
Software Engineering at Google frames engineering around change over time, organizational scale, and tradeoffs. That perspective makes a design's expected lifetime and change demands relevant to evaluating its structure. It does not imply that every long-lived function needs a named pattern. Software engineering and change.
Separate variation, invariant, and ownership. Variation is what legitimately changes. An invariant is what must remain true. Ownership identifies who controls state or resources over a lifecycle. A useful abstraction makes one or more of these clearer.
An interface can be small and valuable, while a short implementation can still hide dangerous coupling. Lines of code and class counts are observations, not universal design-quality scores.
Compare the actual next change
This editorial comparison map suggests experiments rather than prescribing a pattern catalog. The smallest useful boundary depends on the actual requirement.
Take the next plausible change and sketch it in both implementations. Count the meaningful responsibilities that move, not just the files edited. Ask where a reviewer would find the rule and how an error propagates.
Let responsibilities justify the abstraction
In the example, passing a callable expresses stateless rendering variation directly. If rendering later owns a connection, cache, configuration validation, or cleanup process, an object may become a clearer owner. That is a concrete reason to add structure.
Avoid building a general plugin framework merely because a second function might exist someday. A narrow seam can preserve the option to change without implementing every hypothetical lifecycle, registration, and configuration feature now.
Conversely, do not keep duplicating a consequential rule because introducing an abstraction feels unfashionable. If several paths must enforce the same invariant, a shared owner or explicit policy boundary can reduce the risk of divergence.
Keep failure and resource behavior in the comparison. A pattern that simplifies success while making cleanup, cancellation, or partial failure obscure may not improve the design. Ask who owns the work and which outcomes a caller can observe.
Test behavior and review the change path
Use tests to protect meaningful contracts while refactoring. Include boundary and failure cases rather than constructing tests that merely repeat the new class hierarchy. Output equivalence is valuable where it is the intended invariant, but it does not establish all lifecycle semantics.
Review how a new reader traces a request. Can they identify the rule, its inputs, state, and effects without jumping through unnecessary layers? An indirection that supports a real boundary can be helpful; one that only renames a call can increase effort without isolating change.
Distinguish a reusable contract from an accidental common shape. Two functions can look similar while changing for different reasons. Combining them can create condition-heavy machinery that couples otherwise independent requirements.
Do not claim a universal future saving. Record the expected change, assumptions, and maintenance obligation. If that change never occurs or the boundary proves wrong, simplify or revise the abstraction rather than defending it because it has a recognized name.
Best Practices
Write a short design note: current problem, direct option, structured option, expected change, failure behavior, and reversal condition. Scale the note to the change rather than turning every helper into an architecture review.
Prefer boundaries that can be changed incrementally. Keep clients dependent on the behavior they need, and avoid exposing internal representation merely to support hypothetical extensions.
Evaluate the team's actual codebase and maintenance capacity. Familiarity can reduce implementation risk, but it is not a reason to impose one pattern everywhere. A design should make the required work easier to understand and verify.
Common Mistakes
Bad: Introduce an interface and factory because every component should have them.
Correct: Identify the variation, ownership, or invariant each boundary carries and compare a smaller option.
Bad: Reject all abstractions as overengineering.
Correct: Add structure when it isolates a demonstrated responsibility or prevents meaningful divergence.
Bad: Treat passing unit tests as proof that the design is easier to maintain.
Correct: Preserve behavior through tests and assess the change/readability/lifecycle questions separately.
FAQ
Is a callable a design pattern?
It can implement a useful behavior-selection idea without a large hierarchy. The name matters less than the contract and responsibility it expresses.
When should a small implementation become an object?
When state, validation, resource lifetime, or a coherent interface benefits from an explicit owner. Explain that need rather than using class structure as a default quality signal.
What would reverse the choice?
New variation, duplicated invariants, an unclear lifecycle, or excessive reader effort can change the design. Preserve enough behavioral evidence to revise it safely.
Related Topics
- Design Patterns — Learn the problems patterns are intended to address.
- Software Craft — Connect structure to maintainable behavior.
- Go Concurrency and Cancellation — See why ownership and completion can justify explicit boundaries.