Unresolved Forces - Copyright Richard Fabian 2024

For example, instead of referring to a Strategy pattern, refer to the context of existing code handling only one variant. Introduce the forces as a new requirement for the code to adjust behaviour based on other information. The GoF Strategy pattern is a solution when:

• You want to offer variations on behaviour, but
• You don’t want the decision-making process limited to options you can think of right now, e.g. you wish to allow plugins or users of your library to add new possibilities, and
• You are using an object-oriented language, but
• It does not have access to function pointers, or
• You wish to serialise the choice of behaviour.

Then, a Strategy object works to solve the problem. Outside of the context of object-oriented languages or when you have function pointers, the larger pattern is solved by other means, so using the name pollutes the value of thinking about the larger pattern.

So, what is the larger pattern? It’s dynamic behaviour, which is a bit of a performance anti-pattern, but we’ll let that slide. Instead of demanding an object, we record the pattern as state-determined behaviour. Some languages don’t have a case/switch statement, some don’t have function pointers, and others don’t have objects; however, the core purpose and value of Strategy is achievable in all. We point out that the state needs to be stored somewhere and insist on taking care in concurrent contexts, providing the necessary wisdom to decide how to hold the state.

When naming an object-oriented version of a pattern, don’t be afraid to use a verb nominalised into a noun. The idea of many object-oriented practices is to create objects that represent actions. A place in which an action takes place can be named after it. 112 Entrance Transition, Boot Sequence, and Cyclic Update are all valid. So, feel free to rename Strategy as Last-minute Decision-Making.

Context rules

Whenever possible, introduce an element of the context over just describing a pattern. Sometimes, the context is well known, and so is the solution, so writing about it is about making sure related things are linked together. However, in cases where the contexts are less well-known and solutions are scarce, the context needs a vibrant presence in the pattern. You should represent the lack to be satisfied in the name. Dark rooms or ones in which the light is not good are referenced by the pattern 159 Light on two sides of every room, although indirectly. However, patterns without even an indirect name to an unexpected context will be missed, and only those who know the pattern very well before they come across the context will be able to use it. Examples of names that defy their context include most of those found in the GoF book.

If things are different, refer to them by different names. A crash is a hang, a transaction failure, or some unexpected behaviour. Which one? A user error might be a program error, fault, bug, invalid input, misuse, mistake, or stumble. What actually happened is the cause, the problem that we want to use to name our pattern.

You can only make decisions about things of which you are aware. Some decisions can only be made by creating a new label for a new configuration. As labels often lead to a meaning or essential nature, sometimes the decision can come down to your chosen name or attributes belonging to the new label.

Ultimately, all patterns need names. Otherwise, we cannot communicate with them as a language. But they must not be trivial. Small API, deep classes is better than Thin Classes. All work is not done until checked by the customer is more explicit than Customer value. Names can help when they state something that is not obvious. For example, repeatedly saying, ‘The customer comes first’ will not be as loud and clear as ‘If the customer wants your shoes, you must ask them whether they want them gift wrapped’.

So, name your patterns after elements that stand out, but make them discoverable by ensuring the problem is referenced, not a solution.