Composite pattern in Scala

The composite pattern is a structural design pattern. Its aim is to allow client code to treat individual objects and collections of objects uniformly (GoF, 1994). The example given in Design Patterns looks like so:

Unfortunately, the methods add(Graphic), remove(Graphic) and getChild(int) defined by the interface Graphic make little sense for the classes Text, Rectangle and Line. As a result implementations must either do nothing (potentially hiding an error in client code) or throw an exception resulting in a run-time error (as done by the Java collections library). This can be resolved by moving the definition of these methods down the inheritance hierarchy. For example:

Scala pattern matching means that there is no need for type casts if / when client code needs to distinguish between Text, Rectangle, Line and Picture instances. For example:

def render(graphic: Graphic): Unit = graphic match {
  case text: Text => ???
  case rectangle: Rectangle => ???
  case line: Line => ???
  case picture: Picture => ???
}

Further, sealing the base trait Graphic means that the compiler will warn you should you miss a case. For example:

sealed trait Graphic {
  def draw(): Unit
}

trait Picture extends Graphic {
  def add(graphic: Graphic): Unit
  def remove(graphic: Graphic): Unit
  def getChild(index: Int): Graphic
}

trait Line extends Graphic

trait Rectangle extends Graphic

trait Text extends Graphic

The return type Unit for draw, add and remove suggests the methods will have side effects. The first would likely call out to some graphics driver and the last two would probably mutate some private collection. This can be resolved by refactoring the definitions to defer side effects or avoid them all together. For example:

sealed trait Graphic {
  def draw(canvas: Canvas): Canvas
}

trait Picture extends Graphic {
  val graphics: Vector[Graphic]
  def withChild(graphic: Graphic): Picture
  def withoutChild(graphic: Graphic): Picture
}

trait Line extends Graphic

trait Rectangle extends Graphic

trait Text extends Graphic

This could be abstracted and improved upon further, but definitely seems like a step in the right direction. Assuming one is happy stopping here then the end result would look like so: