# Ruby DelegateClass

DevFeed: [Ruby DelegateClass](<https://devfeed.tech/articles/ruby-delegateclass-21049.md>)

Original publisher: [Read original article](<https://jakeyesbeck.com/2015/11/08/ruby-delegate-class/>)

Published: 2015-11-08T12:00:00Z

Content type: tutorial

Language: en

Sources: [Jake Yesbeck](<https://devfeed.tech/sources/jake-yesbeck.md>)

Topics: [Ruby](<https://devfeed.tech/topics/ruby.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>)

Tags: [activerecord](<https://devfeed.tech/tags/activerecord.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [module](<https://devfeed.tech/tags/module.md>), [mount](<https://devfeed.tech/tags/mount.md>), [rails](<https://devfeed.tech/tags/rails.md>), [ruby](<https://devfeed.tech/tags/ruby.md>), [web-applications](<https://devfeed.tech/tags/web-applications.md>)

## AI overview

This article explains how to use Ruby's DelegateClass and object delegation to model users with multiple roles, such as authors and critics, in a Rails application. It contrasts delegation with inheritance and Single Table Inheritance, emphasizing flexible composition, encapsulation, and separating business logic from standard user information.

## Source excerpt

Objects are a big deal in Ruby. A previous post about Ruby Objects can corroborate: Ruby Objects are pretty cool. There are many ways to work with Ruby Objects. Standard inheritance, module inheritance, decorators, and composition are all commonly found in a codebase. One class in particular seems almost universal across applications: the User class. From social networks to online retails stores, web applications most always have a user. Additionally, the User class might interact with nearly all other classes. This can make the relationship and responsibilities of that User awkward or unwieldy over time. As an example, assume that an application "booksandreviews.com" exists. This application serves both authors and critics, each representing a User. These User types have different responsibilities and privileges. Assuming a Rails application, the basic user model will look most likely like: class User < ActiveRecord::Base end One approach to extend this class and make Author and Critic classes is to use the Single Table Inheritance pattern. STI is a common pattern in Rails applications to share responsibilities between classes and store all records in the same place. This approach can work and might fit current needs just fine, but it might be beneficial to think outside the single table for a second. After all, no one said a User had to be either an Author or a Critic, what if they were both? Delegators, Mount Up! An alternative way to architect a system like the one described is by using delegation. Object delegation is a way of composing objects to achieve flexibility and maintain encapsulation. Ruby provides a few ways to delegate objects. An interesting option that will nicely serve this application's needs is DelegateClass. The DelegateClass method accepts a class and returns a new class. The returned class takes the passed in class's instance methods and defines delegating methods. Defining Author and Critic classes: class Author < DelegateClass(User) end cl