Patterns don't specialize or use each other; they contain each other. That's because patterns are about geometry, about space.

The pattern Garden Growing Wild ''contains'' the patterns Garden Seat and Connection To The Earth. These patterns do not ''refine'' Garden Growing Wild; they add to it. They do not ''specialize'' Garden Growing Wild. They are ''part of'' the pattern Garden Growing Wild - in a given context.
----
Sometimes JimCoplien talks about patterns that "contain" other patterns in the sense that ChristopherAlexander describes. Many have mistaken Cope to be talking about "containment" in the sense of encapsulation and information hiding. But that is veering off in the wrong direction from what Cope means. The "containment" Cope refers to isn't so much a relationship of encapsulation or information hiding; It's all about ''geometry'': The smaller patterns are still visible inside the larger one, and in fact not only do they help the larger one emerge and become more distinct, but the larger one helps reinforce the aesthetics of the smaller ones in the process. It will probably also help reinforce both larger and smaller patterns ''outside'' the containing pattern as well.

This has little to do with access restriction and encapsulation / hiding and has far more to do with emergent behavior and dense, local interaction between patterns. Since Alexander is dealing with visually tangible geometric / structural relationships, it may look like containment in the encapsulating sense but IMHO that's not the relevant aspect to be looking at.

It has more to do with what kind of "geometry" the software patterns in question are trying to shape. If the patterns are trying to shape the geometry of the source code on the page/screen, levels of scale will be things like tokens, identifiers, operators, keywords, lines, statements, statement blocks, subroutines, modules/packages, pages/screens, and
indentation levels. A module may be trying to hide certain information, but from this perspective it's not trying to hide the appearance of the statements and declarations inside of out. [''inside of out??'']

Similarly, OO design patterns are trying to shape the "geometry" of the OO "architecture" (whatever you interpret that to mean - perhaps it means the geometric appearance of your UML diagrams for the architecture, or maybe it means something else). The dense local interaction here would be between things like objects/classes, components, subsystems, frameworks, applications across processors, networks, subject domains, etc.

Some things may be visible or capable of standing alone, but at the same time their biggest benefit comes from how they help contribute to the larger outcome that may not be visible till some of the larger patterns emerge from the collaborations between the smaller ones.

-- BradAppleton