About resolving forces in a context
A pattern begins with the context and the forces and only then starts to show its value through the constraints of a solution that satisfies them. Contexts don’t always have the same solution when the forces at play differ, and forces don’t always lead to the same solution when operating in different contexts.
Forces are needs, desires, and requirements. Sometimes, a stakeholder’s values impart a force upon a situation. Forces are the stresses and pains of the participants in the environment. They are the drivers of action and the cause of any imbalance. They are the unresolved conflicts or dependencies. In this, patterns rely upon and resolve the relationships between the identifiable parts of a context.
Context is the environment. It’s the situation in which these forces are playing out. It can include a project, the timescale of a solution, or other external limitations. It can be the available actions, such as tools and the principles to which a solution must adhere. In effect, the context is the sum of the rules of physics governing what is possible. It is the set of rules by which you may introduce change.
So, a pattern is a recognition of a set of forces in a context and the steps
and techniques leading to solutions balancing those forces. Not a solution, but
a guide to reach one. The patterns in
Not all books are like this though. One book I read on compression when I first started out in computer games fed me a diet of information theory and examples. I learned how you might exploit your domain knowledge to reduce the number of bits required to store your data. I internalised much of this wisdom and often view problems through its lens, and not just problems of compression.
Some building patterns are only appropriate within a culture or a climate. In software development, it’s the same. Consider which patterns only matter because of the medium, such as the language. A C++ pattern might be a language feature in Python. A pattern in C might be impossible to implement in Java or Rust. Consider also the applicability of patterns at different scales of each aspect. Does team size or product scale affect which patterns are valuable or available to the project? Does a quality bar or expected product lifetime affect whether safety-related patterns apply? Is maintainability or project budget more important than time to market? Some higher-level patterns resolve some of these forces over others. These are all part of the context.
The patterns of building construction don’t define what a place or thing is made of; instead, they define what kinds of affordances it has to the inhabitants—the actions and interactions that can take place in it.
The design of a spade does not specify metal or wood but a light shaft and harder than the target material blade. It includes size and proportion limits balanced against leverage requirements for a specific user and the target’s toughness. It’s relative; it’s about relationships between elements, constraints, and context. It’s all about how we will be using the tool, the contexts of dirt and available manual labour, and the forces of needing to move material from one place to another with a delicate touch. This is a pattern resolving forces.
When you think in terms of lawns, walls, paths, and trees, these are the pieces by which we complete the pattern. If you instead turn to the interpretation of things as relationships, such as a sunny place where you can be with trees, a terrace on the street, or a garden wall, they are about how things interact to produce something more meaningful. These are the forces. They are what it is for. People’s impressions of a place aren’t descriptions; they are the hopes. And hope is a force.
We should always consider design patterns superior to solutions because they are transformations rather than additions. They do not conflict with other patterns because they preserve and define, not replace or subtract. Why this is so will be explained in the chapter Fundamental Properties.