A design pattern is a reusable blueprint for solving similarly structured software problems, adjusted slightly for each scenario rather than used as a pre-built library. section 2.1
API design patterns apply this idea to API structure, helping reduce large future changes while preserving a deliberate balance between implementation difficulty and flexibility. section 2.0 section 2.5
Evaluate a pattern before adopting it:
- Identify the recurring problem and confirm that the pattern is close enough to fit the problem space. section 2.3.1 section 2.3.5
- Name the pattern clearly and use a short synopsis to make its purpose easy to recognize. section 2.3.1
- Compare its benefits with functional limitations, added complexity, and possible data-consistency effects. section 2.3.5
- Treat the pattern as an adaptable design rather than an automatic replacement for custom software. section 2.1
Table 2.1 Comparison of ways to build a shed with ways to build software (view table figure)
Compare pre-built software, customization, design documents, and fully custom implementation by their relative difficulty and flexibility. section 2.1
From shed plans to API design
Choosing software approaches resembles building a shed: use a pre-built package for simplicity, customize a kit for limited flexibility, follow blueprints for moderate flexibility, or build from scratch for maximum flexibility. A catalog entry might then name an export solution the “IO pattern” and summarize it as structured movement of data between storage sources and destinations. section 2.1 section 2.3.1
