The document discusses the differences between composition and inheritance/mixins in object-oriented programming. It notes that mixins can violate the single responsibility principle and be difficult to test since the code is not contained in one place. Composition is recommended instead as it allows calling methods on child instances, only using necessary code, and avoids naming conflicts. Links are provided discussing replacing inheritance with composition and decomposing fat models.

1. Composition vs
Inheritance/Mixins

2. What is mixin?

3. "Using mixins like this is akin to
cleaning a messy room by dumping
the clutter into six separate junk
drawers and slamming them shut."

4. What's wrong with mixins?
• They are a violation of the Single Responsibility
Principle
• They are hard to test.
• Where the called code lives?
• http://blog.8thlight.com/eric-meyer/2012/11/16/
composition-over-mixins.html

5. Composition benefits
• Fits better for deep hierarchy
• You call methods on instances instead of global
namespace ("Engine.new.start" instead of
"start_engine")
• Use only what you need, easier to share code, no
method name conflicts

6. Replace Inheritance with
Composition

9. • http://blog.codeclimate.com/blog/2012/10/17/7-
ways-to-decompose-fat-activerecord-models/
• http://blog.8thlight.com/eric-meyer/2012/11/16/
composition-over-mixins.html
• http://reefpoints.dockyard.com/2013/10/01/design-
patterns-composite-pattern.html
• Ruby Science book

10. THANKS!