If you have alternatives - different kinds of things that can be used to replace one another or, sometimes combined with one another - then you have variation.
Design patterns thinking tells us that we should encapsulate variation. That's the kind of thing that is obvious once you already understand it (the hallmark of a good idea) but turning the advice into action can be challenging for people at first.
The immediate goal isn't really to make code less aware of the fact that there is variation so much as making your code so it doesn't need to change when you add or subtract a variant.
So, it's not that we're trying to hide variation altogether. We just want to minimize its impact on most of the code. We are seeking to lessen awareness, not eliminate it altogether.
If you are considering a design pattern for your system, and you aren't really sure if it's the right way to go, ask yourself this:
"Does this make something less aware of a kind of variation?"Or...
"Does this make something less aware of the variants in a kind of variation?"If the answer is "no", you aren't attending to the fundamental value-proposition of design patterns thinking and there's a good chance you should be considering another path.
