Compare revisions

Programming Patterns

Body changes between the two selected stored revisions. Code is not executed.

Before: full revision: 2026-10-24 18:08:33 UTC After: full revision: 2026-10-26 00:23:27 UTC

9 changed sections

− Removed+ Added42 unchanged content blocks omitted.

Content blocks 1-2 → 1-2

Programming patterns are names given to frequently recurring design problems. Quite a few people argue that patterns are used as rote memorization and are therefore harmful, or that they were just a passing trend. However, the real advantage of programming patterns is that they reduce the cost of communication. Suppose an output component keeps gaining conditionals for ~~different~~ ~~formats~~. ~~Moving~~ ~~each~~ conversion into a ~~function~~ or ~~object~~ ~~lets~~ ~~the~~ ~~format~~ change while the output code stays ~~the~~ ~~same.~~ ~~This~~ ~~solution~~ ~~structure~~ is ~~called~~ the Strategy pattern.

Programming patterns are names given to frequently recurring design problems. Quite a few people argue that patterns are used as rote memorization and are therefore harmful, or that they were just a passing trend. However, the real advantage of programming patterns is that they reduce the cost of communication. The name comes last. What comes first is a concrete annoyance in the code. Suppose an output component keeps gaining conditionals, one for each new format. Every new format means reopening output code that already works. If you split the conversion rules into separate functions or objects and pass them in, you can change the format while the output code stays as it is; that arrangement is what we call the Strategy pattern.

Content blocks 4-7 → 4-7

"Let's wrap the external SDK with an Adapter pattern" means fitting an external library's calling conventions to the contract our own code uses. "A Query Facade works better than a Repository for this query" puts the focus on producing the result a screen needs, rather than on loading and saving business objects. Such names shorten the discussion when the team shares an understanding of the problem and the roles. ~~Use this~~ page to ~~find~~ a pattern for the problem you are facing. ~~Start~~ ~~with~~ a situation in the selection ~~guide~~, then ~~follow~~ the individual article to see which roles it separates and why, ~~with~~ ~~examples~~. ~~When~~ ~~looking~~ at a pattern, ~~you~~ ~~should~~ ~~think~~ ~~about~~ ~~the~~ ~~following~~ ~~before~~ ~~focusing~~ on ~~its~~ name.

"Let's wrap the external SDK with an Adapter pattern" means fitting an external library's calling conventions to the contract our own code uses. The contract is just the shape of the call our code expects. "A Query Facade works better than a Repository for this query" puts the focus on producing the result a screen needs, rather than on loading and saving business objects. A different name draws a different boundary around responsibility. Such names shorten the discussion when the team shares an understanding of the problem and the roles. This page is a guide to finding the pattern article you need for the problem you are facing. Choose the closest situation in the selection table below, then read the individual article to see, with examples, which roles it separates and why. The names above all started from a concrete annoyance. Before you pick a pattern name, work out what is actually painful in the code right now. The name comes after that.

Content blocks 11 → 11

A programming idiom is a small, natural expression specific to a particular language. A pattern is larger, typically addressing relationships among multiple objects, modules, or layers.

A programming idiom is a small, natural expression specific to a particular language. A pattern is larger, typically addressing relationships among multiple objects, modules, or layers. Using the two interchangeably blurs what is actually being changed.

Content blocks 13-14 → 13-14

Even the same Strategy ~~Pattern~~ looks different ~~across~~ ~~languages~~. Java and C# ~~can~~ ~~receive~~ an object ~~implementing~~ an interface; Python ~~can~~ ~~receive~~ a function or an object that provides the required behavior. Keep the contract the component ~~needs~~, ~~while~~ ~~expressing~~ it ~~through~~ the language's idioms.

Even the same Strategy pattern looks different in each language. Java and C# let you pass an object that implements an interface, while Python lets you pass a function or an object that provides the required behavior. Keep the contract the component uses, but express it the way the language's idioms favor.

Content blocks 17 → 17

GoF Category | ~~Representative~~ ~~Patterns~~ | Rough Concern Creational Pattern | ~~Factory Method,~~ Abstract Factory, Builder, ~~Prototype~~, Singleton | How to create objects Structural Pattern | Adapter, ~~Decorator, Facade, Proxy,~~ Bridge, ~~Composite~~, Flyweight | How to assemble objects Behavioral Pattern | ~~Strategy,~~ ~~State,~~ ~~Observer~~, Command, ~~Template~~ ~~Method~~, ~~Iterator~~, Visitor | How objects collaborate

GoF Category | All 23 patterns | Rough Concern Creational Pattern | Abstract Factory, Builder Factory Method, Prototype Singleton | How to create objects Structural Pattern | Adapter, Bridge Composite, Decorator Facade, Flyweight Proxy | How to assemble objects Behavioral Pattern | Chain of Responsibility, Command Interpreter, Iterator Mediator, Memento Observer, State Strategy, Template Method Visitor | How objects collaborate

Content blocks 21 → 21

The text is unchanged, but footnotes, formatting or block attributes have changed.

Content blocks 23 → 23

The text is unchanged, but footnotes, formatting or block attributes have changed.

Content blocks 25 → 25

The text is unchanged, but footnotes, formatting or block attributes have changed.

Content blocks 30-31 → 30-31

Practical selection ~~guide~~ When you see this problem | Start with this pattern Inheritance hierarchies grow too deep | Composition A policy or algorithm changes frequently | Strategy Pattern The shape of an external SDK spreads into internal code | Adapter Pattern Subsystem call sequences become complex | Facade Pattern You want to add extra behavior without modifying the original object | Decorator Pattern Nested if blocks grow too deep | Guard Clause The caller must handle failures directly | Result Pattern Per-state behavior and transitions are complex | State Pattern One object's changes must notify several receivers | Observer Pattern DB details are leaking into domain code | Repository Pattern Screen queries are forced to drag along the domain model | Query Facade External calls fail occasionally | Retry + Timeout A failure in an external dependency is bringing down your system | Circuit Breaker The same data is read repeatedly | Cache-Aside

Practical selection table When you see this problem | Start with this pattern Inheritance hierarchies grow too deep | Composition A policy or algorithm changes frequently | Strategy Pattern The shape of an external SDK spreads into internal code | Adapter Pattern Subsystem call sequences become complex | Facade Pattern You want to add extra behavior without modifying the original object | Decorator Pattern Nested if blocks grow too deep | Guard Clause The caller must handle failures directly | Result Pattern Per-state behavior and transitions are complex | State Pattern One object's changes must notify several receivers | Observer Pattern DB details are leaking into domain code | Repository Pattern Screen queries are forced to drag along the domain model | Query Facade External calls fail occasionally | Retry + Timeout A failure in an external dependency is bringing down your system | Circuit Breaker The same data is read repeatedly | Cache-Aside

Programming Patterns

Body changes between the two selected stored revisions. Code is not executed.

9 changed sections

− Removed+ Added42 unchanged content blocks omitted.

Content blocks 1-2 → 1-2

Programming patterns are names given to frequently recurring design problems. Quite a few people argue that patterns are used as rote memorization and are therefore harmful, or that they were just a passing trend. However, the real advantage of programming patterns is that they reduce the cost of communication. The name comes last. What comes first is a concrete annoyance in the code. Suppose an output component keeps gaining conditionals, one for each new format. Every new format means reopening output code that already works. If you split the conversion rules into separate functions or objects and pass them in, you can change the format while the output code stays as it is; that arrangement is what we call the Strategy pattern.

Content blocks 4-7 → 4-7

Content blocks 11 → 11

A programming idiom is a small, natural expression specific to a particular language. A pattern is larger, typically addressing relationships among multiple objects, modules, or layers.

Content blocks 13-14 → 13-14

Content blocks 17 → 17

Content blocks 21 → 21

The text is unchanged, but footnotes, formatting or block attributes have changed.

Content blocks 23 → 23

The text is unchanged, but footnotes, formatting or block attributes have changed.

Content blocks 25 → 25

The text is unchanged, but footnotes, formatting or block attributes have changed.