A design pattern is a reusable, high-level approach to a recurring software design problem. It gives developers a familiar way to reason about a design and helps other people recognize what the code is doing. A useful pattern applies broadly without dictating every implementation detail. section 1.2 section 1.0
Treat a pattern as a tool, not a recipe. Copying its shape gets you only a small part of a finished design; you still need to decide whether it suits the problem and how to adapt it. Following a pattern blindly can add complexity instead of improving the code. section 1.3 section 1.1
In Rust, pattern choices draw on language features as well as familiar ideas from other languages:
- Generics, traits, pattern matching, and closures provide building blocks for concrete patterns. section 5.0
- Builders, fluent interfaces, observers, and commands are familiar patterns; newtype is presented as Rust-specific. section 5.0
- Some object-oriented patterns are unnecessary when a Rust feature or standard-library facility, such as iterators, provides a simpler alternative. section 1.1
Where an idiom becomes a pattern
Resource acquisition is initialization (RAII) handles program resources in a formalized way. It is treated as a pattern rather than merely a coding idiom because it can affect a program’s structure and architecture. In Rust, it also supports other patterns and contributes to safety. section 4.1
The right pattern also depends on the job. Some are broadly useful; others, including patterns built with specialized uses of traits, generics, and structs, are more complex and less likely to fit everyday work. Prefer a recognizable design when it helps, but leave room for a simpler solution. section 7.0 section 1.2
Figure 1.1 Hierarchy of idioms, patterns, and architecture
Use the hierarchy to place design patterns in relation to smaller idioms and broader architecture. section 1.2
