# I would love to see some composition examples

**URL:** <https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265>\
**Category:** Ruby Chat\
**Created:** [July 22, 2015, 1:38am UTC](https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265 "2015-07-22T01:38:08Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![PikachuEXE](https://metaruby.com/user_avatar/metaruby.com/pikachuexe/32/854_2.png) [@PikachuEXE](https://metaruby.com/u/PikachuEXE)\
**Post date:** [July 22, 2015, 1:38am UTC](https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265/1 "2015-07-22T01:38:08Z")

</div>

I saw this tweet:

[https://twitter.com/](https://twitter.com/)_solnic_/status/623224611212251136

I lack the experience to understand “prefer composition over inheritance” in Ruby (or Rails).  
I would love to hear reasons & examples for that.  
(Also googling at the same time)

---

<div class="post-metadata">

**Author:** ![kofno](https://metaruby.com/user_avatar/metaruby.com/kofno/32/159_2.png) [@kofno](https://metaruby.com/u/kofno)\
**Post date:** [July 22, 2015, 3:36am UTC](https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265/2 "2015-07-22T03:36:44Z")

</div>

This refers to creating reuse by extracting functionality into objects that can be instantiated by your class, rather then pushing the functionality up the inheritance hierarchy (into a super class or mixin).

This example may be too simplistic, but consider the following classes that both create\_foo:

```
class A
  def create_foo
    # does stuff
  end
end

class B
  def create_foo
    # does same stuff
  end
end

```

You might push the #create\_foo method up into a super class or module (inheritance). In composition, we would create a new object to handle Foo creation:

```
class Foo
  def create
     # still does the same stuff
  end
end

```

Then we could instantiate this class and call it from our original classes:

```
class A
  def create_foo
    foo = Foo.new
    foo.create
  end
end

class B
  def create_foo
    foo = Foo.new
    foo.create
  end
end

```

The benefit of composition over inheritance is that it is far more malleable. Creating variable behavior in the inherited create\_foo method would likely cause it to gradually grow into a nest of if and case statements. In the composition example, I only need to replace the Foo class with something that quacks like Foo.

---

<div class="post-metadata">

**Author:** ![RedFred7](https://metaruby.com/user_avatar/metaruby.com/redfred7/32/838_2.png) [@RedFred7](https://metaruby.com/u/RedFred7)\
**Post date:** [July 22, 2015, 7:26pm UTC](https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265/3 "2015-07-22T19:26:09Z")

</div>

> [@PikachuEXE](#):
>
> I lack the experience to understand "prefer composition over inheritance

This is a paradigm that’s not so much relevant in Ruby as in static languages. Here’s a crude example:

```
class Car
  attr_reader :engine
  def initialize
    @engine = 1200
  end
end

class Ford < Car
end

car = Ford.new
puts car.engine

```

My Ford needs an engine and one way of getting one is to inherit from something that has one, i.e. a Car. The trouble with this is that if you need to select which engine your Ford will have based on some conditional dynamic logic then you’re stuck. You can’t un-inherit Car and re-inherit from something else that has the engine you need (although in Ruby we can use modules and meta-programming to get round that). The alternative approach would be:.

```
class Engine
  attr_reader :capacity
  def initialize
    @capacity = 1200
  end
end

class Ford
  def engine
  	Engine.new.capacity
  end

end

car = Ford.new
puts car.engine

```

We’re now _composing_ an engine when we need it, as opposed to expecting one from a parent class. The advantage here is that can dynamically plug-in whichever class we see fit at runtime, e.g. DieselEngine or PetrolEngine. This is a choice we don’t really have with inheritance, as we need to decide whether we need to inherit from a DieselCar or a PetrolCar right back when we define our class.

When it comes to choosing which method to use, i apply the old OO principle: If Class B **is a type of** class A then use inheritance. If Class B **has an instance of** A then use composition. That would mean that, in our example, my Ford is\_a car and has\_an engine. So I would use both methods here, inheriting from Car and composing an engine.

HTH

---

<div class="post-metadata">

**Author:** ![PikachuEXE](https://metaruby.com/user_avatar/metaruby.com/pikachuexe/32/854_2.png) [@PikachuEXE](https://metaruby.com/u/PikachuEXE)\
**Post date:** [July 23, 2015, 1:50am UTC](https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265/4 "2015-07-23T01:50:27Z")

</div>

Thanks both of you 🙂  
I can at least remember the OO principle now (“is a” vs “has a”)  
But with my understanding now I would expect the example to be:

Inheritance

```ruby
class Car
  def engine_capacity
    1000
  end
end

class Ford < Car
  def engine_capacity
    1200
  end
end

```

Composition

```ruby
class Engine
  attr_reader :capacity

  def initialize(capacity)
    @capacity = capacity
  end
end

class Car
  attr_reader :engine

  def initialize(engine)
    @engine = engine
  end

  def engine_capacity
    engine.capacity
  end
end

def Ford < Car
  # nothing to override now
end

```

A default engine can be applied too

```ruby
class Car
  def initialize(engine)
    @engine = engine
  end

  def engine_capacity
    engine.capacity
  end

  def engine
    @engine ||= default_engine
  end

  private

  def default_engine
    Engine.new(1000)
  end
end

def Ford < Car
  private

  def default_engine
    Engine.new(1200)
  end
end

```

---

<div class="post-metadata">

**Author:** ![RedFred7](https://metaruby.com/user_avatar/metaruby.com/redfred7/32/838_2.png) [@RedFred7](https://metaruby.com/u/RedFred7)\
**Post date:** [July 23, 2015, 12:40pm UTC](https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265/5 "2015-07-23T12:40:56Z")

</div>

@PikachuEXE you’re absolutely right, a Car **has\_an** Engine and a Ford **is\_a** Car, that’s the way it should be. I told you my example was crude 😄 The default engine is a nice touch, though I’d probably write it a bit less verbosely:

```
class Engine
  attr_reader :capacity

  def initialize(capacity)
    @capacity = capacity
  end
end

class Car
  DEFAULT_CAPACITY = 1000
  attr_reader :engine
  def initialize(engine_capacity)
    @engine = ( engine_capacity ? Engine.new(engine_capacity) : Engine.new(DEFAULT_CAPACITY) )
  end
end

class Ford < Car
end

car = Ford.new(2000)
puts car.engine.capacity #capacity = 20000

car2 = Ford.new(nil)
puts car2.engine.capacity # Default capacity

```

I know a lot of people frown upon inheritance, but I think in a dynamic, flexible language like Ruby, the disadvantages are not that bad. Besides, Ruby relies heavily on inheritance to enable some of the cool things we can do with it. The ROM is but an inheritance tree (one one axis anyway) after all. In general, I tend to stick to the _has\_a, is\_a_ rule and not worry about false dilemmas too much. 👍

---

<div class="post-metadata">

**Author:** ![kofno](https://metaruby.com/user_avatar/metaruby.com/kofno/32/159_2.png) [@kofno](https://metaruby.com/u/kofno)\
**Post date:** [July 23, 2015, 3:48pm UTC](https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265/6 "2015-07-23T15:48:42Z")

</div>

I think anti-inheritance is a backlash from people working in poorly modeled systems.

A fictitious (though representative example): modeling “a person _is\_a_ manager” instead of "a person _has\_a_ role of manager.

This doesn’t mean inheritance is broken and never use it. Just that we now have a better understanding of our model and of OO. That’s a good thing.

---

<div class="post-metadata">

**Author:** ![RedFred7](https://metaruby.com/user_avatar/metaruby.com/redfred7/32/838_2.png) [@RedFred7](https://metaruby.com/u/RedFred7)\
**Post date:** [July 23, 2015, 8:15pm UTC](https://metaruby.com/t/i-would-love-to-see-some-composition-examples/265/7 "2015-07-23T20:15:41Z")

</div>

> [@kofno](#):
>
> A fictitious (though representative example): modeling “a person is\_a manager” instead of "a person has\_a role of manager

I know where you’re coming from. That’s why I’ll often talk of **is\_a\_type\_of** and **has\_an\_instance\_of** instead of simply has\_a and is\_a. Helps avoiding confusion.