# A decorator vs. a subclass

DevFeed: [A decorator vs. a subclass](<https://devfeed.tech/articles/a-decorator-vs-a-subclass-26264.md>)

Original publisher: [Read original article](<https://www.justinweiss.com/articles/a-decorator-vs-a-subclass/>)

Author: Justin Weiss

Published: 2017-05-09T04:40:15Z

Content type: tutorial

Language: en

Sources: [Justin Weiss](<https://devfeed.tech/sources/justin-weiss.md>)

Topics: [Rails](<https://devfeed.tech/topics/rails.md>), [Inheritance](<https://devfeed.tech/topics/inheritance.md>), [Polymorphism](<https://devfeed.tech/topics/polymorphism.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [code](<https://devfeed.tech/tags/code.md>), [design-patterns](<https://devfeed.tech/tags/design-patterns.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [rails](<https://devfeed.tech/tags/rails.md>)

## AI overview

This article explains when to use a decorator instead of a subclass in Rails. It shows how decorators add behavior to existing objects without inheritance, while preserving the option to use the original object and reducing dependence on implementation details.

## Source excerpt

In my most recent article, I mentioned a great new feature in Rails 5.1, delegate_missing_to. With delegate_missing_to, any method that you can't find on one object is called on another object, instead: class Player delegate_missing_to :@user def initalize(user) @user = user end def points Game.points_for_user(user.id) end end Player.new(user).name # calls user.name But, like Gavin mentioned in the comments, this seems like an odd way to avoid inheritance. Why not just use a subclass? You'd get the same effect, and you don't have to add a whole new feature. It seems like a weird thing to add. There must be a reason delegate_missing_to was added, though. And for Rails features, pull requests are a great way to find those reasons. In this pull request, DHH mentioned why he suggested the feature: Here's a common pattern if you want to build a decorator: That seems like a pretty good place to start digging. Why decorators? When you build a decorator, you're changing the way an object acts, without creating a new subclass. For example, in the code from earlier: class Player delegate_missing_to :@user def initalize(user) @user = user end def points Game.points_for_user(user.id) end end You'd say that "Player decorates user," because a Player almost acts like a User, but has an extra method, points. And it does this without inheritance. Why would you need something like this? That's a tough question to answer, because like many design patterns, it's not always clear where you'd want to use it instead of something else. When would you use a decorator? Decorators could just be a more complicated way to do inheritance. I mean, which of these two lines of code is better? player = Player.new(User.new(name: "Justin")) # Player decorates User player = Player.new(name: "Justin") # Player subclasses User Clearly the second one, right? Here, creating Player as a decorator instead of a subclass is just a waste of code. But sometimes, you want to add functionality to an object later o