🎉 Hooray! After 3 years of work, I've finally released the ebook on design patterns! Check it out »

Composite in Ruby

Composite is a structural design pattern that allows composing objects into a tree-like structure and work with the it as if it was a singular object.

Composite became a pretty popular solution for the most problems that require building a tree structure. Composite’s great feature is the ability to run methods recursively over the whole tree structure and sum up the results.

Learn more about Composite

Usage of the pattern in Ruby



Usage examples: The Composite pattern is pretty common in Ruby code. It’s often used to represent hierarchies of user interface components or the code that works with graphs.

Identification: The composite is easy to recognize by behavioral methods taking an instance of the same abstract/interface type into a tree structure.

Conceptual Example

This example illustrates the structure of the Composite design pattern. It focuses on answering these questions:

  • What classes does it consist of?
  • What roles do these classes play?
  • In what way the elements of the pattern are related?

main.rb: Conceptual Example

# The base Component class declares common operations for both simple and
# complex objects of a composition.
class Component
  # @return [Component]
  def parent

  # Optionally, the base Component can declare an interface for setting and
  # accessing a parent of the component in a tree structure. It can also provide
  # some default implementation for these methods.
  def parent=(parent)
    @parent = parent

  # In some cases, it would be beneficial to define the child-management
  # operations right in the base Component class. This way, you won't need to
  # expose any concrete component classes to the client code, even during the
  # object tree assembly. The downside is that these methods will be empty for
  # the leaf-level components.
  def add(component)
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"

  # @abstract
  # @param [Component] component
  def remove(component)
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"

  # You can provide a method that lets the client code figure out whether a
  # component can bear children.
  def composite?

  # The base Component may implement some default behavior or leave it to
  # concrete classes (by declaring the method containing the behavior as
  # "abstract").
  def operation
    raise NotImplementedError, "#{self.class} has not implemented method '#{__method__}'"

# The Leaf class represents the end objects of a composition. A leaf can't have
# any children.
# Usually, it's the Leaf objects that do the actual work, whereas Composite
# objects only delegate to their sub-components.
class Leaf < Component
  # return [String]
  def operation

# The Composite class represents the complex components that may have children.
# Usually, the Composite objects delegate the actual work to their children and
# then "sum-up" the result.
class Composite < Component
  def initialize
    @children = []

  # A composite object can add or remove other components (both simple or
  # complex) to or from its child list.

  # @param [Component] component
  def add(component)
    component.parent = self

  # @param [Component] component
  def remove(component)
    component.parent = nil

  # @return [Boolean]
  def composite?

  # The Composite executes its primary logic in a particular way. It traverses
  # recursively through all its children, collecting and summing their results.
  # Since the composite's children pass these calls to their children and so
  # forth, the whole object tree is traversed as a result.
  def operation
    results = []
    @children.each { |child| results.append(child.operation) }

# The client code works with all of the components via the base interface.
def client_code(component)
  puts "RESULT: #{component.operation}"

# Thanks to the fact that the child-management operations are declared in the
# base Component class, the client code can work with any component, simple or
# complex, without depending on their concrete classes.
def client_code2(component1, component2)
  component1.add(component2) if component1.composite?

  print "RESULT: #{component1.operation}"

# This way the client code can support the simple leaf components...
simple = Leaf.new
puts 'Client: I\'ve got a simple component:'
puts "\n"

# ...as well as the complex composites.
tree = Composite.new

branch1 = Composite.new

branch2 = Composite.new


puts 'Client: Now I\'ve got a composite tree:'
puts "\n"

puts 'Client: I don\'t need to check the components classes even when managing the tree:'
client_code2(tree, simple)

output.txt: Execution result

Client: I've got a simple component:

Client: Now I've got a composite tree:
RESULT: Branch(Branch(Leaf+Leaf)+Branch(Leaf))

Client: I don't need to check the components classes even when managing the tree:
RESULT: Branch(Branch(Leaf+Leaf)+Branch(Leaf)+Leaf)

Composite in Other Languages

Design Patterns: Composite in Java Design Patterns: Composite in C# Design Patterns: Composite in PHP Design Patterns: Composite in Python Design Patterns: Composite in Swift Design Patterns: Composite in TypeScript