Design patterns

I treat a pattern as a named design trade-off, not a requirement to add classes. The GoF groups are creational, structural and behavioral: construction, composition and collaboration. I first describe the repeated change or coupling problem, then choose the smallest design that addresses it. A pattern's name helps the team communicate, but I still explain ownership, failure behavior and when the design should be simplified. More patterns do not automatically make a system more maintainable.

A classic Singleton controls construction and exposes a global access point, commonly through a private constructor and Lazy instance. A DI singleton is a container lifetime: consumers explicitly request the service, and one provider supplies a shared instance. It is easier to substitute in tests but does not prohibit other construction or create one instance across servers. I still require thread-safe behavior and avoid capturing scoped dependencies. Thread-safe initialization alone does not protect mutable service state.

I use a builder when construction has several optional or dependent steps and the result benefits from validation at completion. It can make report definitions or host configuration readable without an unwieldy constructor. I make Build return a valid independent product so later builder changes cannot mutate earlier results. For a simple object with a few required values, a constructor or initializer is usually clearer. Fluent chaining is helpful syntax, but not a reason by itself to introduce a builder.

Adapter lets an incompatible interface satisfy the contract a client expects. For example, an adapter can translate a decimal amount into a legacy payment API's minor units and map its response into the application's result type. I keep external types and semantics at that boundary. It can also support an anti-corruption layer when concepts differ. I avoid empty adapters that add no translation or isolation, and I do not confuse adaptation with a facade merely simplifying a subsystem.

Strategy separates interchangeable algorithms behind one contract, so a shipping quote can use a flat fee or weight-based fee without embedding every rule in a growing switch. The client or configuration chooses the strategy. I use it when variants change independently or recur across workflows. I keep the contract's inputs and guarantees consistent across implementations. If the variation is a tiny expression or the set is small and stable, a delegate or straightforward switch can be easier to maintain.

In the classic GoF Factory Method, a base workflow calls an overridable creation method and a subclass chooses the concrete product. Abstract Factory is an object that creates a compatible family, such as database connections and commands. A simple factory centralizes selection, often with a switch, without requiring that inheritance structure. I distinguish them because many APIs called factories are not GoF Factory Method. I prefer direct injection when product creation does not need its own variation mechanism.

I check copy semantics first. A record with expression creates a shallow copy, so a referenced mutable list is still shared unless I copy it separately. Copying that list is not automatically a deep copy of mutable elements either. I define which parts should be shared, which should be independent, and whether identity must be regenerated. Immutable values make this easier. I avoid cloning resource owners such as database connections, and I do not assume ICloneable specifies deep-copy behavior.

Adapter changes the exposed interface to match a client's expectation. Decorator preserves the contract and adds composable responsibilities, such as logging or compression. Proxy generally preserves the contract while controlling access, for example by delaying creation or representing a remote object. Their code can look similar, so I explain intent rather than identifying them from a wrapper alone. I also define lifetime, disposal and failure behavior, because stacking wrappers can change ordering and hide network or storage costs.

A facade simplifies a cohesive subsystem for a particular client need, while a God object accumulates unrelated policies and workflows. I keep the facade focused on orchestration and leave domain invariants with their proper owners. If every feature depends on it and every change edits it, that is a warning sign. I also make its failure contract explicit: wrapping several calls in one method does not make them atomic or provide rollback across external systems.

Both delegate behavior, but they model different reasons for change. Strategy selects an interchangeable algorithm, usually chosen by a client or configuration, such as a shipping-fee calculation. State changes a context's behavior as its lifecycle changes, and states may choose transitions to other states. I use State when transition rules are otherwise repeated across operations. For a small stable lifecycle, an enum with explicit transition validation can be simpler. Neither pattern automatically handles persistence or concurrent transitions.

Observer publishes notifications to interested subscribers without the publisher coordinating their complete workflow. Mediator centralizes collaboration or request routing so components do not directly depend on each other. A C# event is a familiar Observer mechanism, but it is normally synchronous and not durable. MediatR is one mediation implementation, not a requirement. I choose explicit calls when there is one clear collaborator, and use notifications carefully when ordering, failures and subscriber lifetimes need well-defined behavior.

Command packages an operation's intent and inputs separately from the sender, making queuing or recording possible. Chain of Responsibility routes a request through handlers that can handle it, forward it or stop processing. They can work together, but neither guarantees safe retries, undo or atomicity. I define ordering and unhandled-request behavior for the chain, and an idempotency policy for replayable commands. For trivial direct calls, those abstractions may add more navigation than value.

I use Template Method when several implementations share an algorithm's fixed sequence and only specific steps should vary. The base class can enforce validation order while subclasses implement parsing or persistence hooks. Strategy uses composition and is easier when whole algorithms or independent steps must be selected dynamically. I avoid deep template hierarchies where hooks interact unpredictably. A simple function or an explicit pipeline can be clearer if there is little stable behavior to inherit.

I use Composite for a genuine tree where leaves and groups share meaningful operations. Bridge pays off when two independent axes, such as report type and output format, would otherwise create a subclass for every combination. Flyweight helps when many objects repeat substantial immutable state and measurements show a memory benefit. I avoid fake leaf operations, speculative variation axes and unbounded pools. Each pattern solves a specific structural problem; none is a general way to make ordinary object models better.

Visitor moves operations into separate visitor objects, with Accept selecting the correct node-specific operation through double dispatch. Adding printing or validation then means another visitor, while the node model stays stable. Adding a node type is expensive because the visitor contract and existing visitors must change. That trade-off suits expression trees better than a rapidly evolving domain hierarchy. I consider C# pattern matching for smaller cases, while remembering that arbitrary class hierarchies are not automatically checked exhaustively.

I check the hidden cost each introduces. Iterator hides representation, but lazy traversal can repeat I/O on re-enumeration and may hold resources open. Memento supports local state restoration, not reversal of an external payment, and retained snapshots need memory limits. Interpreter makes a small language explicit, but a large grammar or unbounded input needs stronger parsing and resource controls. I do not treat their names as guarantees of streaming efficiency, transactional undo or safe execution of arbitrary user rules.

Not automatically. DbContext already coordinates tracked changes and saving, and DbSet provides repository-like access. A generic wrapper can hide projections and useful EF behavior without creating a meaningful boundary. I add an aggregate-specific repository when the domain needs a focused persistence contract or loading policy. I keep its methods aligned with the aggregate and share one unit of work. I also avoid claiming provider independence while exposing IQueryable or provider-specific transaction assumptions through the abstraction.

I ask what concrete contract each pattern improves. A specification should name a reused predicate, a Result should make expected failure handling explicit, Options should group validated configuration, and a Null Object should represent an intentional safe no-op. A pipeline needs meaningful ordering and composition. I remove abstractions that only forward calls, hide missing dependencies or let callers ignore errors. I also keep infrastructure failures observable instead of converting every exception into an ordinary business rejection.