Structural Patterns in Scala

Explore Structural Patterns in Scala, including Adapter Pattern in Scala Design Patterns, Bridge Pattern in Scala: Separating Abstraction from Implementation, and Composite Pattern in Scala: Mastering Tree Structures with Case Classes and Sealed Traits.

Structural patterns in Scala are less about reproducing object-oriented class diagrams and more about shaping boundaries cleanly. Scala gives you traits, case classes, sealed hierarchies, objects, extension methods, higher-order functions, and immutable data. Those features let you solve the same structural problems as classic patterns, but often with smaller and more explicit designs.

This chapter is best read as a set of boundary decisions:

  • use Adapter when two APIs do not fit and one side should stay unchanged
  • use Bridge when a stable abstraction must vary independently from its implementation
  • use Composite when tree-shaped data and recursive behavior belong together
  • use Decorator when you need to wrap behavior at the edge without mutating the wrapped type
  • use Facade when a subsystem needs one cleaner entry point
  • use Flyweight when many values can safely share immutable intrinsic state
  • use Proxy when access, laziness, remoteness, or policy should sit between client and target
  • use Extension Methods when call-site ergonomics matter but ownership of the original type does not
  • use Module Pattern when the primary structural problem is code organization, encapsulation, and assembly

In Scala, the main design question is usually not “which named pattern fits?” It is “where should this boundary live, and which language feature makes that boundary obvious?” The strongest solutions tend to preserve referential transparency where possible, keep mutation near the edges, and avoid introducing extra object hierarchies just to imitate catalog examples.

In this section

Revised on Thursday, April 23, 2026