release/ruby-science.html

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <meta name="generator" content="pandoc">
  <meta name="author" content="thoughtbot">
  <meta name="author" content="Joe Ferris">
  <meta name="author" content="Harlow Ward">
  <title>Ruby Science</title>
  <style type="text/css">code{white-space: pre;}</style>
  <!--[if lt IE 9]>
    <script src="http://html5shim.googlecode.com/svn/trunk/html5.js"></script>
  <![endif]-->
  <style type="text/css">
table.sourceCode, tr.sourceCode, td.lineNumbers, td.sourceCode {
  margin: 0; padding: 0; vertical-align: baseline; border: none; }
table.sourceCode { width: 100%; line-height: 100%; }
td.lineNumbers { text-align: right; padding-right: 4px; padding-left: 4px; color: #aaaaaa; border-right: 1px solid #aaaaaa; }
td.sourceCode { padding-left: 5px; }
code > span.kw { color: #007020; font-weight: bold; }
code > span.dt { color: #902000; }
code > span.dv { color: #40a070; }
code > span.bn { color: #40a070; }
code > span.fl { color: #40a070; }
code > span.ch { color: #4070a0; }
code > span.st { color: #4070a0; }
code > span.co { color: #60a0b0; font-style: italic; }
code > span.ot { color: #007020; }
code > span.al { color: #ff0000; font-weight: bold; }
code > span.fu { color: #06287e; }
code > span.er { color: #ff0000; font-weight: bold; }
  </style>
</head>
<body>
<header>
<h1 class="title">Ruby Science</h1>
<h2 class="author">thoughtbot</h2>
<h2 class="author">Joe Ferris</h2>
<h2 class="author">Harlow Ward</h2>
</header>
<nav id="TOC">
<ul>
<li><a href="#introduction">Introduction</a><ul>
<li><a href="#code-reviews">Code Reviews</a></li>
<li><a href="#follow-your-nose">Follow Your Nose</a></li>
<li><a href="#removing-resistance">Removing Resistance</a></li>
<li><a href="#bugs-and-churn">Bugs and Churn</a></li>
<li><a href="#tools-to-find-smells">Tools to Find Smells</a></li>
<li><a href="#how-to-read-this-book">How to Read This Book</a></li>
<li><a href="#example-application">Example Application</a></li>
</ul></li>
<li><a href="#long-method">Long Method</a><ul>
<li><a href="#symptoms">Symptoms</a></li>
<li><a href="#example">Example</a></li>
<li><a href="#solutions">Solutions</a></li>
</ul></li>
<li><a href="#large-class">Large Class</a><ul>
<li><a href="#symptoms-1">Symptoms</a></li>
<li><a href="#example-1">Example</a></li>
<li><a href="#solutions-1">Solutions</a></li>
<li><a href="#prevention">Prevention</a></li>
<li><a href="#private-methods">Private Methods</a></li>
<li><a href="#god-class">God Class</a></li>
</ul></li>
<li><a href="#feature-envy">Feature Envy</a><ul>
<li><a href="#symptoms-2">Symptoms</a></li>
<li><a href="#example-2">Example</a></li>
<li><a href="#solutions-2">Solutions</a></li>
<li><a href="#prevention-1">Prevention</a></li>
</ul></li>
<li><a href="#case-statement">Case Statement</a><ul>
<li><a href="#symptoms-3">Symptoms</a></li>
<li><a href="#type-codes">Type Codes</a><ul>
<li><a href="#example-3">Example</a></li>
<li><a href="#solutions-3">Solutions</a></li>
</ul></li>
</ul></li>
<li><a href="#shotgun-surgery">Shotgun Surgery</a><ul>
<li><a href="#symptoms-4">Symptoms</a></li>
<li><a href="#example-4">Example</a></li>
<li><a href="#solutions-4">Solutions</a></li>
<li><a href="#prevention-2">Prevention</a></li>
</ul></li>
<li><a href="#divergent-change">Divergent Change</a><ul>
<li><a href="#symptoms-5">Symptoms</a></li>
<li><a href="#example-5">Example</a></li>
<li><a href="#solutions-5">Solutions</a></li>
<li><a href="#prevention-3">Prevention</a></li>
</ul></li>
<li><a href="#long-parameter-list">Long Parameter List</a><ul>
<li><a href="#symptoms-6">Symptoms</a></li>
<li><a href="#example-6">Example</a></li>
<li><a href="#solutions-6">Solutions</a></li>
<li><a href="#anti-solution">Anti-Solution</a></li>
</ul></li>
<li><a href="#duplicated-code">Duplicated Code</a><ul>
<li><a href="#symptoms-7">Symptoms</a></li>
<li><a href="#example-7">Example</a></li>
<li><a href="#solutions-7">Solutions</a></li>
<li><a href="#prevention-4">Prevention</a></li>
</ul></li>
<li><a href="#uncommunicative-name">Uncommunicative Name</a><ul>
<li><a href="#symptoms-8">Symptoms</a></li>
<li><a href="#example-8">Example</a></li>
<li><a href="#solutions-8">Solutions</a></li>
</ul></li>
<li><a href="#single-table-inheritance-sti">Single Table Inheritance (STI)</a><ul>
<li><a href="#symptoms-9">Symptoms</a></li>
<li><a href="#example-9">Example</a></li>
<li><a href="#solutions-9">Solutions</a></li>
<li><a href="#prevention-5">Prevention</a></li>
</ul></li>
<li><a href="#comments">Comments</a><ul>
<li><a href="#symptoms-10">Symptoms</a></li>
<li><a href="#example-10">Example</a></li>
<li><a href="#solutions-10">Solutions</a></li>
</ul></li>
<li><a href="#mixin">Mixin</a><ul>
<li><a href="#symptoms-11">Symptoms</a></li>
<li><a href="#example-11">Example</a></li>
<li><a href="#solutions-11">Solutions</a></li>
<li><a href="#prevention-6">Prevention</a></li>
</ul></li>
<li><a href="#callback">Callback</a><ul>
<li><a href="#symptoms-12">Symptoms</a></li>
<li><a href="#example-12">Example</a></li>
<li><a href="#solutions-12">Solutions</a></li>
</ul></li>
<li><a href="#replace-conditional-with-polymorphism">Replace Conditional with Polymorphism</a><ul>
<li><a href="#uses">Uses</a></li>
<li><a href="#example-13">Example</a></li>
<li><a href="#replace-type-code-with-subclasses">Replace Type Code with Subclasses</a></li>
<li><a href="#single-table-inheritance-sti-1">Single Table Inheritance (STI)</a><ul>
<li><a href="#extracting-type-specific-code">Extracting Type-Specific Code</a></li>
</ul></li>
<li><a href="#polymorphic-partials">Polymorphic Partials</a><ul>
<li><a href="#multiple-polymorphic-views">Multiple Polymorphic Views</a></li>
<li><a href="#drawbacks">Drawbacks</a></li>
<li><a href="#next-steps">Next Steps</a></li>
</ul></li>
</ul></li>
<li><a href="#replace-conditional-with-null-object">Replace Conditional with Null Object</a><ul>
<li><a href="#uses-1">Uses</a></li>
<li><a href="#example-14">Example</a></li>
<li><a href="#drawbacks-1">Drawbacks</a></li>
<li><a href="#next-steps-1">Next Steps</a></li>
<li><a href="#truthiness-try-and-other-tricks">Truthiness, <code>try</code> and Other Tricks</a></li>
</ul></li>
<li><a href="#extract-method">Extract Method</a><ul>
<li><a href="#uses-2">Uses</a></li>
<li><a href="#example-15">Example</a></li>
<li><a href="#replace-temp-with-query">Replace Temp with Query</a><ul>
<li><a href="#other-examples">Other Examples</a></li>
<li><a href="#next-steps-2">Next Steps</a></li>
</ul></li>
</ul></li>
<li><a href="#rename-method">Rename Method</a><ul>
<li><a href="#uses-3">Uses</a></li>
<li><a href="#example-16">Example</a></li>
<li><a href="#next-steps-3">Next Steps</a></li>
</ul></li>
<li><a href="#extract-class">Extract Class</a><ul>
<li><a href="#uses-4">Uses</a></li>
<li><a href="#example-17">Example</a></li>
<li><a href="#drawbacks-2">Drawbacks</a></li>
<li><a href="#next-steps-4">Next Steps</a></li>
</ul></li>
<li><a href="#extract-value-object">Extract Value Object</a><ul>
<li><a href="#uses-5">Uses</a></li>
<li><a href="#example-18">Example</a></li>
<li><a href="#next-steps-5">Next Steps</a></li>
</ul></li>
<li><a href="#extract-decorator">Extract Decorator</a><ul>
<li><a href="#uses-6">Uses</a></li>
<li><a href="#example-19">Example</a></li>
<li><a href="#drawbacks-3">Drawbacks</a></li>
<li><a href="#next-steps-6">Next Steps</a></li>
</ul></li>
<li><a href="#extract-partial">Extract Partial</a><ul>
<li><a href="#uses-7">Uses</a></li>
<li><a href="#steps">Steps</a></li>
<li><a href="#example-20">Example</a></li>
<li><a href="#next-steps-7">Next Steps</a></li>
</ul></li>
<li><a href="#extract-validator">Extract Validator</a><ul>
<li><a href="#uses-8">Uses</a></li>
<li><a href="#example-21">Example</a></li>
<li><a href="#next-steps-8">Next Steps</a></li>
</ul></li>
<li><a href="#introduce-explaining-variable">Introduce Explaining Variable</a><ul>
<li><a href="#uses-9">Uses</a></li>
<li><a href="#example-22">Example</a></li>
<li><a href="#next-steps-9">Next Steps</a></li>
</ul></li>
<li><a href="#introduce-form-object">Introduce Form Object</a><ul>
<li><a href="#uses-10">Uses</a></li>
<li><a href="#example-23">Example</a></li>
<li><a href="#next-steps-10">Next Steps</a></li>
</ul></li>
<li><a href="#introduce-parameter-object">Introduce Parameter Object</a><ul>
<li><a href="#uses-11">Uses</a></li>
<li><a href="#example-24">Example</a></li>
<li><a href="#next-steps-11">Next Steps</a></li>
</ul></li>
<li><a href="#use-class-as-factory">Use Class as Factory</a><ul>
<li><a href="#uses-12">Uses</a></li>
<li><a href="#example-25">Example</a></li>
<li><a href="#next-steps-12">Next Steps</a></li>
</ul></li>
<li><a href="#move-method">Move Method</a><ul>
<li><a href="#uses-13">Uses</a></li>
<li><a href="#dangerous-move-and-extract-at-the-same-time">Dangerous: Move and Extract at the Same Time</a></li>
<li><a href="#next-steps-13">Next Steps</a></li>
</ul></li>
<li><a href="#inline-class">Inline Class</a><ul>
<li><a href="#uses-14">Uses</a></li>
<li><a href="#example-26">Example</a></li>
<li><a href="#drawbacks-4">Drawbacks</a></li>
<li><a href="#next-steps-14">Next Steps</a></li>
</ul></li>
<li><a href="#inject-dependencies">Inject Dependencies</a><ul>
<li><a href="#uses-15">Uses</a></li>
<li><a href="#example-27">Example</a></li>
<li><a href="#drawbacks-5">Drawbacks</a></li>
<li><a href="#next-steps-15">Next Steps</a></li>
</ul></li>
<li><a href="#replace-subclasses-with-strategies">Replace Subclasses with Strategies</a><ul>
<li><a href="#uses-16">Uses</a></li>
<li><a href="#example-28">Example</a></li>
<li><a href="#drawbacks-6">Drawbacks</a></li>
<li><a href="#next-steps-16">Next Steps</a></li>
</ul></li>
<li><a href="#replace-mixin-with-composition">Replace Mixin with Composition</a><ul>
<li><a href="#uses-17">Uses</a></li>
<li><a href="#example-29">Example</a></li>
<li><a href="#next-steps-17">Next Steps</a></li>
</ul></li>
<li><a href="#replace-callback-with-method">Replace Callback with Method</a><ul>
<li><a href="#uses-18">Uses</a></li>
<li><a href="#steps-1">Steps</a></li>
<li><a href="#example-30">Example</a></li>
<li><a href="#next-steps-18">Next Steps</a></li>
</ul></li>
<li><a href="#use-convention-over-configuration">Use Convention Over Configuration</a><ul>
<li><a href="#uses-19">Uses</a></li>
<li><a href="#example-31">Example</a></li>
<li><a href="#scoping-constantize">Scoping <code>constantize</code></a></li>
<li><a href="#drawbacks-7">Drawbacks</a></li>
</ul></li>
<li><a href="#dry">DRY</a><ul>
<li><a href="#duplicated-knowledge-vs.-duplicated-text">Duplicated Knowledge vs. Duplicated Text</a><ul>
<li><a href="#application">Application</a></li>
</ul></li>
</ul></li>
<li><a href="#single-responsibility-principle">Single Responsibility Principle</a><ul>
<li><a href="#reasons-to-change">Reasons to Change</a></li>
<li><a href="#stability">Stability</a></li>
<li><a href="#cohesion">Cohesion</a></li>
<li><a href="#responsibility-magnets">Responsibility Magnets</a></li>
<li><a href="#tension-with-tell-dont-ask">Tension with Tell, Don't Ask</a><ul>
<li><a href="#drawbacks-8">Drawbacks</a></li>
<li><a href="#application-1">Application</a></li>
</ul></li>
</ul></li>
<li><a href="#tell-dont-ask">Tell, Don't Ask</a><ul>
<li><a href="#encapsulation-of-logic">Encapsulation of Logic</a></li>
<li><a href="#encapsulation-of-state">Encapsulation of State</a></li>
<li><a href="#minimal-public-interface">Minimal Public Interface</a></li>
<li><a href="#tension-with-modelviewcontroller">Tension with Model—View—Controller</a><ul>
<li><a href="#application-2">Application</a></li>
</ul></li>
</ul></li>
<li><a href="#law-of-demeter">Law of Demeter</a><ul>
<li><a href="#multiple-dots">Multiple Dots</a></li>
<li><a href="#multiple-assignments">Multiple Assignments</a></li>
<li><a href="#the-spirit-of-the-law">The Spirit of the Law</a></li>
<li><a href="#objects-vs.-types">Objects vs. Types</a></li>
<li><a href="#duplication">Duplication</a><ul>
<li><a href="#application-3">Application</a></li>
</ul></li>
</ul></li>
<li><a href="#composition-over-inheritance">Composition Over Inheritance</a><ul>
<li><a href="#inheritance">Inheritance</a></li>
<li><a href="#composition">Composition</a></li>
<li><a href="#dynamic-vs.-static">Dynamic vs. Static</a></li>
<li><a href="#dynamic-inheritance">Dynamic Inheritance</a></li>
<li><a href="#the-trouble-with-hierarchies">The Trouble with Hierarchies</a></li>
<li><a href="#mixins">Mixins</a></li>
<li><a href="#single-table-inheritance">Single Table Inheritance</a><ul>
<li><a href="#drawbacks-9">Drawbacks</a></li>
<li><a href="#application-4">Application</a></li>
</ul></li>
</ul></li>
<li><a href="#openclosed-principle">Open/Closed Principle</a><ul>
<li><a href="#strategies">Strategies</a><ul>
<li><a href="#inheritance-1">Inheritance</a></li>
<li><a href="#decorators">Decorators</a></li>
<li><a href="#dependency-injection">Dependency Injection</a></li>
</ul></li>
<li><a href="#everything-is-open">Everything is Open</a></li>
<li><a href="#monkey-patching">Monkey Patching</a><ul>
<li><a href="#drawbacks-10">Drawbacks</a></li>
<li><a href="#application-5">Application</a></li>
</ul></li>
</ul></li>
<li><a href="#dependency-inversion-principle">Dependency Inversion Principle</a><ul>
<li><a href="#inversion-of-control">Inversion of Control</a></li>
<li><a href="#where-to-decide-dependencies">Where To Decide Dependencies</a><ul>
<li><a href="#drawbacks-11">Drawbacks</a></li>
<li><a href="#application-6">Application</a></li>
</ul></li>
</ul></li>
</ul>
</nav>
<p></p>
<section id="introduction" class="level1">
<h1><a href="#introduction">Introduction</a></h1>
<p>Ruby on Rails is almost a decade old, and its community has developed a number of principles for building applications that are fast, fun and easy to change: Don't repeat yourself, keep your views dumb, keep your controllers skinny, and keep business logic in your models. These principles carry most applications to their first release or beyond.</p>
<p>However, these principles only get you so far. After a few releases, most applications begin to suffer. Models become fat, classes become few and large, tests become slow and changes become painful. In many applications, there comes a day when the developers realize that there's no going back; the application is a twisted mess and the only way out is a rewrite or a new job.</p>
<p>Fortunately, it doesn't have to be this way. Developers have been using object-oriented programming for several decades and there's a wealth of knowledge out there that still applies to developing applications today. We can use the lessons learned by these developers to write good Rails applications by applying good object-oriented programming.</p>
<p>Ruby Science will outline a process for detecting emerging problems in code and will dive into the solutions, old and new.</p>
<section id="code-reviews" class="level2">
<h2><a href="#code-reviews">Code Reviews</a></h2>
<p>Our first step toward better code is to review it.</p>
<p>Have you ever sent an email with typos? Did you review what you wrote before clicking &quot;Send&quot;? Reviewing your e-mails prevents mistakes and reviewing your code does the same.</p>
<p>To make it easier to review code, always work in a feature branch. The branch reduces the temptation to push unreviewed code or to wait too long to push code.</p>
<p>The first person who should review every line of your code is you. Before committing new code, read each changed line. Use git's <code>diff</code> and <code>--patch</code> features to examine code before you commit. Read more about these features using <code>git help add</code> and <code>git help commit</code>.</p>
<p>If you're working on a team, push your feature branch and invite your teammates to review the changes via <code>git diff origin/master..HEAD</code>.</p>
<p>Team review reveals how understandable code is to someone other than the author. Your team members' understanding now is a good indicator of your understanding in the future.</p>
<p>However, what should you and your teammates look for during review?</p>
</section>
<section id="follow-your-nose" class="level2">
<h2><a href="#follow-your-nose">Follow Your Nose</a></h2>
<p>Code &quot;smells&quot; are indicators something may be wrong. They are useful because they are easy to see—sometimes easier than the root cause of a problem.</p>
<p>When you review code, watch for smells. Consider whether refactoring the code to remove the smell would result in better code. If you're reviewing a teammate's feature branch, share your best refactoring ideas with him or her.</p>
<p>Smells are associated with one or more refactorings (example: remove the Long Method smell using the Extract Method refactoring). Learn these associations in order to quickly consider them during review and whether the result (example: several small methods) improves the code.</p>
<p>Don't treat code smells as bugs. It will be a waste of time to &quot;fix&quot; every smell. Not every smell is the symptom of a problem and despite your best intentions, you can accidentally introduce another smell or problem.</p>
</section>
<section id="removing-resistance" class="level2">
<h2><a href="#removing-resistance">Removing Resistance</a></h2>
<p>Another opportunity for refactoring is when you're having difficulty making a change to existing code. This is called &quot;resistance.&quot; The refactoring you choose depends on the type of resistance.</p>
<p>Is it hard to determine where new code belongs? The code is not readable enough. Rename methods and variables until it's obvious where your change belongs. This and every subsequent change will be easier. Refactor for readability first.</p>
<p>Is it hard to change the code without breaking existing code? Add extension points or extract code to be easier to reuse, and then try to introduce your change. Repeat this process until the change you want is easy to introduce.</p>
<p>Each change should be easy to introduce. If it's not, refactor.</p>
<p>When you are making your changes, you will be in a feature branch. Try to make your change without refactoring. If your meet resistance, make a &quot;work in progress&quot; commit, check out master and create a new refactoring branch:</p>
<pre><code>git commit -m 'wip: new feature'
git push
git checkout master
git checkout -b refactoring-for-new-feature</code></pre>
<p>Refactor until you fix the resistance you met on your feature branch. Then rebase your feature branch on top of your refactoring branch:</p>
<pre><code>git rebase -i new-feature
git checkout new-feature
git merge refactoring-for-new-feature --ff-only</code></pre>
<p>If the change is easier now, continue in your feature branch. If not, check out your refactoring branch and try again.</p>
</section>
<section id="bugs-and-churn" class="level2">
<h2><a href="#bugs-and-churn">Bugs and Churn</a></h2>
<p>If you're spending a lot of time swatting bugs, remove smells in the methods or classes of the buggy code. You'll make it less likely that a bug will be reintroduced.</p>
<p>After you commit a bug fix to a feature branch, find out if the code you changed to fix the bug is in files that change often. If the buggy code does change often, find smells and eliminate them. Separate the parts that change often from the parts that don't.</p>
<p>Conversely, avoid refactoring areas with low churn. Refactoring changes code and with each change, you risk introducing new bugs. If a file hasn't changed in six months, leave it alone. It may not be pretty, but you'll spend more time looking at it when you break it by trying to fix something that wasn't broken.</p>
</section>
<section id="tools-to-find-smells" class="level2">
<h2><a href="#tools-to-find-smells">Tools to Find Smells</a></h2>
<p>Some smells are easy to find while you're reading code and change sets, but other smells slip through the cracks without extra help.</p>
<p>Duplication is one of the hardest problems to find by hand. If you're using diffs during code reviews, it will be invisible when you copy and paste existing methods. The original method will be unchanged and won't show up in the diff, so unless the reviewer knows and remembers that the original existed, he or she won't notice that the copied method isn't just a new addition. Every duplicated piece of code is a bug waiting to happen.</p>
<p>Churn is similarly invisible, in that each change will look fine, and only the file's full history will reveal the smell.</p>
<p>Various tools are available which can aid you in your search for code smells.</p>
<p>Our favorite is <a href="https://codeclimate.com/">Code Climate</a>, which is a hosted tool and will scan your code for issues every time you push to Git. Code Climate attempts to locate hot spots for refactoring and assigns each class a simple A through F grade. It identifies complexity, duplication, churn and code smells.</p>
<p>If you're unable to use a hosted service, there are gems you can use locally, such as <a href="https://github.com/metricfu/metric_fu">metric_fu</a>, <a href="https://github.com/danmayer/churn">churn</a>, <a href="http://rubygems.org/gems/flog">flog</a>, <a href="http://rubygems.org/gems/flay">flay</a>, and <a href="https://github.com/troessner/reek/wiki">reek</a>. These gems can identify churn, complexity, duplication and smells.</p>
<p>Getting obsessed with the counts and scores from these tools will distract from the actual issues in your code, but it's worthwhile to run them continually and watch out for potential warning signs.</p>
</section>
<section id="how-to-read-this-book" class="level2">
<h2><a href="#how-to-read-this-book">How to Read This Book</a></h2>
<p>This book contains three catalogs: smells, solutions and principles.</p>
<p>Start by looking up a smell that sounds familiar. Each chapter on smells explains the potential problems each smell may reveal and references possible solutions.</p>
<p>Once you've identified the problem revealed by a smell, read the relevant solution chapter to learn how to fix it. Each solution chapter explains which problems it addresses and potential problems that can be introduced.</p>
<p>Lastly, smell and solution chapters reference related principles. The smell chapters reference principles that you can follow to avoid the root problem in the future. The solution chapters explain how each solution changes your code to follow related principles.</p>
<p>By following this process, you'll learn how to detect and fix actual problems in your code using smells and reusable solutions, and you'll learn about principles that you can follow to improve the code you write from the beginning.</p>
</section>
<section id="example-application" class="level2">
<h2><a href="#example-application">Example Application</a></h2>
<p>This book comes with a bundled example application, which you can find <a href="https://github.com/thoughtbot/ruby-science/tree/master/example_app">on GitHub</a>. Make sure that you sign into GitHub before attempting to view example application and commit links, or you'll receive a 404 error.</p>
<p>Most of the code samples included in the book come directly from commits in the example application. Several chapters link to the full commits for related changes. At any point, you can check out the application locally and check out those commits to explore solutions in progress.</p>
<p>For some solutions, the entire change is not included in the chapter for the sake of focus and brevity. However, you can see every change made for a solution in the example commits, including tests.</p>
<p>Make sure to take a look at the application's <a href="https://github.com/thoughtbot/ruby-science/blob/master/example_app/README.md">README</a>, as it contains a summary of the application and instructions for setting it up.</p>
<p></p>
</section>
</section>
<section id="long-method" class="level1">
<h1><a href="#long-method">Long Method</a></h1>
<p>The most common smell in Rails applications is the Long Method.</p>
<p>Long methods are exactly what they sound like: methods that are too long. They're easy to spot.</p>
<section id="symptoms" class="level3">
<h3><a href="#symptoms">Symptoms</a></h3>
<ul>
<li>If you can't tell exactly what a method does at a glance, it's too long.</li>
<li>Methods with more than one level of nesting are usually too long.</li>
<li>Methods with more than one level of abstraction may be too long.</li>
<li>Methods with a flog score of 10 or higher may be too long.</li>
</ul>
<p>You can watch out for long methods as you write them, but finding existing methods is easiest with tools like flog:</p>
<pre><code>% flog app lib
    72.9: flog total
     5.6: flog/method average

    15.7: QuestionsController#create       app/controllers/questions_controller.rb:9
    11.7: QuestionsController#new          app/controllers/questions_controller.rb:2
    11.0: Question#none
     8.1: SurveysController#create         app/controllers/surveys_controller.rb:6</code></pre>
<p>Methods with higher scores are more complicated. Anything with a score higher than 10 is worth looking at, but flog only helps you find potential trouble spots; use your own judgment when refactoring.</p>
</section>
<section id="example" class="level3">
<h3><a href="#example">Example</a></h3>
<p>For an example of a long method, let's take a look at the highest scored method from flog, <code>QuestionsController#create</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> create
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="ot">@submittable_type</span> = params[<span class="st">:submittable_type_id</span>]
  question_params = params.
    require(<span class="st">:question</span>).
    permit(<span class="st">:submittable_type</span>, <span class="st">:title</span>, <span class="st">:options_attributes</span>, <span class="st">:minimum</span>, <span class="st">:maximum</span>)
  <span class="ot">@question</span> = <span class="ot">@survey</span>.questions.new(question_params)
  <span class="ot">@question</span>.submittable_type = <span class="ot">@submittable_type</span>

  <span class="kw">if</span> <span class="ot">@question</span>.save
    redirect_to <span class="ot">@survey</span>
  <span class="kw">else</span>
    render <span class="st">:new</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
</section>
<section id="solutions" class="level3">
<h3><a href="#solutions">Solutions</a></h3>
<ul>
<li><a href="#extract-method">Extract method</a> is the most common way to break apart long methods.</li>
<li><a href="#replace-temp-with-query">Replace temp with query</a> if you have local variables in the method.</li>
</ul>
<p>After extracting methods, check for <a href="#feature-envy">feature envy</a> in the new methods to see if you should employ <a href="#move-method">move method</a> to provide the method with a better home.</p>
</section>
</section>
<section id="large-class" class="level1">
<h1><a href="#large-class">Large Class</a></h1>
<p>Most Rails applications suffer from several Large Classes. Large classes are difficult to understand and make it harder to change or reuse behavior. Tests for large classes are slow and churn tends to be higher, leading to more bugs and conflicts. Large classes likely also suffer from <a href="#divergent-change">divergent change</a>.</p>
<section id="symptoms-1" class="level3">
<h3><a href="#symptoms-1">Symptoms</a></h3>
<ul>
<li>You can't easily describe what the class does in one sentence.</li>
<li>You can't tell what the class does without scrolling.</li>
<li>The class needs to change for more than one reason.</li>
<li>The class has more than seven methods.</li>
<li>The class has a total flog score of 50.</li>
</ul>
</section>
<section id="example-1" class="level3">
<h3><a href="#example-1">Example</a></h3>
<p>This class has a high flog score, has a large number of methods, more private than public methods and has multiple responsibilities:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">class</span> <span class="dt">Question</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">ActiveModel</span>::<span class="dt">ForbiddenAttributesProtection</span>

  <span class="dt">SUBMITTABLE_TYPES</span> =<span class="ot"> %w(</span><span class="st">Open MultipleChoice Scale</span><span class="ot">)</span>.freeze

  validates <span class="st">:maximum</span>, presence: <span class="dv">true</span>, <span class="kw">if</span>: <span class="st">:scale?</span>
  validates <span class="st">:minimum</span>, presence: <span class="dv">true</span>, <span class="kw">if</span>: <span class="st">:scale?</span>
  validates <span class="st">:question_type</span>, presence: <span class="dv">true</span>, inclusion: <span class="dt">SUBMITTABLE_TYPES</span>
  validates <span class="st">:title</span>, presence: <span class="dv">true</span>

  belongs_to <span class="st">:survey</span>
  has_many <span class="st">:answers</span>
  has_many <span class="st">:options</span>

  accepts_nested_attributes_for <span class="st">:options</span>, reject_if: <span class="st">:all_blank</span>

  <span class="kw">def</span> summary
    <span class="kw">case</span> question_type
    <span class="kw">when</span> <span class="st">'MultipleChoice'</span>
      summarize_multiple_choice_answers
    <span class="kw">when</span> <span class="st">'Open'</span>
      summarize_open_answers
    <span class="kw">when</span> <span class="st">'Scale'</span>
      summarize_scale_answers
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">def</span> steps
    (minimum..maximum).to_a
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> scale?
    question_type == <span class="st">'Scale'</span>
  <span class="kw">end</span>

  <span class="kw">def</span> summarize_multiple_choice_answers
    total = answers.count
    counts = answers.group(<span class="st">:text</span>).order(<span class="st">'COUNT(*) DESC'</span>).count
    percents = counts.map <span class="kw">do</span> |text, count|
      percent = (<span class="fl">100.0</span> * count / total).round
      <span class="st">&quot;</span><span class="ot">#{</span>percent<span class="ot">}</span><span class="st">% </span><span class="ot">#{</span>text<span class="ot">}</span><span class="st">&quot;</span>
    <span class="kw">end</span>
    percents.join(<span class="st">', '</span>)
  <span class="kw">end</span>

  <span class="kw">def</span> summarize_open_answers
    answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>).join(<span class="st">', '</span>)
  <span class="kw">end</span>

  <span class="kw">def</span> summarize_scale_answers
    sprintf(<span class="st">'Average: %.02f'</span>, answers.average(<span class="st">'text'</span>))
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
</section>
<section id="solutions-1" class="level3">
<h3><a href="#solutions-1">Solutions</a></h3>
<ul>
<li><a href="#move-method">Move method</a> to move methods to another class if an existing class could better handle the responsibility.</li>
<li><a href="#extract-class">Extract class</a> if the class has multiple responsibilities.</li>
<li><a href="#replace-conditional-with-polymorphism">Replace conditional with polymorphism</a> if the class contains private methods related to conditional branches.</li>
<li><a href="#extract-value-object">Extract value object</a> if the class contains private query methods.</li>
<li><a href="#extract-decorator">Extract decorator</a> if the class contains delegation methods.</li>
<li><a href="#replace-subclasses-with-strategies">Replace subclasses with strategies</a> if the large class is a base class in an inheritance hierarchy.</li>
</ul>
</section>
<section id="prevention" class="level3">
<h3><a href="#prevention">Prevention</a></h3>
<p>Following the <a href="#single-responsibility-principle">single responsibility principle</a> will prevent large classes from cropping up. It's difficult for any class to become too large without taking on more than one responsibility.</p>
<p>Using <a href="#composition-over-inheritance">composition over inheritance</a> makes it easier to create small classes.</p>
<p>If a large portion of the class is devoted to instantiating subclasses, try following the <a href="#dependency-inversion-principle">dependency inversion principle</a>.</p>
<p>Following the <a href="#openclosed-principle">open/closed principle</a> will prevent large classes by preventing new concerns from being introduced.</p>
<p>You can use flog to analyze classes as you write and modify them:</p>
<pre><code>% flog -a app/models/question.rb
    48.3: flog total
     6.9: flog/method average

    15.6: Question#summarize_multiple_choice_answers app/models/question.rb:38
    12.0: Question#none
     6.3: Question#summary                 app/models/question.rb:17
     5.2: Question#summarize_open_answers  app/models/question.rb:48
     3.6: Question#summarize_scale_answers app/models/question.rb:52
     3.4: Question#steps                   app/models/question.rb:28
     2.2: Question#scale?                  app/models/question.rb:34</code></pre>
</section>
<section id="private-methods" class="level2">
<h2><a href="#private-methods">Private Methods</a></h2>
<p>In general, public methods are a greater liability than private methods. This is because it's harder to tell where public methods are used, so you need to take greater care when refactoring them. However, a large suite of private methods is also a strong indicator of a large class.</p>
<p>Private methods can't be reused between classes, which makes it more likely that code will be duplicated. Extracting private methods to new classes makes it easier for developers to do the right thing.</p>
<p>Additionally, private methods can't be tested directly. This makes it more difficult to write focused, simple unit tests, since the tests will need to go through one or more public methods. The further a test is from the code it tests, the harder it is to understand.</p>
<p>Lastly, private methods are often the easiest to extract to new classes. Large classes can be difficult to split up because of entangled dependencies between public and private methods.</p>
<p>Attempts to extract public methods will frequently halt when shared dependencies are discovered on private methods. Extracting the private behavior of a class into a small, reusable class is often the easiest first step towards splitting up a large class.</p>
<p>Keeping a class's public interface as small as possible is a best practice. However, keep an eye on your private interface as well. A maze of private dependencies is a good sign that your public interface is not cohesive and can be split into two or more classes.</p>
</section>
<section id="god-class" class="level2">
<h2><a href="#god-class">God Class</a></h2>
<p>A particular specimen of large class affects most Rails applications: the God class. A God class is any class that seems to know everything about an application. It has a reference to the majority of the other models and it's difficult to answer any question or perform any action in the application without going through this class.</p>
<p>Most applications have two God classes: the user, and the central focus of the application. For a todo list application, it will be user and todo; for photo sharing application, it will be user and photo.</p>
<p>You need to be particularly vigilant about refactoring these classes. If you don't start splitting up your God classes early on, it will become impossible to separate them without rewriting most of your application.</p>
<p>Treatment and prevention of God classes is the same as for any large class.</p>
</section>
</section>
<section id="feature-envy" class="level1">
<h1><a href="#feature-envy">Feature Envy</a></h1>
<p>Feature envy reveals a method (or method-to-be) that would work better on a different class.</p>
<p>Methods suffering from feature envy contain logic that is difficult to reuse because the logic is trapped within a method on the wrong class. These methods are also often private methods, which makes them unavailable to other classes. Moving the method (or the affected portion of a method) to a more appropriate class improves readability, makes the logic easier to reuse and reduces coupling.</p>
<section id="symptoms-2" class="level3">
<h3><a href="#symptoms-2">Symptoms</a></h3>
<ul>
<li>Repeated references to the same object.</li>
<li>Parameters or local variables that are used more than methods and instance variables of the class in question.</li>
<li>Methods that include a class name in their own names (such as <code>invite_user</code>).</li>
<li>Private methods on the same class that accept the same parameter.</li>
<li><a href="#law-of-demeter">Law of Demeter</a> violations.</li>
<li><a href="#tell-dont-ask">Tell, don't ask</a> violations.</li>
</ul>
</section>
<section id="example-2" class="level3">
<h3><a href="#example-2">Example</a></h3>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/completion.rb</span>
<span class="kw">def</span> score
  answers.inject(<span class="dv">0</span>) <span class="kw">do</span> |result, answer|
    question = answer.question
    result + question.score(answer.text)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The <code>answer</code> local variable is used twice in the block: once to get its <code>question</code>, and once to get its <code>text</code>. This tells us that we can probably extract a new method and move it to the <code>answer</code> class.</p>
</section>
<section id="solutions-2" class="level3">
<h3><a href="#solutions-2">Solutions</a></h3>
<ul>
<li><a href="#extract-method">Extract method</a> if only part of the method suffers from feature envy; then move the method.</li>
<li><a href="#move-method">Move method</a> if the entire method suffers from feature envy.</li>
<li><a href="#inline-class">Inline class</a> if the envied class isn't pulling its weight.</li>
</ul>
</section>
<section id="prevention-1" class="level3">
<h3><a href="#prevention-1">Prevention</a></h3>
<p>Following the <a href="#law-of-demeter">law of Demeter</a> will prevent a lot of feature envy by limiting the dependencies of each method.</p>
<p>Following <a href="#tell-dont-ask">tell, don't ask</a> will prevent feature envy by avoiding unnecessary inspection of another object's state.</p>
</section>
</section>
<section id="case-statement" class="level1">
<h1><a href="#case-statement">Case Statement</a></h1>
<p>Case Statements are a sign that a method contains too much knowledge.</p>
<section id="symptoms-3" class="level3">
<h3><a href="#symptoms-3">Symptoms</a></h3>
<ul>
<li>Case statements that check the class of an object.</li>
<li>Case statements that check a type code.</li>
<li><a href="#divergent-change">Divergent change</a> caused by changing or adding <code>when</code> clauses.</li>
<li><a href="#shotgun-surgery">Shotgun surgery</a> caused by duplicating the case statement.</li>
</ul>
<p>Actual <code>case</code> statements are extremely easy to find. Just grep your codebase for &quot;case.&quot; However, you should also be on the lookout for <code>case</code>'s sinister cousin, the repetitive <code>if-elsif</code>.</p>
</section>
<section id="type-codes" class="level2">
<h2><a href="#type-codes">Type Codes</a></h2>
<p>Some applications contain type codes—fields that store type information about objects. These fields are easy to add and seem innocent, but result in code that's harder to maintain. A better solution is to take advantage of Ruby's ability to invoke different behavior based on an object's class, called &quot;dynamic dispatch.&quot; Using a case statement with a type code inelegantly reproduces dynamic dispatch.</p>
<p>The special <code>type</code> column that ActiveRecord uses is not necessarily a type code. The <code>type</code> column is used to serialize an object's class to the database so that the correct class can be instantiated later on. If you're just using the <code>type</code> column to let ActiveRecord decide which class to instantiate, this isn't a smell. However, make sure to avoid referencing the <code>type</code> column from <code>case</code> or <code>if</code> statements.</p>
<section id="example-3" class="level3">
<h3><a href="#example-3">Example</a></h3>
<p>This method summarizes the answers to a question. The summary varies based on the type of question.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summary
  <span class="kw">case</span> question_type
  <span class="kw">when</span> <span class="st">'MultipleChoice'</span>
    summarize_multiple_choice_answers
  <span class="kw">when</span> <span class="st">'Open'</span>
    summarize_open_answers
  <span class="kw">when</span> <span class="st">'Scale'</span>
    summarize_scale_answers
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<p>Note that many applications replicate the same <code>case</code> statement, which is a more serious offence. This view duplicates the <code>case</code> logic from <code>Question#summary</code>, this time in the form of multiple <code>if</code> statements:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/_question.html.erb
<span class="kw">&lt;%</span> <span class="kw">if</span> question.question_type <span class="ch">==</span> <span class="st">'MultipleChoice'</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;ol&gt;</span>
    <span class="kw">&lt;%</span> question.options.each <span class="kw">do</span> <span class="ch">|</span>option<span class="ch">|</span> <span class="kw">-%&gt;</span>
      <span class="kw">&lt;li&gt;</span>
        <span class="kw">&lt;%=</span> submission_fields.radio_button <span class="st">:text</span>, option.text, id: dom_id(option) <span class="kw">%&gt;</span>
        <span class="kw">&lt;%=</span> content_tag <span class="st">:label</span>, option.text, <span class="kw">for</span>: dom_id(option) <span class="kw">%&gt;</span>
      <span class="kw">&lt;/li&gt;</span>
    <span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;/ol&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>

<span class="kw">&lt;%</span> <span class="kw">if</span> question.question_type <span class="ch">==</span> <span class="st">'Scale'</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;ol&gt;</span>
    <span class="kw">&lt;%</span> question.steps.each <span class="kw">do</span> <span class="ch">|</span>step<span class="ch">|</span> <span class="kw">-%&gt;</span>
      <span class="kw">&lt;li&gt;</span>
        <span class="kw">&lt;%=</span> submission_fields.radio_button <span class="st">:text</span>, step <span class="kw">%&gt;</span>
        <span class="kw">&lt;%=</span> submission_fields.label <span class="st">&quot;text_</span><span class="ot">#{</span>step<span class="ot">}</span><span class="st">&quot;</span>, label: step <span class="kw">%&gt;</span>
      <span class="kw">&lt;/li&gt;</span>
    <span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;/ol&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
</section>
<section id="solutions-3" class="level3">
<h3><a href="#solutions-3">Solutions</a></h3>
<ul>
<li><a href="#replace-type-code-with-subclasses">Replace type code with subclasses</a> if the <code>case</code> statement is checking a type code, such as <code>question_type</code>.</li>
<li><a href="#replace-conditional-with-polymorphism">Replace conditional with polymorphism</a> when the <code>case</code> statement is checking the class of an object.</li>
<li><a href="#use-convention-over-configuration">Use convention over configuration</a> when selecting a strategy based on a string name.</li>
</ul>
</section>
</section>
</section>
<section id="shotgun-surgery" class="level1">
<h1><a href="#shotgun-surgery">Shotgun Surgery</a></h1>
<p>Shotgun Surgery is usually a more obvious symptom that reveals another smell.</p>
<section id="symptoms-4" class="level3">
<h3><a href="#symptoms-4">Symptoms</a></h3>
<ul>
<li>You have to make the same small change across several different files.</li>
<li>Changes become difficult to manage because they are hard to keep track of.</li>
</ul>
<p>Make sure you look for related smells in the affected code:</p>
<ul>
<li><a href="#duplicated-code">Duplicated code</a></li>
<li><a href="#case-statement">Case statement</a></li>
<li><a href="#feature-envy">Feature envy</a></li>
<li><a href="#long-parameter-list">Long parameter list</a></li>
</ul>
</section>
<section id="example-4" class="level3">
<h3><a href="#example-4">Example</a></h3>
<p>Users' names are formatted and displayed as &quot;First Last&quot; throughout the application. If you want to change the formatting to include a middle initial (example: &quot;First M. Last&quot;) you'll need to make the same small change in several places.</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/users/show.html.erb
<span class="kw">&lt;%=</span> current_user.first_name <span class="kw">%&gt;</span> <span class="kw">&lt;%=</span> current_user.last_name <span class="kw">%&gt;</span>

# app/views/users/index.html.erb
<span class="kw">&lt;%=</span> current_user.first_name <span class="kw">%&gt;</span> <span class="kw">&lt;%=</span> current_user.last_name <span class="kw">%&gt;</span>

# app/views/layouts/application.html.erb
<span class="kw">&lt;%=</span> current_user.first_name <span class="kw">%&gt;</span> <span class="kw">&lt;%=</span> current_user.last_name <span class="kw">%&gt;</span>

# app/views/mailers/completion_notification.html.erb
<span class="kw">&lt;%=</span> current_user.first_name <span class="kw">%&gt;</span> <span class="kw">&lt;%=</span> current_user.last_name <span class="kw">%&gt;</span></code></pre>
</section>
<section id="solutions-4" class="level3">
<h3><a href="#solutions-4">Solutions</a></h3>
<ul>
<li><a href="#replace-conditional-with-polymorphism">Replace conditional with polymorphism</a> to replace duplicated <code>case</code> statements and <code>if-elsif</code> blocks.</li>
<li><a href="#replace-conditional-with-null-object">Replace conditional with null object</a> if changing a method to return <code>nil</code> would require checks for <code>nil</code> in several places.</li>
<li><a href="#extract-decorator">Extract decorator</a> to replace duplicated display code in views/templates.</li>
<li><a href="#introduce-parameter-object">Introduce parameter object</a> to hang useful formatting methods alongside a data clump of related attributes.</li>
<li><a href="#use-convention-over-configuration">Use convention over configuration</a> to eliminate small steps that can be inferred based on a convention, such as a name.</li>
<li><a href="#inline-class">Inline class</a> if the class only serves to add extra steps when performing changes.</li>
</ul>
</section>
<section id="prevention-2" class="level3">
<h3><a href="#prevention-2">Prevention</a></h3>
<p>If your changes become spread out because you need to pass information between boundaries for dependencies, try <a href="#dependency-inversion-principle">inverting control</a>.</p>
<p>If you find yourself repeating the exact same change in several places, make sure that you <a href="#dry">Don't Repeat Yourself</a>.</p>
<p>If you need to change several places because of a modification in your dependency chain, such as changing <code>user.plan.price</code> to <code>user.account.plan.price</code>, make sure that you're following the <a href="#law-of-demeter">law of Demeter</a>.</p>
<p>If conditional logic is affected in several places by a single, cohesive change, make sure that you're following <a href="#tell-dont-ask">tell, don't ask</a>.</p>
</section>
</section>
<section id="divergent-change" class="level1">
<h1><a href="#divergent-change">Divergent Change</a></h1>
<p>A class suffers from Divergent Change when it changes for multiple reasons.</p>
<section id="symptoms-5" class="level3">
<h3><a href="#symptoms-5">Symptoms</a></h3>
<ul>
<li>You can't easily describe what the class does in one sentence.</li>
<li>The class is changed more frequently than other classes in the application.</li>
<li>Different changes to the class aren't related to each other.</li>
</ul>
<p></p>
</section>
<section id="example-5" class="level3">
<h3><a href="#example-5">Example</a></h3>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">class</span> <span class="dt">SummariesController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="kw">def</span> show
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
    <span class="ot">@summaries</span> = <span class="ot">@survey</span>.summarize(summarizer)
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> summarizer
    <span class="kw">case</span> params[<span class="st">:id</span>]
    <span class="kw">when</span> <span class="st">'breakdown'</span>
      <span class="dt">Breakdown</span>.new
    <span class="kw">when</span> <span class="st">'most_recent'</span>
      <span class="dt">MostRecent</span>.new
    <span class="kw">when</span> <span class="st">'your_answers'</span>
      <span class="dt">UserAnswer</span>.new(current_user)
    <span class="kw">else</span>
      raise <span class="st">&quot;Unknown summary type: </span><span class="ot">#{</span>params[<span class="st">:id</span>]<span class="ot">}</span><span class="st">&quot;</span>
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This controller has many reasons to change:</p>
<ul>
<li>Control flow logic related to summaries, such as authentication.</li>
<li>Any instance in which a summarizer strategy is added or changed.</li>
</ul>
</section>
<section id="solutions-5" class="level3">
<h3><a href="#solutions-5">Solutions</a></h3>
<ul>
<li><a href="#extract-class">Extract class</a> to move one cause of change to a new class.</li>
<li><a href="#move-method">Move method</a> if the class is changing because of methods that relate to another class.</li>
<li><a href="#extract-validator">Extract validator</a> to move validation logic out of models.</li>
<li><a href="#introduce-form-object">Introduce form object</a> to move form logic out of controllers.</li>
<li><a href="#use-convention-over-configuration">Use convention over configuration</a> to eliminate changes that can be inferred by a convention, such as a name.</li>
</ul>
</section>
<section id="prevention-3" class="level3">
<h3><a href="#prevention-3">Prevention</a></h3>
<p>You can prevent divergent change from occurring by following the <a href="#single-responsibility-principle">single responsibility principle</a>. If a class has only one responsibility, it has only one reason to change.</p>
<p>Following the <a href="#openclosed-principle">open/closed principle</a> limits future changes to classes, including divergent change.</p>
<p>Following <a href="#composition-over-inheritance">composition over inheritance</a> will make it easier to create small classes, preventing divergent change.</p>
<p>If a large portion of the class is devoted to instantiating subclasses, try following the <a href="#dependency-inversion-principle">dependency inversion principle</a>.</p>
<p>You can use churn to discover which files are changing most frequently. This isn't a direct relationship, but frequently changed files often have more than one responsibility and thus more than one reason to change.</p>
</section>
</section>
<section id="long-parameter-list" class="level1">
<h1><a href="#long-parameter-list">Long Parameter List</a></h1>
<p>Ruby supports positional method arguments which can lead to Long Parameter Lists.</p>
<section id="symptoms-6" class="level3">
<h3><a href="#symptoms-6">Symptoms</a></h3>
<ul>
<li>You can't easily change the method's arguments.</li>
<li>The method has three or more arguments.</li>
<li>The method is complex due to number of collaborating parameters.</li>
<li>The method requires large amounts of setup during isolated testing.</li>
</ul>
<p></p>
</section>
<section id="example-6" class="level3">
<h3><a href="#example-6">Example</a></h3>
<p>Look at this mailer for an example of long parameter list.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/mailers/mailer.rb</span>
<span class="kw">class</span> <span class="dt">Mailer</span> &lt; <span class="dt">ActionMailer</span>::<span class="dt">Base</span>
  default from: <span class="st">&quot;from@example.com&quot;</span>

  <span class="kw">def</span> completion_notification(first_name, last_name, email)
    <span class="ot">@first_name</span> = first_name
    <span class="ot">@last_name</span> = last_name

    mail(
      to: email,
      subject: <span class="st">'Thank you for completing the survey'</span>
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
</section>
<section id="solutions-6" class="level3">
<h3><a href="#solutions-6">Solutions</a></h3>
<ul>
<li><p><a href="#introduce-parameter-object">Introduce parameter object</a> and pass it in as an object of naturally grouped attributes.</p></li>
<li><p><a href="#extract-class">Extract class</a> if the method is complex due to the number of collaborators.</p></li>
</ul>
</section>
<section id="anti-solution" class="level3">
<h3><a href="#anti-solution">Anti-Solution</a></h3>
<p>A common technique used to mask a long parameter list is grouping parameters using a hash of named parameters; this will replace connascence of position with connascence of name (a good first step). However, it will not reduce the number of collaborators in the method.</p>
</section>
</section>
<section id="duplicated-code" class="level1">
<h1><a href="#duplicated-code">Duplicated Code</a></h1>
<p>One of the first principles we're taught as developers: <a href="#dry">Don't Repeat Yourself</a>.</p>
<section id="symptoms-7" class="level3">
<h3><a href="#symptoms-7">Symptoms</a></h3>
<ul>
<li>You find yourself copying and pasting code from one place to another.</li>
<li><a href="#shotgun-surgery">Shotgun surgery</a> occurs when changes to your application require the same small edits in multiple places.</li>
</ul>
<p></p>
</section>
<section id="example-7" class="level3">
<h3><a href="#example-7">Example</a></h3>
<p>The <code>QuestionsController</code> suffers from duplication in the <code>create</code> and <code>update</code> methods.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
<span class="kw">def</span> create
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  question_params = params.
    require(<span class="st">:question</span>).
    permit(<span class="st">:title</span>, <span class="st">:options_attributes</span>, <span class="st">:minimum</span>, <span class="st">:maximum</span>)
  <span class="ot">@question</span> = type.constantize.new(question_params)
  <span class="ot">@question</span>.survey = <span class="ot">@survey</span>

  <span class="kw">if</span> <span class="ot">@question</span>.save
    redirect_to <span class="ot">@survey</span>
  <span class="kw">else</span>
    render <span class="st">:new</span>
  <span class="kw">end</span>
<span class="kw">end</span>

<span class="kw">def</span> update
  <span class="ot">@question</span> = <span class="dt">Question</span>.find(params[<span class="st">:id</span>])
  question_params = params.
    require(<span class="st">:question</span>).
    permit(<span class="st">:title</span>, <span class="st">:options_attributes</span>, <span class="st">:minimum</span>, <span class="st">:maximum</span>)
  <span class="ot">@question</span>.update_attributes(question_params)

  <span class="kw">if</span> <span class="ot">@question</span>.save
    redirect_to <span class="ot">@question</span>.survey
  <span class="kw">else</span>
    render <span class="st">:edit</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
</section>
<section id="solutions-7" class="level3">
<h3><a href="#solutions-7">Solutions</a></h3>
<ul>
<li><a href="#extract-method">Extract method</a> for duplicated code in the same file.</li>
<li><a href="#extract-class">Extract class</a> for duplicated code across multiple files.</li>
<li><a href="#extract-partial">Extract partial</a> for duplicated view and template code.</li>
<li><a href="#replace-conditional-with-polymorphism">Replace conditional with polymorphism</a> for duplicated conditional logic.</li>
<li><a href="#replace-conditional-with-null-object">Replace conditional with null object</a> to remove duplicated checks for <code>nil</code> values.</li>
</ul>
</section>
<section id="prevention-4" class="level3">
<h3><a href="#prevention-4">Prevention</a></h3>
<p>Following the <a href="#single-responsibility-principle">single responsibility principle</a> will result in small classes that are easier to reuse, reducing the temptation of duplication.</p>
</section>
</section>
<section id="uncommunicative-name" class="level1">
<h1><a href="#uncommunicative-name">Uncommunicative Name</a></h1>
<p>Software is run by computers—but written and read by humans. Names provide important information to developers who are trying to understand a piece of code. Patterns and challenges when naming a method or class can also provide clues for refactoring.</p>
<section id="symptoms-8" class="level3">
<h3><a href="#symptoms-8">Symptoms</a></h3>
<ul>
<li>Difficulty understanding a method or class.</li>
<li>Methods or classes with similar names but dissimilar functionality.</li>
<li>Redundant names, such as names that include the type of object to which they refer.</li>
</ul>
</section>
<section id="example-8" class="level3">
<h3><a href="#example-8">Example</a></h3>
<p>In our example application, the <code>SummariesController</code> generates summaries from a <code>Survey</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="ot">@summaries</span> = <span class="ot">@survey</span>.summarize(summarizer)</code></pre>
<p>The <code>summarize</code> method on <code>Survey</code> asks each <code>Question</code> to <code>summarize</code> itself using a <code>summarizer</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summarize(summarizer)
  questions.map <span class="kw">do</span> |question|
    question.summarize(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The <code>summarize</code> method on <code>Question</code> gets a value by calling <code>summarize</code> on a summarizer, and then builds a <code>Summary</code> using that value.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summarize(summarizer)
  value = summarizer.summarize(<span class="dv">self</span>)
  <span class="dt">Summary</span>.new(title, value)
<span class="kw">end</span></code></pre>
<p>There are several summarizer classes, each of which respond to <code>summarize</code>.</p>
<p>If you're lost, don't worry: You're not the only one. The confusing maze of similar names makes this example extremely hard to follow.</p>
<p>See <a href="#rename-method">rename method</a> to see how we improve the situation.</p>
</section>
<section id="solutions-8" class="level3">
<h3><a href="#solutions-8">Solutions</a></h3>
<ul>
<li><a href="#rename-method">Rename method</a> if a well-factored method isn't well named.</li>
<li><a href="#extract-class">Extract class</a> if a class is doing too much to have a meaningful name.</li>
<li><a href="#extract-method">Extract method</a> if a method is doing too much to have a meaningful name.</li>
<li><a href="#inline-class">Inline class</a> if a class is too abstract to have a meaningful name.</li>
</ul>
</section>
</section>
<section id="single-table-inheritance-sti" class="level1">
<h1><a href="#single-table-inheritance-sti">Single Table Inheritance (STI)</a></h1>
<p>Using subclasses is a common method of achieving reuse in object-oriented software. Rails provides a mechanism for storing instances of different classes in the same table, called Single Table Inheritance. Rails takes care of most of the details by writing the class's name to the type column and instantiating the correct class when results come back from the database.</p>
<p>Inheritance has its own pitfalls (see <a href="#composition-over-inheritance">composition over inheritance</a>) and STI introduces a few new gotchas that may compel you to consider an alternate solution.</p>
<section id="symptoms-9" class="level3">
<h3><a href="#symptoms-9">Symptoms</a></h3>
<ul>
<li>You need to change from one subclass to another.</li>
<li>Behavior is shared among some subclasses but not others.</li>
<li>One subclass is a fusion of one or more other subclasses.</li>
</ul>
<p></p>
</section>
<section id="example-9" class="level3">
<h3><a href="#example-9">Example</a></h3>
<p>This method on <code>Question</code> changes the question to a new type. Any necessary attributes for the new subclass are provided to the <code>attributes</code> method.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> switch_to(type, new_attributes)
  attributes = <span class="dv">self</span>.attributes.merge(new_attributes)
  new_question = type.constantize.new(attributes.except(<span class="st">'id'</span>, <span class="st">'type'</span>))
  new_question.id = id

  <span class="kw">begin</span>
    <span class="dt">Question</span>.transaction <span class="kw">do</span>
      destroy
      new_question.save!
    <span class="kw">end</span>
  <span class="kw">rescue</span> <span class="dt">ActiveRecord</span>::<span class="dt">RecordInvalid</span>
  <span class="kw">end</span>

  new_question
<span class="kw">end</span></code></pre>
<p>This transition is difficult for a number of reasons:</p>
<ul>
<li>You need to worry about common <code>Question</code> validations.</li>
<li>You need to make sure validations for the old subclass are not used.</li>
<li>You need to make sure validations for the new subclass are used.</li>
<li>You need to delete data from the old subclass, including associations.</li>
<li>You need to support data from the new subclass.</li>
<li>Common attributes need to remain the same.</li>
</ul>
<p>The implementation achieves all these requirements, but is awkward:</p>
<ul>
<li>You can't actually change the class of an instance in Ruby, so you need to return the instance of the new class.</li>
<li>The implementation requires deleting and creating records, but part of the transaction (<code>destroy</code>) must execute before you can validate the new instance. This results in control flow using exceptions.</li>
<li>The STI abstraction leaks into the model, because it needs to understand that it has a <code>type</code> column. STI models normally don't need to understand that they're implemented using STI.</li>
<li>It's hard to understand why this method is implemented the way it is, so other developers fixing bugs or refactoring in the future will have a hard time navigating it.</li>
</ul>
</section>
<section id="solutions-9" class="level3">
<h3><a href="#solutions-9">Solutions</a></h3>
<ul>
<li>If you're using STI to reuse common behavior, use <a href="#replace-subclasses-with-strategies">replace subclasses with strategies</a> to switch to a composition-based model.</li>
<li>If you're using STI so that you can easily refer to several different classes in the same table, switch to using a polymorphic association instead.</li>
</ul>
</section>
<section id="prevention-5" class="level3">
<h3><a href="#prevention-5">Prevention</a></h3>
<p>By following <a href="#composition-over-inheritance">composition over inheritance</a>, you'll use STI as a solution less often.</p>
</section>
</section>
<section id="comments" class="level1">
<h1><a href="#comments">Comments</a></h1>
<p>Comments can be used appropriately to introduce classes and provide documentation. But used incorrectly, they mask readability and process problems by further obfuscating already unreadable code.</p>
<section id="symptoms-10" class="level3">
<h3><a href="#symptoms-10">Symptoms</a></h3>
<ul>
<li>Comments within method bodies.</li>
<li>More than one comment per method.</li>
<li>Comments that restate the method name in English.</li>
<li>Todo comments.</li>
<li>Commented out, dead code.</li>
</ul>
</section>
<section id="example-10" class="level3">
<h3><a href="#example-10">Example</a></h3>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_question.rb</span>
<span class="kw">def</span> summary
  <span class="co"># Text for each answer in order as a comma-separated string</span>
  answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>).join(<span class="st">', '</span>)
<span class="kw">end</span></code></pre>
<p>This comment is trying to explain what the following line of code does because the code itself is too hard to understand. A better solution would be to improve the legibility of the code.</p>
<p>Some comments add no value at all and can safely be removed:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">Invitation</span>
  <span class="co"># Deliver the invitation</span>
  <span class="kw">def</span> deliver
    <span class="dt">Mailer</span>.invitation_notification(<span class="dv">self</span>, message).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>If there isn't a useful explanation to provide for a method or class beyond the name, don't leave a comment.</p>
</section>
<section id="solutions-10" class="level3">
<h3><a href="#solutions-10">Solutions</a></h3>
<ul>
<li><a href="#introduce-explaining-variable">Introduce explaining variable</a> to make obfuscated lines easier to read in pieces.</li>
<li><a href="#extract-method">Extract method</a> to break up methods that are difficult to read.</li>
<li>Move todo comments into a task management system.</li>
<li>Delete commented out code and rely on version control in the event that you want to get it back.</li>
<li>Delete superfluous comments that don't add more value than the method or class name.</li>
</ul>
</section>
</section>
<section id="mixin" class="level1">
<h1><a href="#mixin">Mixin</a></h1>
<p>Inheritance is a common method of reuse in object-oriented software. Ruby supports single inheritance using subclasses and multiple inheritance using Mixins. Mixins can be used to package common helpers or provide a common public interface.</p>
<p>However, mixins have some drawbacks:</p>
<ul>
<li>They use the same namespace as classes they're mixed into, which can cause naming conflicts.</li>
<li>Although they have access to instance variables from classes they're mixed into, mixins can't easily accept initializer arguments, so they can't have their own state.</li>
<li>They inflate the number of methods available in a class.</li>
<li>They're not easy to add and remove at runtime.</li>
<li>They're difficult to test in isolation, since they can't be instantiated.</li>
</ul>
<section id="symptoms-11" class="level3">
<h3><a href="#symptoms-11">Symptoms</a></h3>
<ul>
<li>Methods in mixins that accept the same parameters over and over.</li>
<li>Methods in mixins that don't reference the state of the class they're mixed into.</li>
<li>Business logic that can't be used without using the mixin.</li>
<li>Classes that have few public methods except those from a mixin.</li>
<li><a href="#dependency-inversion-principle">Inverting dependencies</a> is difficult because mixins can't accept parameters.</li>
</ul>
</section>
<section id="example-11" class="level3">
<h3><a href="#example-11">Example</a></h3>
<p>In our example application, users can invite their friends by email to take surveys. If an invited email matches an existing user, a private message will be created. Otherwise, a message is sent to that email address with a link.</p>
<p>The logic to generate the invitation message is the same regardless of the delivery mechanism, so this behavior is encapsulated in a mixin:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/inviter.rb</span>
<span class="kw">module</span> <span class="dt">Inviter</span>
  extend <span class="dt">ActiveSupport</span>::<span class="dt">Concern</span>

  included <span class="kw">do</span>
    <span class="kw">include</span> <span class="dt">AbstractController</span>::<span class="dt">Rendering</span>
    <span class="kw">include</span> <span class="dt">Rails</span>.application.routes.url_helpers

    <span class="dv">self</span>.view_paths = <span class="st">'app/views'</span>
    <span class="dv">self</span>.default_url_options = <span class="dt">ActionMailer</span>::<span class="dt">Base</span>.default_url_options
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> render_message_body
    render template: <span class="st">'invitations/message'</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<p>Each delivery strategy mixes in <code>Inviter</code> and calls <code>render_message_body</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/message_inviter.rb</span>
<span class="kw">class</span> <span class="dt">MessageInviter</span> &lt; <span class="dt">AbstractController</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">Inviter</span>

  <span class="kw">def</span> initialize(invitation, recipient)
    <span class="ot">@invitation</span> = invitation
    <span class="ot">@recipient</span> = recipient
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Message</span>.create!(
      recipient: <span class="ot">@recipient</span>,
      sender: <span class="ot">@invitation</span>.sender,
      body: render_message_body
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Although the mixin does a good job of preventing <a href="#duplicated-code">duplicated code</a>, it's difficult to test or understand in isolation, it obfuscates the inviter classes, and it tightly couples the inviter classes to a particular message body implementation.</p>
</section>
<section id="solutions-11" class="level3">
<h3><a href="#solutions-11">Solutions</a></h3>
<ul>
<li><a href="#extract-class">Extract class</a> to liberate business logic trapped in mixins.</li>
<li><a href="#replace-mixin-with-composition">Replace mixin with composition</a> to improve testability, flexibility and readability.</li>
</ul>
</section>
<section id="prevention-6" class="level3">
<h3><a href="#prevention-6">Prevention</a></h3>
<p>Mixins are a form of inheritance. By following <a href="#composition-over-inheritance">composition over inheritance</a>, you'll be less likely to introduce mixins.</p>
<p>Reserve mixins for reusable framework code like common associations and callbacks, and you'll end up with a more flexible and comprehensible system.</p>
</section>
</section>
<section id="callback" class="level1">
<h1><a href="#callback">Callback</a></h1>
<p>Callbacks are a convenient way to decorate the default <code>save</code> method with custom persistence logic, without the drudgery of template methods, overriding, or calling <code>super</code>.</p>
<p>However, callbacks are frequently abused by adding non-persistence logic to the persistence life cycle, such as sending emails or processing payments. Models riddled with callbacks are harder to refactor and prone to bugs, such as accidentally sending emails or performing external changes before a database transaction is committed.</p>
<section id="symptoms-12" class="level3">
<h3><a href="#symptoms-12">Symptoms</a></h3>
<ul>
<li>Callbacks containing business logic, such as processing payments.</li>
<li>Attributes that allow certain callbacks to be skipped.</li>
<li>Methods such as <code>save_without_sending_email</code>, which skip callbacks.</li>
<li>Callbacks that need to be invoked conditionally.</li>
</ul>
<p></p>
</section>
<section id="example-12" class="level3">
<h3><a href="#example-12">Example</a></h3>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> deliver_invitations
  recipients.map <span class="kw">do</span> |recipient_email|
    <span class="dt">Invitation</span>.create!(
      survey: survey,
      sender: sender,
      recipient_email: recipient_email,
      status: <span class="st">'pending'</span>,
      message: <span class="ot">@message</span>
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
after_create <span class="st">:deliver</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">def</span> deliver
  <span class="dt">Mailer</span>.invitation_notification(<span class="dv">self</span>).deliver
<span class="kw">end</span></code></pre>
<p>In the above code, the <code>SurveyInviter</code> is simply creating <code>Invitation</code> records, and the actual delivery of the invitation email is hidden behind <code>Invitation.create!</code> via a callback.</p>
<p>If one of several invitations fails to save, the user will see a 500 page, but some of the invitations will already have been saved and delivered. The user will be unable to tell which invitations were sent.</p>
<p>Because delivery is coupled with persistence, there's no way to make sure that all of the invitations are saved before starting to deliver emails.</p>
</section>
<section id="solutions-12" class="level3">
<h3><a href="#solutions-12">Solutions</a></h3>
<ul>
<li><a href="#replace-callback-with-method">Replace callback with method</a> if the callback logic is unrelated to persistence.</li>
</ul>
<p></p>
</section>
</section>
<section id="replace-conditional-with-polymorphism" class="level1">
<h1><a href="#replace-conditional-with-polymorphism">Replace Conditional with Polymorphism</a></h1>
<p>Conditional code clutters methods, makes extraction and reuse harder and can lead to leaky concerns. Object-oriented languages like Ruby allow developers to avoid conditionals using polymorphism. Rather than using <code>if</code>/<code>else</code> or <code>case</code>/<code>when</code> to create a conditional path for each possible situation, you can implement a method differently in different classes, adding (or reusing) a class for each situation.</p>
<p>Replacing conditional code allows you to move decisions to the best point in the application. Depending on polymorphic interfaces will create classes that don't need to change when the application changes.</p>
<section id="uses" class="level3">
<h3><a href="#uses">Uses</a></h3>
<ul>
<li>Removes <a href="#divergent-change">divergent change</a> from classes that need to alter their behavior based on the outcome of the condition.</li>
<li>Prevents <a href="#shotgun-surgery">shotgun surgery</a> from adding new types.</li>
<li>Removes <a href="#feature-envy">feature envy</a> by allowing dependent classes to make their own decisions.</li>
<li>Makes it easier to remove <a href="#duplicated-code">duplicated code</a> by taking behavior out of conditional clauses and private methods.</li>
<li>Makes conditional logic easier to reuse, which makes it easier to <a href="#dry">avoid duplication</a>.</li>
<li>Replaces conditional logic with simple commands, following <a href="#tell-dont-ask">tell, don't ask</a>.</li>
</ul>
</section>
<section id="example-13" class="level3">
<h3><a href="#example-13">Example</a></h3>
<p>This <code>Question</code> class summarizes its answers differently depending on its <code>question_type</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">class</span> <span class="dt">Question</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">ActiveModel</span>::<span class="dt">ForbiddenAttributesProtection</span>

  <span class="dt">SUBMITTABLE_TYPES</span> =<span class="ot"> %w(</span><span class="st">Open MultipleChoice Scale</span><span class="ot">)</span>.freeze

  validates <span class="st">:maximum</span>, presence: <span class="dv">true</span>, <span class="kw">if</span>: <span class="st">:scale?</span>
  validates <span class="st">:minimum</span>, presence: <span class="dv">true</span>, <span class="kw">if</span>: <span class="st">:scale?</span>
  validates <span class="st">:question_type</span>, presence: <span class="dv">true</span>, inclusion: <span class="dt">SUBMITTABLE_TYPES</span>
  validates <span class="st">:title</span>, presence: <span class="dv">true</span>

  belongs_to <span class="st">:survey</span>
  has_many <span class="st">:answers</span>
  has_many <span class="st">:options</span>

  accepts_nested_attributes_for <span class="st">:options</span>, reject_if: <span class="st">:all_blank</span>

  <span class="kw">def</span> summary
    <span class="kw">case</span> question_type
    <span class="kw">when</span> <span class="st">'MultipleChoice'</span>
      summarize_multiple_choice_answers
    <span class="kw">when</span> <span class="st">'Open'</span>
      summarize_open_answers
    <span class="kw">when</span> <span class="st">'Scale'</span>
      summarize_scale_answers
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">def</span> steps
    (minimum..maximum).to_a
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> scale?
    question_type == <span class="st">'Scale'</span>
  <span class="kw">end</span>

  <span class="kw">def</span> summarize_multiple_choice_answers
    total = answers.count
    counts = answers.group(<span class="st">:text</span>).order(<span class="st">'COUNT(*) DESC'</span>).count
    percents = counts.map <span class="kw">do</span> |text, count|
      percent = (<span class="fl">100.0</span> * count / total).round
      <span class="st">&quot;</span><span class="ot">#{</span>percent<span class="ot">}</span><span class="st">% </span><span class="ot">#{</span>text<span class="ot">}</span><span class="st">&quot;</span>
    <span class="kw">end</span>
    percents.join(<span class="st">', '</span>)
  <span class="kw">end</span>

  <span class="kw">def</span> summarize_open_answers
    answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>).join(<span class="st">', '</span>)
  <span class="kw">end</span>

  <span class="kw">def</span> summarize_scale_answers
    sprintf(<span class="st">'Average: %.02f'</span>, answers.average(<span class="st">'text'</span>))
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>There are a number of issues with the <code>summary</code> method:</p>
<ul>
<li>Adding a new question type will require modifying the method, leading to <a href="#divergent-change">divergent change</a>.</li>
<li>The logic and data for summarizing every type of question and answer is jammed into the <code>Question</code> class, resulting in a <a href="#large-class">large class</a> with <a href="#obscure-code">obscure code</a>.</li>
<li>This method isn't the only place in the application where question types are checked, meaning that new types will cause <a href="#shotgun-surgery">shotgun surgery</a>.</li>
</ul>
<p>There are several ways to refactor to use polymorphism. In this chapter, we'll demonstrate a solution that uses subclasses to replace type codes, which is one of the simplest solutions to implement. However, make sure to see the <a href="#drawbacks">Drawbacks</a> section in this chapter for alternative implementations.</p>
</section>
<section id="replace-type-code-with-subclasses" class="level2">
<h2><a href="#replace-type-code-with-subclasses">Replace Type Code with Subclasses</a></h2>
<p>Let's replace this case statement with polymorphism by introducing a subclass for each type of question.</p>
<p>Our <code>Question</code> class is a subclass of <code>ActiveRecord::Base</code>. If we want to create subclasses of <code>Question</code>, we have to tell ActiveRecord which subclass to instantiate when it fetches records from the <code>questions</code> table. The mechanism Rails uses for storing instances of different classes in the same table is called <a href="#single-table-inheritance-sti">single table inheritance</a>. Rails will take care of most of the details, but there are a few extra steps we need to take when refactoring to single table inheritance.</p>
</section>
<section id="single-table-inheritance-sti-1" class="level2">
<h2><a href="#single-table-inheritance-sti-1">Single Table Inheritance (STI)</a></h2>
<p>The first step to convert to <a href="#single-table-inheritance-sti">STI</a> is generally to create a new subclass for each type. However, the existing type codes are named &quot;Open,&quot; &quot;Scale&quot; and &quot;MultipleChoice,&quot; which won't make good class names. Names like &quot;OpenQuestion&quot; would be better, so let's start by changing the existing type codes:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summary
  <span class="kw">case</span> question_type
  <span class="kw">when</span> <span class="st">'MultipleChoiceQuestion'</span>
    summarize_multiple_choice_answers
  <span class="kw">when</span> <span class="st">'OpenQuestion'</span>
    summarize_open_answers
  <span class="kw">when</span> <span class="st">'ScaleQuestion'</span>
    summarize_scale_answers
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># db/migrate/20121128221331_add_question_suffix_to_question_type.rb</span>
<span class="kw">class</span> <span class="dt">AddQuestionSuffixToQuestionType</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Migration</span>
  <span class="kw">def</span> up
    connection.update(&lt;&lt;-<span class="kw">SQL</span><span class="ot">)</span>
<span class="ot">      UPDATE questions SET question_type = question_type || 'Question'</span>
<span class="ot">    </span><span class="kw">SQL</span>
  <span class="kw">end</span>

  <span class="kw">def</span> down
    connection.update(&lt;&lt;-<span class="kw">SQL</span><span class="ot">)</span>
<span class="ot">      UPDATE questions SET question_type = REPLACE(question_type, 'Question', '')</span>
<span class="ot">    </span><span class="kw">SQL</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>See <a href="https://github.com/thoughtbot/ruby-science/commit/b535171">commit b535171</a> for the full change.</p>
<p>The <code>Question</code> class stores its type code as <code>question_type</code>. The Rails convention is to use a column named <code>type</code>, but Rails will automatically start using STI if that column is present. That means that renaming <code>question_type</code> to <code>type</code> at this point would result in debugging two things at once: possible breaks from renaming and possible breaks from using STI. Therefore, let's start by just marking <code>question_type</code> as the inheritance column, allowing us to debug STI failures by themselves:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
set_inheritance_column  <span class="st">'question_type'</span></code></pre>
<p>Running the tests after this will reveal that Rails wants the subclasses to be defined, so let's add some placeholder classes:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_question.rb</span>
<span class="kw">class</span> <span class="dt">OpenQuestion</span> &lt; <span class="dt">Question</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/scale_question.rb</span>
<span class="kw">class</span> <span class="dt">ScaleQuestion</span> &lt; <span class="dt">Question</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/multiple_choice_question.rb</span>
<span class="kw">class</span> <span class="dt">MultipleChoiceQuestion</span> &lt; <span class="dt">Question</span>
<span class="kw">end</span></code></pre>
<p>Rails generates URLs and local variable names for partials based on class names. Our views will now be getting instances of subclasses like <code>OpenQuestion</code> rather than <code>Question</code>, so we'll need to update a few more references. For example, we'll have to change lines like:</p>
<pre class="erb"><code>&lt;%= form_for @question do |form| %&gt;</code></pre>
<p>To:</p>
<pre class="erb"><code>&lt;%= form_for @question, as: :question do |form| %&gt;</code></pre>
<p>Otherwise, it will generate <code>/open_questions</code> as a URL instead of <code>/questions</code>. See <a href="https://github.com/thoughtbot/ruby-science/commit/c18ebeb">commit c18ebeb</a> for the full change.</p>
<p>At this point, the tests are passing with STI in place, so we can rename <code>question_type</code> to <code>type</code>, following the Rails convention:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># db/migrate/20121128225425_rename_question_type_to_type.rb</span>
<span class="kw">class</span> <span class="dt">RenameQuestionTypeToType</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Migration</span>
  <span class="kw">def</span> up
    rename_column <span class="st">:questions</span>, <span class="st">:question_type</span>, <span class="st">:type</span>
  <span class="kw">end</span>

  <span class="kw">def</span> down
    rename_column <span class="st">:questions</span>, <span class="st">:type</span>, <span class="st">:question_type</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now we need to build the appropriate subclass instead of <code>Question</code>. We can use a little Ruby meta-programming to make that fairly painless:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
<span class="kw">def</span> build_question
  <span class="ot">@question</span> = type.constantize.new(question_params)
  <span class="ot">@question</span>.survey = <span class="ot">@survey</span>
<span class="kw">end</span>

<span class="kw">def</span> type
  params[<span class="st">:question</span>][<span class="st">:type</span>]
<span class="kw">end</span></code></pre>
<p>At this point, we're ready to proceed with a regular refactoring.</p>
<section id="extracting-type-specific-code" class="level3">
<h3><a href="#extracting-type-specific-code">Extracting Type-Specific Code</a></h3>
<p>The next step is to move type-specific code from <code>Question</code> into the subclass for each specific type.</p>
<p>Let's look at the <code>summary</code> method again:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summary
  <span class="kw">case</span> question_type
  <span class="kw">when</span> <span class="st">'MultipleChoice'</span>
    summarize_multiple_choice_answers
  <span class="kw">when</span> <span class="st">'Open'</span>
    summarize_open_answers
  <span class="kw">when</span> <span class="st">'Scale'</span>
    summarize_scale_answers
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>For each path of the condition, there is a sequence of steps.</p>
<p>The first step is to use <a href="#extract-method">extract method</a> to move each path to its own method. In this case, we already extracted methods called <code>summarize_multiple_choice_answers</code>, <code>summarize_open_answers</code>, and <code>summarize_scale_answers</code>, so we can proceed immediately.</p>
<p>The next step is to use <a href="#move-method">move method</a> to move the extracted method to the appropriate class. First, let's move the method <code>summarize_multiple_choice_answers</code> to <code>MultipleChoiceQuestion</code> and rename it to <code>summary</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">MultipleChoiceQuestion</span> &lt; <span class="dt">Question</span>
  <span class="kw">def</span> summary
    total = answers.count
    counts = answers.group(<span class="st">:text</span>).order(<span class="st">'COUNT(*) DESC'</span>).count
    percents = counts.map <span class="kw">do</span> |text, count|
      percent = (<span class="fl">100.0</span> * count / total).round
      <span class="st">&quot;</span><span class="ot">#{</span>percent<span class="ot">}</span><span class="st">% </span><span class="ot">#{</span>text<span class="ot">}</span><span class="st">&quot;</span>
    <span class="kw">end</span>
    percents.join(<span class="st">', '</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p><code>MultipleChoiceQuestion#summary</code> now overrides <code>Question#summary</code>, so the correct implementation will now be chosen for multiple choice questions.</p>
<p>Now that the code for multiple choice types is in place, we repeat the steps for each other path. Once every path is moved, we can remove <code>Question#summary</code> entirely.</p>
<p>In this case, we've already created all our subclasses, but you can use <a href="#extract-class">extract class</a> to create them if you're extracting each conditional path into a new class.</p>
<p>You can see the full change for this step in <a href="https://github.com/thoughtbot/ruby-science/commit/a08f801">commit a08f801</a>.</p>
<p>The <code>summary</code> method is now much better. Adding new question types is easier. The new subclass will implement <code>summary</code> and the <code>Question</code> class doesn't need to change. The summary code for each type now lives with its type, so no one class is cluttered up with the details.</p>
</section>
</section>
<section id="polymorphic-partials" class="level2">
<h2><a href="#polymorphic-partials">Polymorphic Partials</a></h2>
<p>Applications rarely check the type code in just one place. Running grep on our example application reveals several more places. Most interestingly, the views check the type before deciding how to render a question:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/_question.html.erb
<span class="kw">&lt;%</span> <span class="kw">if</span> question.type <span class="ch">==</span> <span class="st">'MultipleChoiceQuestion'</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;ol&gt;</span>
    <span class="kw">&lt;%</span> question.options.each <span class="kw">do</span> <span class="ch">|</span>option<span class="ch">|</span> <span class="kw">-%&gt;</span>
      <span class="kw">&lt;li&gt;</span>
        <span class="kw">&lt;%=</span> submission_fields.radio_button <span class="st">:text</span>, option.text, id: dom_id(option) <span class="kw">%&gt;</span>
        <span class="kw">&lt;%=</span> content_tag <span class="st">:label</span>, option.text, <span class="kw">for</span>: dom_id(option) <span class="kw">%&gt;</span>
      <span class="kw">&lt;/li&gt;</span>
    <span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;/ol&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>

<span class="kw">&lt;%</span> <span class="kw">if</span> question.type <span class="ch">==</span> <span class="st">'ScaleQuestion'</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;ol&gt;</span>
    <span class="kw">&lt;%</span> question.steps.each <span class="kw">do</span> <span class="ch">|</span>step<span class="ch">|</span> <span class="kw">-%&gt;</span>
      <span class="kw">&lt;li&gt;</span>
        <span class="kw">&lt;%=</span> submission_fields.radio_button <span class="st">:text</span>, step <span class="kw">%&gt;</span>
        <span class="kw">&lt;%=</span> submission_fields.label <span class="st">&quot;text_</span><span class="ot">#{</span>step<span class="ot">}</span><span class="st">&quot;</span>, label: step <span class="kw">%&gt;</span>
      <span class="kw">&lt;/li&gt;</span>
    <span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;/ol&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>

<span class="kw">&lt;%</span> <span class="kw">if</span> question.type <span class="ch">==</span> <span class="st">'OpenQuestion'</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> submission_fields.text_field <span class="st">:text</span> <span class="kw">%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
<p>In the previous example, we moved type-specific code into <code>Question</code> subclasses. However, moving view code would violate MVC (introducing <a href="#divergent-change">divergent change</a> into the subclasses) and, more importantly, it would be ugly and hard to understand.</p>
<p>Rails has the ability to render views polymorphically. A line like this—</p>
<pre class="erb"><code>&lt;%= render @question %&gt;</code></pre>
<p>—will ask <code>@question</code> which view should be rendered by calling <code>to_partial_path</code>. As subclasses of <code>ActiveRecord::Base</code>, our <code>Question</code> subclasses will return a path based on their class name. This means that the above line will attempt to render <code>open_questions/_open_question.html.erb</code> for an open question, and so on.</p>
<p>We can use this to move the type-specific view code into a view for each type:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/open_questions/_open_question.html.erb
<span class="kw">&lt;%=</span> submission_fields.text_field <span class="st">:text</span> <span class="kw">%&gt;</span></code></pre>
<p>You can see the full change in <a href="https://github.com/thoughtbot/ruby-science/commit/8243493">commit 8243493</a>.</p>
<section id="multiple-polymorphic-views" class="level3">
<h3><a href="#multiple-polymorphic-views">Multiple Polymorphic Views</a></h3>
<p>Our application also has different fields on the question form depending on the question type. Currently, that also performs type-checking:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/new.html.erb
<span class="kw">&lt;%</span> <span class="kw">if</span> <span class="ot">@question</span>.type <span class="ch">==</span> <span class="st">'MultipleChoiceQuestion'</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> form.fields_for(<span class="st">:options</span>, <span class="ot">@question</span>.options_for_form) <span class="kw">do</span> <span class="ch">|</span>option_fields<span class="ch">|</span> <span class="kw">-%&gt;</span>
    <span class="kw">&lt;%=</span> option_fields.input <span class="st">:text</span>, label: <span class="st">'Option'</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span>

<span class="kw">&lt;%</span> <span class="kw">if</span> <span class="ot">@question</span>.type <span class="ch">==</span> <span class="st">'ScaleQuestion'</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> form.input <span class="st">:minimum</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> form.input <span class="st">:maximum</span> <span class="kw">%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
<p>We already used views like <code>open_questions/_open_question.html.erb</code> for showing a question, so we can't just put the edit code there. Rails doesn't support prefixes or suffixes in <code>render</code>, but we can do it ourselves easily enough:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/new.html.erb
<span class="kw">&lt;%=</span> render <span class="st">&quot;</span><span class="ot">#{@question</span>.to_partial_path<span class="ot">}</span><span class="st">_form&quot;</span>, question: <span class="ot">@question</span>, form: form <span class="kw">%&gt;</span></code></pre>
<p>This will render <code>app/views/open_questions/_open_question_form.html.erb</code> for an open question, and so on.</p>
</section>
<section id="drawbacks" class="level3">
<h3><a href="#drawbacks">Drawbacks</a></h3>
<p>It's worth noting that, although this refactoring improved this particular example, replacing conditionals with polymorphism is not without its drawbacks.</p>
<p>Using polymorphism like this makes it easier to add new types, because adding a new type means that you just need to add a new class and implement the required methods. Adding a new type won't require changes to any existing classes, and it's easy to understand what the types are because each type is encapsulated within a class.</p>
<p>However, this change makes it harder to add new behaviors. Adding a new behavior will mean finding every type and adding a new method. Understanding the behavior becomes more difficult because the implementations are spread out among the types. Object-oriented languages lean toward polymorphic implementations, but if you find yourself adding behaviors much more often than adding types, you should look into using observers or visitors instead.</p>
<p>Using subclasses forces you to use inheritance instead of composition for reuse and separation of concerns. See <a href="#composition-over-inheritance">composition over inheritance</a> for more on this subject.</p>
<p>Also, using STI has specific disadvantages. See the <a href="#single-table-inheritance-sti">chapter on STI</a> for details.</p>
</section>
<section id="next-steps" class="level3">
<h3><a href="#next-steps">Next Steps</a></h3>
<ul>
<li>Check the new classes for <a href="#duplicated-code">duplicated code</a> that can be pulled up into the superclass.</li>
<li>Pay attention to changes that affect the new types, watching out for <a href="#shotgun-surgery">shotgun surgery</a> that can result from splitting up classes.</li>
</ul>
</section>
</section>
</section>
<section id="replace-conditional-with-null-object" class="level1">
<h1><a href="#replace-conditional-with-null-object">Replace Conditional with Null Object</a></h1>
<p>Every Ruby developer is familiar with <code>nil</code>, and Ruby on Rails comes with a full complement of tools to handle it: <code>nil?</code>, <code>present?</code>, <code>try</code> and more. However, it's easy to let these tools hide duplication and leak concerns. If you find yourself checking for <code>nil</code> all over your codebase, try replacing some of the <code>nil</code> values with Null Objects.</p>
<section id="uses-1" class="level3">
<h3><a href="#uses-1">Uses</a></h3>
<ul>
<li>Removes <a href="#shotgun-surgery">shotgun surgery</a> when an existing method begins returning <code>nil</code>.</li>
<li>Removes <a href="#duplicated-code">duplicated code</a> related to checking for <code>nil</code>.</li>
<li>Removes clutter, improving readability of code that consumes <code>nil</code>.</li>
<li>Makes logic related to presence and absence easier to reuse, making it easier to <a href="#dry">avoid duplication</a>.</li>
<li>Replaces conditional logic with simple commands, following <a href="#tell-dont-ask">tell, don't ask</a>.</li>
</ul>
</section>
<section id="example-14" class="level3">
<h3><a href="#example-14">Example</a></h3>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> most_recent_answer_text
  answers.most_recent.try(<span class="st">:text</span>) || <span class="dt">Answer</span>::<span class="dt">MISSING_TEXT</span>
<span class="kw">end</span></code></pre>
<p>The <code>most_recent_answer_text</code> method asks its <code>answers</code> association for <code>most_recent</code> answer. It only wants the <code>text</code> from that answer, but it must first check to make sure that an answer actually exists to get <code>text</code> from. It needs to perform this check because <code>most_recent</code> might return <code>nil</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/answer.rb</span>
<span class="kw">def</span> <span class="dv">self</span>.most_recent
  order(<span class="st">:created_at</span>).last
<span class="kw">end</span></code></pre>
<p>This call clutters up the method, and returning <code>nil</code> is contagious: Any method that calls <code>most_recent</code> must also check for <code>nil</code>. The concept of a missing answer is likely to come up more than once, as in this example:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/user.rb</span>
<span class="kw">def</span> answer_text_for(question)
  question.answers.for_user(<span class="dv">self</span>).try(<span class="st">:text</span>) || <span class="dt">Answer</span>::<span class="dt">MISSING_TEXT</span>
<span class="kw">end</span></code></pre>
<p>Again, <code>for_user</code> might return <code>nil</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/answer.rb</span>
<span class="kw">def</span> <span class="dv">self</span>.for_user(user)
  joins(<span class="st">:completion</span>).where(completions: { user_id: user.id }).last
<span class="kw">end</span></code></pre>
<p>The <code>User#answer_text_for</code> method duplicates the check for a missing answer—and worse, it's repeating the logic of what happens when you need text without an answer.</p>
<p>We can remove these checks entirely from <code>Question</code> and <code>User</code> by introducing a null object:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> most_recent_answer_text
  answers.most_recent.text
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/user.rb</span>
<span class="kw">def</span> answer_text_for(question)
  question.answers.for_user(<span class="dv">self</span>).text
<span class="kw">end</span></code></pre>
<p>We're now just assuming that <code>Answer</code> class methods will return something answer-like; specifically, we expect an object that returns useful <code>text</code>. We can refactor <code>Answer</code> to handle the <code>nil</code> check:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/answer.rb</span>
<span class="kw">class</span> <span class="dt">Answer</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">ActiveModel</span>::<span class="dt">ForbiddenAttributesProtection</span>

  belongs_to <span class="st">:completion</span>
  belongs_to <span class="st">:question</span>

  validates <span class="st">:text</span>, presence: <span class="dv">true</span>

  <span class="kw">def</span> <span class="dv">self</span>.for_user(user)
    joins(<span class="st">:completion</span>).where(completions: { user_id: user.id }).last ||
      <span class="dt">NullAnswer</span>.new
  <span class="kw">end</span>

  <span class="kw">def</span> <span class="dv">self</span>.most_recent
    order(<span class="st">:created_at</span>).last || <span class="dt">NullAnswer</span>.new
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Note that <code>for_user</code> and <code>most_recent</code> return a <code>NullAnswer</code> if no answer can be found, so these methods will never return <code>nil</code>. The implementation for <code>NullAnswer</code> is simple:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/null_answer.rb</span>
<span class="kw">class</span> <span class="dt">NullAnswer</span>
  <span class="kw">def</span> text
    <span class="st">'No response'</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>We can take things just a little further and remove a bit of duplication with a quick <a href="#extract-method">extract method</a>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/answer.rb</span>
<span class="kw">class</span> <span class="dt">Answer</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">ActiveModel</span>::<span class="dt">ForbiddenAttributesProtection</span>

  belongs_to <span class="st">:completion</span>
  belongs_to <span class="st">:question</span>

  validates <span class="st">:text</span>, presence: <span class="dv">true</span>

  <span class="kw">def</span> <span class="dv">self</span>.for_user(user)
    joins(<span class="st">:completion</span>).where(completions: { user_id: user.id }).last_or_null
  <span class="kw">end</span>

  <span class="kw">def</span> <span class="dv">self</span>.most_recent
    order(<span class="st">:created_at</span>).last_or_null
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> <span class="dv">self</span>.last_or_null
    last || <span class="dt">NullAnswer</span>.new
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now we can easily create <code>Answer</code> class methods that return a usable answer, no matter what.</p>
</section>
<section id="drawbacks-1" class="level3">
<h3><a href="#drawbacks-1">Drawbacks</a></h3>
<p>Introducing a null object can remove duplication and clutter. But it can also cause pain and confusion:</p>
<ul>
<li>As a developer reading a method like <code>Question#most_recent_answer_text</code>, you may be confused to find that <code>most_recent_answer</code> returned an instance of <code>NullAnswer</code> and not <code>Answer</code>.</li>
<li>It's possible some methods will need to distinguish between <code>NullAnswer</code>s and real <code>Answer</code>s. This is common in views, when special markup is required to denote missing values. In this case, you'll need to add explicit <code>present?</code> checks and define <code>present?</code> to return <code>false</code> on your null object.</li>
<li><code>NullAnswer</code> may eventually need to reimplement large part of the <code>Answer</code> API, leading to potential <a href="#duplicated-code">duplicated code</a> and <a href="#shotgun-surgery">shotgun surgery</a>, which is largely what we hoped to solve in the first place.</li>
</ul>
<p>Don't introduce a null object until you find yourself swatting enough <code>nil</code> values to grow annoyed. And make sure the removal of the <code>nil</code>-handling logic outweighs the drawbacks above.</p>
</section>
<section id="next-steps-1" class="level3">
<h3><a href="#next-steps-1">Next Steps</a></h3>
<ul>
<li>Look for other <code>nil</code> checks of the return values of refactored methods.</li>
<li>Make sure your null object class implements the required methods from the original class.</li>
<li>Make sure no <a href="#duplicated-code">duplicated code</a> exists between the null object class and the original.</li>
</ul>
<p></p>
</section>
<section id="truthiness-try-and-other-tricks" class="level2">
<h2><a href="#truthiness-try-and-other-tricks">Truthiness, <code>try</code> and Other Tricks</a></h2>
<p>All checks for <code>nil</code> are a condition, but Ruby provides many ways to check for <code>nil</code> without using an explicit <code>if</code>. Watch out for <code>nil</code> conditional checks disguised behind other syntax. The following are all roughly equivalent:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># Explicit if with nil?</span>
<span class="kw">if</span> user.nil?
  <span class="dv">nil</span>
<span class="kw">else</span>
  user.name
<span class="kw">end</span>

<span class="co"># Implicit nil check through truthy conditional</span>
<span class="kw">if</span> user
  user.name
<span class="kw">end</span>

<span class="co"># Relies on nil being falsey</span>
user &amp;&amp; user.name

<span class="co"># Call to try</span>
user.try(<span class="st">:name</span>)</code></pre>
</section>
</section>
<section id="extract-method" class="level1">
<h1><a href="#extract-method">Extract Method</a></h1>
<p>The simplest refactoring to perform is extract method. To extract a method:</p>
<ul>
<li>Pick a name for the new method.</li>
<li>Move extracted code into the new method.</li>
<li>Call the new method from the point of extraction.</li>
</ul>
<section id="uses-2" class="level3">
<h3><a href="#uses-2">Uses</a></h3>
<ul>
<li>Removes <a href="#long-method">long methods</a>.</li>
<li>Sets the stage for moving behavior via <a href="#move-method">move method</a>.</li>
<li>Resolves obscurity by introducing intention-revealing names.</li>
<li>Allows removal of <a href="#duplicated-code">duplicated code</a> by moving the common code into the extracted method.</li>
<li>Reveals complexity, making it easier to follow the <a href="#single-responsibility-principle">single responsibility principle</a>.</li>
<li>Makes behavior easier to reuse, which makes it easier to <a href="#dry">avoid duplication</a>.</li>
</ul>
<p></p>
</section>
<section id="example-15" class="level3">
<h3><a href="#example-15">Example</a></h3>
<p>Let's take a look at an example of <a href="#long-method">long method</a> and improve it by extracting smaller methods:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> create
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="ot">@submittable_type</span> = params[<span class="st">:submittable_type_id</span>]
  question_params = params.
    require(<span class="st">:question</span>).
    permit(<span class="st">:submittable_type</span>, <span class="st">:title</span>, <span class="st">:options_attributes</span>, <span class="st">:minimum</span>, <span class="st">:maximum</span>)
  <span class="ot">@question</span> = <span class="ot">@survey</span>.questions.new(question_params)
  <span class="ot">@question</span>.submittable_type = <span class="ot">@submittable_type</span>

  <span class="kw">if</span> <span class="ot">@question</span>.save
    redirect_to <span class="ot">@survey</span>
  <span class="kw">else</span>
    render <span class="st">:new</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This method performs a number of tasks:</p>
<ul>
<li>It finds the survey that the question should belong to.</li>
<li>It figures out what type of question we're creating (the <code>submittable_type</code>).</li>
<li>It builds parameters for the new question by applying a white list to the HTTP parameters.</li>
<li>It builds a question from the given survey, parameters and submittable type.</li>
<li>It attempts to save the question.</li>
<li>It redirects back to the survey for a valid question.</li>
<li>It re-renders the form for an invalid question.</li>
</ul>
<p>Any of these tasks can be extracted to a method. Let's start by extracting the task of building the question.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> create
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="ot">@submittable_type</span> = params[<span class="st">:submittable_type_id</span>]
  build_question

  <span class="kw">if</span> <span class="ot">@question</span>.save
    redirect_to <span class="ot">@survey</span>
  <span class="kw">else</span>
    render <span class="st">:new</span>
  <span class="kw">end</span>
<span class="kw">end</span>

<span class="kw">private</span>

<span class="kw">def</span> build_question
  question_params = params.
    require(<span class="st">:question</span>).
    permit(<span class="st">:submittable_type</span>, <span class="st">:title</span>, <span class="st">:options_attributes</span>, <span class="st">:minimum</span>, <span class="st">:maximum</span>)
  <span class="ot">@question</span> = <span class="ot">@survey</span>.questions.new(question_params)
  <span class="ot">@question</span>.submittable_type = <span class="ot">@submittable_type</span>
<span class="kw">end</span></code></pre>
<p>The <code>create</code> method is already much more readable. The new <code>build_question</code> method is noisy, though, with the wrong details at the beginning. The task of pulling out question parameters is clouding up the task of building the question. Let's extract another method.</p>
<p></p>
</section>
<section id="replace-temp-with-query" class="level2">
<h2><a href="#replace-temp-with-query">Replace Temp with Query</a></h2>
<p>One simple way to extract methods is by replacing local variables. Let's pull <code>question_params</code> into its own method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> build_question
  <span class="ot">@question</span> = <span class="ot">@survey</span>.questions.new(question_params)
  <span class="ot">@question</span>.submittable_type = <span class="ot">@submittable_type</span>
<span class="kw">end</span>

<span class="kw">def</span> question_params
  params.
    require(<span class="st">:question</span>).
    permit(<span class="st">:submittable_type</span>, <span class="st">:title</span>, <span class="st">:options_attributes</span>, <span class="st">:minimum</span>, <span class="st">:maximum</span>)
<span class="kw">end</span></code></pre>
<section id="other-examples" class="level3">
<h3><a href="#other-examples">Other Examples</a></h3>
<p>For more examples of <a href="#extract-method">extract method</a>, take a look at these chapters:</p>
<ul>
<li><a href="#extract-class">Extract class</a>: <a href="https://github.com/thoughtbot/ruby-science/commit/b434954d">b434954d</a>, <a href="https://github.com/thoughtbot/ruby-science/commit/000babe1">000babe1</a></li>
<li><a href="#extract-decorator">Extract decorator</a>: <a href="https://github.com/thoughtbot/ruby-science/commit/15f5b96e">15f5b96e</a></li>
<li><a href="#introduce-explaining-variable">Introduce explaining variable</a> (inline)</li>
<li><a href="#move-method">Move method</a>: <a href="https://github.com/thoughtbot/ruby-science/commit/d5b4871">d5b4871</a></li>
<li><a href="#replace-conditional-with-null-object">Replace conditional with null object</a>: <a href="https://github.com/thoughtbot/ruby-science/commit/1e35c68">1e35c68</a></li>
</ul>
</section>
<section id="next-steps-2" class="level3">
<h3><a href="#next-steps-2">Next Steps</a></h3>
<ul>
<li>Check the original method and the extracted method to make sure neither is a <a href="#long-method">long method</a>.</li>
<li>Check the original method and the extracted method to make sure that they both relate to the same core concern. If the methods aren't highly related, the class will suffer from <a href="#divergent-change">divergent change</a>.</li>
<li>Check newly extracted methods for <a href="#feature-envy">feature envy</a>. If you find some, you may wish to employ <a href="#move-method">move method</a> to provide the new method with a better home.</li>
<li>Check the affected class to make sure it's not a <a href="#large-class">large class</a>. Extracting methods reveals complexity, making it clearer when a class is doing too much.</li>
</ul>
</section>
</section>
</section>
<section id="rename-method" class="level1">
<h1><a href="#rename-method">Rename Method</a></h1>
<p>Renaming a method allows developers to improve the language of the domain as their understanding naturally evolves during development.</p>
<p>The process is straightforward if there aren't too many references:</p>
<ul>
<li>Choose a new name for the method. This is the hard part!</li>
<li>Change the method definition to the new name.</li>
<li>Find and replace all references to the old name.</li>
</ul>
<p>If there are a large number of references to the method you want to rename, you can rename the callers one at a time while keeping everything in working order. The process is mostly the same:</p>
<ul>
<li>Choose a new name for the method.</li>
<li>Give the method its new name.</li>
<li>Add an alias to keep the old name working.</li>
<li>Find and replace all references to the old name.</li>
<li>Remove the alias.</li>
</ul>
<section id="uses-3" class="level3">
<h3><a href="#uses-3">Uses</a></h3>
<ul>
<li>Eliminate <a href="#uncommunicative-name">uncommunicative names</a>.</li>
<li>Change method names to conform to common interfaces.</li>
</ul>
</section>
<section id="example-16" class="level3">
<h3><a href="#example-16">Example</a></h3>
<p>In our example application, we generate summaries from answers to surveys. We allow more than one type of summary, so strategies are employed to handle the variations. There are a number of methods and dependencies that make this work.</p>
<p><code>SummariesController#show</code> depends on <code>Survey#summarize</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="ot">@summaries</span> = <span class="ot">@survey</span>.summarize(summarizer)</code></pre>
<p><code>Survey#summarize</code> depends on <code>Question#summarize</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summarize(summarizer)
  questions.map <span class="kw">do</span> |question|
    question.summarize(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p><code>Question#summarize</code> depends on <code>summarize</code> from its <code>summarizer</code> argument (a strategy):</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summarize(summarizer)
  value = summarizer.summarize(<span class="dv">self</span>)
  <span class="dt">Summary</span>.new(title, value)
<span class="kw">end</span></code></pre>
<p>There are several summarizer classes, each of which respond to <code>summarize</code>.</p>
<p>This is confusing, largely because the word <code>summarize</code> is used to mean several different things:</p>
<ul>
<li><code>Survey#summarize</code> accepts a summarizer and returns an array of <code>Summary</code> instances.</li>
<li><code>Question#summarize</code> accepts a summarizer and returns a single <code>Summary</code> instance.</li>
<li><code>summarize</code> on summarizer strategies accepts a <code>Question</code> and returns a <code>String</code>.</li>
</ul>
<p>Let's rename these methods so that each name is used uniquely and consistently in terms of what it accepts, what it returns and what it does.</p>
<p>First, we'll rename <code>Survey#summarize</code> to reflect the fact that it returns a collection.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer)</code></pre>
<p>Then we'll update the only reference to the old method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="ot">@summaries</span> = <span class="ot">@survey</span>.summaries_using(summarizer)</code></pre>
<p>Next, we'll rename <code>Question#summarize</code> to be consistent with the naming introduced in <code>Survey</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summary_using(summarizer)</code></pre>
<p>Finally, we'll update the only reference in <code>Survey#summaries_using</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
question.summary_using(summarizer)</code></pre>
<p>We now have consistent and clearer naming:</p>
<ul>
<li><code>summarize</code> means taking a question and returning a string value representing its answers.</li>
<li><code>summary_using</code> means taking a summarizer and using it to build a <code>Summary</code>.</li>
<li><code>summaries_using</code> means taking a set of questions and building a <code>Summary</code> for each one.</li>
</ul>
</section>
<section id="next-steps-3" class="level3">
<h3><a href="#next-steps-3">Next Steps</a></h3>
<ul>
<li>Check for explanatory comments that are no longer necessary now that the code is clearer.</li>
<li>If the new name for a method is long, see if you can <a href="#extract-method">extract methods</a> from it to make it smaller.</li>
</ul>
</section>
</section>
<section id="extract-class" class="level1">
<h1><a href="#extract-class">Extract Class</a></h1>
<p>Dividing responsibilities into classes is the primary way to manage complexity in object-oriented software. <a href="#extract-class">Extract class</a> is the primary mechanism for introducing new classes. This refactoring takes one class and splits it into two by moving one or more methods and instance variables into a new class.</p>
<p>The process for extracting a class looks like this:</p>
<ol type="1">
<li>Create a new, empty class.</li>
<li>Instantiate the new class from the original class.</li>
<li><a href="#move-method">Move a method</a> from the original class to the new class.</li>
<li>Repeat step 3 until you're happy with the original class.</li>
</ol>
<section id="uses-4" class="level3">
<h3><a href="#uses-4">Uses</a></h3>
<ul>
<li>Removes <a href="#large-class">large class</a> by splitting up the class.</li>
<li>Eliminates <a href="#divergent-change">divergent change</a> by moving one reason to change into a new class.</li>
<li>Provides a cohesive set of functionality with a meaningful name, making it easier to understand and talk about.</li>
<li>Fully encapsulates a concern within a single class, following the <a href="#single-responsibility-principle">single responsibility principle</a> and making it easier to change and reuse that functionality.</li>
<li>Allows concerns to be injected, following the <a href="#dependency-inversion-principle">dependency inversion principle</a>.</li>
<li>Makes behavior easier to reuse, which makes it easier to <a href="#dry">avoid duplication</a>.</li>
</ul>
</section>
<section id="example-17" class="level3">
<h3><a href="#example-17">Example</a></h3>
<p>The <code>InvitationsController</code> is a <a href="#large-class">large class</a> hidden behind a <a href="#long-method">long method</a>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">class</span> <span class="dt">InvitationsController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="dt">EMAIL_REGEX</span> = <span class="ot">/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/</span>

  <span class="kw">def</span> new
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="kw">end</span>

  <span class="kw">def</span> create
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])

    <span class="ot">@recipients</span> = params[<span class="st">:invitation</span>][<span class="st">:recipients</span>]
    recipient_list = <span class="ot">@recipients</span>.gsub(<span class="ot">/\s+/</span>, <span class="st">''</span>).split(<span class="ot">/[\n,;]+/</span>)

    <span class="ot">@invalid_recipients</span> = recipient_list.map <span class="kw">do</span> |item|
      <span class="kw">unless</span> item.match(<span class="dt">EMAIL_REGEX</span>)
        item
      <span class="kw">end</span>
    <span class="kw">end</span>.compact

    <span class="ot">@message</span> = params[<span class="st">:invitation</span>][<span class="st">:message</span>]

    <span class="kw">if</span> <span class="ot">@invalid_recipients</span>.empty? &amp;&amp; <span class="ot">@message</span>.present?
      recipient_list.each <span class="kw">do</span> |email|
        invitation = <span class="dt">Invitation</span>.create(
          survey: <span class="ot">@survey</span>,
          sender: current_user,
          recipient_email: email,
          status: <span class="st">'pending'</span>
        )
        <span class="dt">Mailer</span>.invitation_notification(invitation, <span class="ot">@message</span>)
      <span class="kw">end</span>

      redirect_to survey_path(<span class="ot">@survey</span>), notice: <span class="st">'Invitation successfully sent'</span>
    <span class="kw">else</span>
      render <span class="st">'new'</span>
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Although it contains only two methods, there's a lot going on under the hood. It parses and validates emails, manages several pieces of state which the view needs to know about, handles control flow for the user and creates and delivers invitations.</p>
<p><a href="https://github.com/thoughtbot/ruby-science/commit/65f1b428">A liberal application</a> of <a href="#extract-method">extract method</a> to break up this <a href="#long-method">long method</a> will reveal the complexity:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">class</span> <span class="dt">InvitationsController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="dt">EMAIL_REGEX</span> = <span class="ot">/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/</span>

  <span class="kw">def</span> new
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="kw">end</span>

  <span class="kw">def</span> create
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
    <span class="kw">if</span> valid_recipients? &amp;&amp; valid_message?
      recipient_list.each <span class="kw">do</span> |email|
        invitation = <span class="dt">Invitation</span>.create(
          survey: <span class="ot">@survey</span>,
          sender: current_user,
          recipient_email: email,
          status: <span class="st">'pending'</span>
        )
        <span class="dt">Mailer</span>.invitation_notification(invitation, message)
      <span class="kw">end</span>
      redirect_to survey_path(<span class="ot">@survey</span>), notice: <span class="st">'Invitation successfully sent'</span>
    <span class="kw">else</span>
      <span class="ot">@recipients</span> = recipients
      <span class="ot">@message</span> = message
      render <span class="st">'new'</span>
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> valid_recipients?
    invalid_recipients.empty?
  <span class="kw">end</span>

  <span class="kw">def</span> valid_message?
    message.present?
  <span class="kw">end</span>

  <span class="kw">def</span> invalid_recipients
    <span class="ot">@invalid_recipients</span> ||= recipient_list.map <span class="kw">do</span> |item|
      <span class="kw">unless</span> item.match(<span class="dt">EMAIL_REGEX</span>)
        item
      <span class="kw">end</span>
    <span class="kw">end</span>.compact
  <span class="kw">end</span>

  <span class="kw">def</span> recipient_list
    <span class="ot">@recipient_list</span> ||= recipients.gsub(<span class="ot">/\s+/</span>, <span class="st">''</span>).split(<span class="ot">/[\n,;]+/</span>)
  <span class="kw">end</span>

  <span class="kw">def</span> recipients
    params[<span class="st">:invitation</span>][<span class="st">:recipients</span>]
  <span class="kw">end</span>

  <span class="kw">def</span> message
    params[<span class="st">:invitation</span>][<span class="st">:message</span>]
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Let's extract all of the non-controller logic into a new class. We'll start by defining and instantiating a new, empty class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="ot">@survey_inviter</span> = <span class="dt">SurveyInviter</span>.new</code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">class</span> <span class="dt">SurveyInviter</span>
<span class="kw">end</span></code></pre>
<p>At this point, we've <a href="https://github.com/thoughtbot/ruby-science/commit/cce33485">created a staging area</a> for using <a href="#move-method">move method</a> to transfer complexity from one class to the other.</p>
<p>Next, we'll move one method from the controller to our new class. It's best to move methods which depend on few private methods or instance variables from the original class, so we'll start with a method which only uses one private method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> recipient_list
  <span class="ot">@recipient_list</span> ||= <span class="ot">@recipients</span>.gsub(<span class="ot">/\s+/</span>, <span class="st">''</span>).split(<span class="ot">/[\n,;]+/</span>)
<span class="kw">end</span></code></pre>
<p>We need the recipients for this method, so we'll accept it in the <code>initialize</code> method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> initialize(recipients)
  <span class="ot">@recipients</span> = recipients
<span class="kw">end</span></code></pre>
<p>And pass it from our controller:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="ot">@survey_inviter</span> = <span class="dt">SurveyInviter</span>.new(recipients)</code></pre>
<p>The original controller method can delegate to the extracted method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">def</span> recipient_list
  <span class="ot">@survey_inviter</span>.recipient_list
<span class="kw">end</span></code></pre>
<p>We've <a href="https://github.com/thoughtbot/ruby-science/commit/ac014750">moved a little complexity out of our controller</a> and we now have a repeatable process for doing so: We can continue to move methods out until we feel good about what's left in the controller.</p>
<p>Next, let's move out <code>invalid_recipients</code> from the controller, since it depends on <code>recipient_list</code>, which we've already moved:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> invalid_recipients
  <span class="ot">@invalid_recipients</span> ||= recipient_list.map <span class="kw">do</span> |item|
    <span class="kw">unless</span> item.match(<span class="dt">EMAIL_REGEX</span>)
      item
    <span class="kw">end</span>
  <span class="kw">end</span>.compact
<span class="kw">end</span></code></pre>
<p>Again, the original controller method can delegate:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">def</span> invalid_recipients
  <span class="ot">@survey_inviter</span>.invalid_recipients
<span class="kw">end</span></code></pre>
<p>This method references a constant from the controller. This was the only place where the constant was used, so we can move it to our new class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="dt">EMAIL_REGEX</span> = <span class="ot">/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/</span></code></pre>
<p>We can remove an instance variable in the controller by invoking this method directly in the view:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/invitations/new.html.erb
<span class="kw">&lt;%</span> <span class="kw">if</span> <span class="ot">@survey_inviter</span>.invalid_recipients <span class="kw">%&gt;</span>
  <span class="kw">&lt;div</span><span class="ot"> class=</span><span class="st">&quot;error&quot;</span><span class="kw">&gt;</span>
    Invalid email addresses: 
    <span class="kw">&lt;%=</span> <span class="ot">@survey_inviter</span>.invalid_recipients.join(<span class="st">', '</span>) <span class="kw">%&gt;</span>
  <span class="kw">&lt;/div&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">%&gt;</span></code></pre>
<p>Now that parsing email lists is <a href="https://github.com/thoughtbot/ruby-science/commit/0fefb969">moved out of our controller</a>, let's extract and delegate the only method in the controller that depends on <code>invalid_recipients</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> valid_recipients?
  invalid_recipients.empty?
<span class="kw">end</span></code></pre>
<p>Now we can remove <code>invalid_recipients</code> from the controller entirely.</p>
<p>The <code>valid_recipients?</code> method is only used in the compound validation condition:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">if</span> valid_recipients? &amp;&amp; valid_message?</code></pre>
<p>If we extract <code>valid_message?</code> as well, we can fully encapsulate validation within <code>SurveyInviter</code>.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> valid_message?
  <span class="ot">@message</span>.present?
<span class="kw">end</span></code></pre>
<p>We need <code>message</code> for this method, so we'll add that to <code>initialize</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> initialize(message, recipients)
  <span class="ot">@message</span> = message
  <span class="ot">@recipients</span> = recipients
<span class="kw">end</span></code></pre>
<p>And pass it in:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="ot">@survey_inviter</span> = <span class="dt">SurveyInviter</span>.new(message, recipients)</code></pre>
<p>We can now extract a method to encapsulate this compound condition:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> valid?
  valid_message? &amp;&amp; valid_recipients?
<span class="kw">end</span></code></pre>
<p>And use that new method in our controller:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">if</span> <span class="ot">@survey_inviter</span>.valid?</code></pre>
<p>Now these methods can be private, trimming down the public interface for <code>SurveyInviter</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">private</span>

<span class="kw">def</span> valid_message?
  <span class="ot">@message</span>.present?
<span class="kw">end</span>

<span class="kw">def</span> valid_recipients?
  invalid_recipients.empty?
<span class="kw">end</span></code></pre>
<p>We've <a href="https://github.com/thoughtbot/ruby-science/commit/b434954d">pulled out most of the private methods</a>, so the remaining complexity results largely from saving and delivering the invitations.</p>
<p>Let's extract and move a <code>deliver</code> method for that:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> deliver
  recipient_list.each <span class="kw">do</span> |email|
    invitation = <span class="dt">Invitation</span>.create(
      survey: <span class="ot">@survey</span>,
      sender: <span class="ot">@sender</span>,
      recipient_email: email,
      status: <span class="st">'pending'</span>
    )
    <span class="dt">Mailer</span>.invitation_notification(invitation, <span class="ot">@message</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>We need the sender (the currently signed-in user) as well as the survey from the controller to do this. This pushes our initialize method up to four parameters, so let's switch to a hash:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> initialize(attributes = {})
  <span class="ot">@survey</span> = attributes[<span class="st">:survey</span>]
  <span class="ot">@message</span> = attributes[<span class="st">:message</span>] || <span class="st">''</span>
  <span class="ot">@recipients</span> = attributes[<span class="st">:recipients</span>] || <span class="st">''</span>
  <span class="ot">@sender</span> = attributes[<span class="st">:sender</span>]
<span class="kw">end</span></code></pre>
<p>And extract a method in our controller to build it:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">def</span> survey_inviter_attributes
  params[<span class="st">:invitation</span>].merge(survey: <span class="ot">@survey</span>, sender: current_user)
<span class="kw">end</span></code></pre>
<p>Now we can invoke this method in our controller:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">if</span> <span class="ot">@survey_inviter</span>.valid?
  <span class="ot">@survey_inviter</span>.deliver
  redirect_to survey_path(<span class="ot">@survey</span>), notice: <span class="st">'Invitation successfully sent'</span>
<span class="kw">else</span>
  <span class="ot">@recipients</span> = recipients
  <span class="ot">@message</span> = message
  render <span class="st">'new'</span>
<span class="kw">end</span></code></pre>
<p>The <code>recipient_list</code> method is now only used internally in <code>SurveyInviter</code>, so let's make it private.</p>
<p>We've <a href="https://github.com/thoughtbot/ruby-science/commit/000babe1">moved most of the behavior out of the controller</a>, but we're still assigning a number of instance variables for the view, which have corresponding private methods in the controller. These values are also available on <code>SurveyInviter</code>, which is already assigned to the view, so let's expose those using <code>attr_reader</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="ot">attr_reader</span> <span class="st">:message</span>, <span class="st">:recipients</span>, <span class="st">:survey</span></code></pre>
<p>And use them directly from the view:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/invitations/new.html.erb
<span class="kw">&lt;%=</span> simple_form_for(
  <span class="st">:invitation</span>,
  url: survey_invitations_path(<span class="ot">@survey_inviter</span>.survey)
) <span class="kw">do</span> <span class="ch">|</span>f<span class="ch">|</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> f.input(
    <span class="st">:message</span>,
    as: <span class="st">:text</span>,
    input_html: <span class="ch">{</span> value: <span class="ot">@survey_inviter</span>.message <span class="ch">}</span>
  ) <span class="kw">%&gt;</span>
  <span class="kw">&lt;%</span> <span class="kw">if</span> <span class="ot">@invlid_message</span> <span class="kw">%&gt;</span>
    <span class="kw">&lt;div</span><span class="ot"> class=</span><span class="st">&quot;error&quot;</span><span class="kw">&gt;</span>Please provide a message<span class="kw">&lt;/div&gt;</span>
  <span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> f.input(
    <span class="st">:recipients</span>,
    as: <span class="st">:text</span>,
    input_html: <span class="ch">{</span> value: <span class="ot">@survey_inviter</span>.recipients <span class="ch">}</span>
  ) <span class="kw">%&gt;</span></code></pre>
<p>Only the <code>SurveyInviter</code> is used in the controller now, so we can <a href="https://github.com/thoughtbot/ruby-science/commit/a0505921">remove the remaining instance variables and private methods</a>.</p>
<p>Our controller is now much simpler:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">class</span> <span class="dt">InvitationsController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="kw">def</span> new
    <span class="ot">@survey_inviter</span> = <span class="dt">SurveyInviter</span>.new(survey: survey)
  <span class="kw">end</span>

  <span class="kw">def</span> create
    <span class="ot">@survey_inviter</span> = <span class="dt">SurveyInviter</span>.new(survey_inviter_attributes)
    <span class="kw">if</span> <span class="ot">@survey_inviter</span>.valid?
      <span class="ot">@survey_inviter</span>.deliver
      redirect_to survey_path(survey), notice: <span class="st">'Invitation successfully sent'</span>
    <span class="kw">else</span>
      render <span class="st">'new'</span>
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> survey_inviter_attributes
    params[<span class="st">:invitation</span>].merge(survey: survey, sender: current_user)
  <span class="kw">end</span>

  <span class="kw">def</span> survey
    <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>It only assigns one instance variable, it doesn't have too many methods and all of its methods are fairly small.</p>
<p></p>
<p>The newly extracted <code>SurveyInviter</code> class absorbed much of the complexity, but still isn't as bad as the original controller:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">class</span> <span class="dt">SurveyInviter</span>
  <span class="dt">EMAIL_REGEX</span> = <span class="ot">/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/</span>

  <span class="kw">def</span> initialize(attributes = {})
    <span class="ot">@survey</span> = attributes[<span class="st">:survey</span>]
    <span class="ot">@message</span> = attributes[<span class="st">:message</span>] || <span class="st">''</span>
    <span class="ot">@recipients</span> = attributes[<span class="st">:recipients</span>] || <span class="st">''</span>
    <span class="ot">@sender</span> = attributes[<span class="st">:sender</span>]
  <span class="kw">end</span>

  <span class="ot">attr_reader</span> <span class="st">:message</span>, <span class="st">:recipients</span>, <span class="st">:survey</span>

  <span class="kw">def</span> valid?
    valid_message? &amp;&amp; valid_recipients?
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    recipient_list.each <span class="kw">do</span> |email|
      invitation = <span class="dt">Invitation</span>.create(
        survey: <span class="ot">@survey</span>,
        sender: <span class="ot">@sender</span>,
        recipient_email: email,
        status: <span class="st">'pending'</span>
      )
      <span class="dt">Mailer</span>.invitation_notification(invitation, <span class="ot">@message</span>)
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">def</span> invalid_recipients
    <span class="ot">@invalid_recipients</span> ||= recipient_list.map <span class="kw">do</span> |item|
      <span class="kw">unless</span> item.match(<span class="dt">EMAIL_REGEX</span>)
        item
      <span class="kw">end</span>
    <span class="kw">end</span>.compact
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> valid_message?
    <span class="ot">@message</span>.present?
  <span class="kw">end</span>

  <span class="kw">def</span> valid_recipients?
    invalid_recipients.empty?
  <span class="kw">end</span>

  <span class="kw">def</span> recipient_list
    <span class="ot">@recipient_list</span> ||= <span class="ot">@recipients</span>.gsub(<span class="ot">/\s+/</span>, <span class="st">''</span>).split(<span class="ot">/[\n,;]+/</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>We can take this further by extracting more classes from <code>SurveyInviter</code>. See our <a href="https://github.com/thoughtbot/ruby-science/commit/fd6cd8d5">full solution on GitHub</a>.</p>
</section>
<section id="drawbacks-2" class="level3">
<h3><a href="#drawbacks-2">Drawbacks</a></h3>
<p>Extracting classes decreases the amount of complexity in each class, but increases the overall complexity of the application. Extracting too many classes will create a maze of indirection that developers will be unable to navigate.</p>
<p>Every class also requires a name. Introducing new names can help to explain functionality at a higher level and facilitate communication between developers. However, introducing too many names results in vocabulary overload, which makes the system difficult to learn for new developers.</p>
<p>If you extract classes in response to pain and resistance, you'll end up with just the right number of classes and names.</p>
</section>
<section id="next-steps-4" class="level3">
<h3><a href="#next-steps-4">Next Steps</a></h3>
<ul>
<li>Check the newly extracted class to make sure it isn't a <a href="#large-class">large class</a>, and extract another class if it is.</li>
<li>Check the original class for <a href="#feature-envy">feature envy</a> of the extracted class and use <a href="#move-method">move method</a> if necessary.</li>
</ul>
</section>
</section>
<section id="extract-value-object" class="level1">
<h1><a href="#extract-value-object">Extract Value Object</a></h1>
<p>Value Objects are objects that represent a value (such as a dollar amount) rather than a unique, identifiable entity (such as a particular user).</p>
<p>Value objects often implement information derived from a primitive object, such as the dollars and cents from a float, or the user name and domain from an email string.</p>
<section id="uses-5" class="level3">
<h3><a href="#uses-5">Uses</a></h3>
<ul>
<li>Prevent <a href="#duplicated-code">duplicated code</a> from making the same observations of primitive objects throughout the code base.</li>
<li>Remove <a href="#large-class">large classes</a> by splitting out query methods associated with a particular variable.</li>
<li>Make the code easier to understand by fully encapsulating related logic into a single class, following the <a href="#single-responsibility-principle">single responsibility principle</a>.</li>
<li>Eliminate <a href="#divergent-change">divergent change</a> by extracting code related to an embedded semantic type.</li>
</ul>
</section>
<section id="example-18" class="level3">
<h3><a href="#example-18">Example</a></h3>
<p><code>InvitationsController</code> is bloated with methods and logic relating to parsing a string that contains a list of email addresses:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">def</span> recipient_list
  <span class="ot">@recipient_list</span> ||= recipients.gsub(<span class="ot">/\s+/</span>, <span class="st">''</span>).split(<span class="ot">/[\n,;]+/</span>)
<span class="kw">end</span>

<span class="kw">def</span> recipients
  params[<span class="st">:invitation</span>][<span class="st">:recipients</span>]
<span class="kw">end</span></code></pre>
<p>We can <a href="#extract-class">extract a new class</a> to offload this responsibility:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/recipient_list.rb</span>
<span class="kw">class</span> <span class="dt">RecipientList</span>
  <span class="kw">include</span> <span class="dt">Enumerable</span>

  <span class="kw">def</span> initialize(recipient_string)
    <span class="ot">@recipient_string</span> = recipient_string
  <span class="kw">end</span>

  <span class="kw">def</span> each(&amp;block)
    recipients.each(&amp;block)
  <span class="kw">end</span>

  <span class="kw">def</span> to_s
    <span class="ot">@recipient_string</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> recipients
    <span class="ot">@recipient_string</span>.to_s.gsub(<span class="ot">/\s+/</span>, <span class="st">''</span>).split(<span class="ot">/[\n,;]+/</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">def</span> recipient_list
  <span class="ot">@recipient_list</span> ||= <span class="dt">RecipientList</span>.new(params[<span class="st">:invitation</span>][<span class="st">:recipients</span>])
<span class="kw">end</span></code></pre>
</section>
<section id="next-steps-5" class="level3">
<h3><a href="#next-steps-5">Next Steps</a></h3>
<ul>
<li>Search the application for <a href="#duplicated-code">duplicated code</a> related to the newly extracted class.</li>
<li>Value objects should be immutable. Make sure the extracted class doesn't have any writer methods.</li>
</ul>
</section>
</section>
<section id="extract-decorator" class="level1">
<h1><a href="#extract-decorator">Extract Decorator</a></h1>
<p>Decorators can be used to place new concerns on top of existing objects without modifying existing classes. They combine best with small classes containing few methods, and make the most sense when modifying the behavior of existing methods, rather than adding new methods.</p>
<p>The steps for extracting a decorator vary depending on the initial state, but they often include the following:</p>
<ol type="1">
<li>Extract a new decorator class, starting with the alternative behavior.</li>
<li>Compose the decorator in the original class.</li>
<li>Move state specific to the alternate behavior into the decorator.</li>
<li>Invert control, applying the decorator to the original class from its container, rather than composing the decorator from the original class.</li>
</ol>
<p>It will be difficult to make use of decorators unless your application is following <a href="#composition-over-inheritance">composition over inheritance</a>.</p>
<section id="uses-6" class="level3">
<h3><a href="#uses-6">Uses</a></h3>
<ul>
<li>Eliminate <a href="#large-class">large classes</a> by extracting concerns.</li>
<li>Eliminate <a href="#divergent-change">divergent change</a> and follow the <a href="#single-responsibility-principle">single responsibility principle</a> by adding new behavior without introducing new concerns to existing classes.</li>
<li>Prevent conditional logic from leaking by making decisions earlier.</li>
<li>Extend existing classes without modifying them, following the <a href="#openclosed-principle">open/closed principle</a>.</li>
</ul>
</section>
<section id="example-19" class="level3">
<h3><a href="#example-19">Example</a></h3>
<p>In our example application, users can view a summary of the answers to each question on a survey. By default, in order to prevent the summary from influencing a user's own answers, users don't see summaries for questions they haven't answered yet. Users can click a link to override this decision and view the summary for every question. This concern is mixed across several levels, and introducing the change affects several classes. Let's see if we can refactor our application to make similar changes easier in the future.</p>
<p>Currently, the controller determines whether or not unanswered questions should display summaries:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> constraints
  <span class="kw">if</span> include_unanswered?
    {}
  <span class="kw">else</span>
    { answered_by: current_user }
  <span class="kw">end</span>
<span class="kw">end</span>

<span class="kw">def</span> include_unanswered?
  params[<span class="st">:unanswered</span>]
<span class="kw">end</span></code></pre>
<p>It passes this decision into <code>Survey#summaries_using</code> as a hash containing Boolean flag:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="ot">@summaries</span> = <span class="ot">@survey</span>.summaries_using(summarizer, constraints)</code></pre>
<p></p>
<p><code>Survey#summaries_using</code> uses this information to decide whether each question should return a real summary or a hidden summary:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer, options = {})
  questions.map <span class="kw">do</span> |question|
    <span class="kw">if</span> !options[<span class="st">:answered_by</span>] || question.answered_by?(options[<span class="st">:answered_by</span>])
      question.summary_using(summarizer)
    <span class="kw">else</span>
      <span class="dt">Summary</span>.new(question.title, <span class="dt">NO_ANSWER</span>)
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This method is pretty dense. We can start by using <a href="#extract-method">extract method</a> to clarify and reveal complexity:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer, options = {})
  questions.map <span class="kw">do</span> |question|
    summary_or_hidden_answer(summarizer, question, options[<span class="st">:answered_by</span>])
  <span class="kw">end</span>
<span class="kw">end</span>

<span class="kw">private</span>

<span class="kw">def</span> summary_or_hidden_answer(summarizer, question, answered_by)
  <span class="kw">if</span> hide_unanswered_question?(question, answered_by)
    hide_answer_to_question(question)
  <span class="kw">else</span>
    question.summary_using(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span>

<span class="kw">def</span> hide_unanswered_question?(question, answered_by)
  answered_by &amp;&amp; !question.answered_by?(answered_by)
<span class="kw">end</span>

<span class="kw">def</span> hide_answer_to_question(question)
  <span class="dt">Summary</span>.new(question.title, <span class="dt">NO_ANSWER</span>)
<span class="kw">end</span></code></pre>
<p>The <code>summary_or_hidden_answer</code> method reveals a pattern that's well-captured by using a Decorator:</p>
<ul>
<li>There's a base case: returning the real summary for the question's answers.</li>
<li>There's an alternative, or decorated, case: returning a summary with a hidden answer.</li>
<li>The conditional logic for using the base or decorated case is unrelated to the base case: <code>answered_by</code> is only used for determining which path to take, and isn't used by to generate summaries.</li>
</ul>
<p>As a Rails developer, this may seem familiar to you: Many pieces of Rack middleware follow a similar approach.</p>
<p>Now that we've recognized this pattern, let's refactor to use a decorator.</p>
<section id="move-decorated-case-to-decorator" class="level4">
<h4><a href="#move-decorated-case-to-decorator">Move Decorated Case to Decorator</a></h4>
<p>Let's start by creating an empty class for the decorator and <a href="#move-method">moving one method</a> into it:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">class</span> <span class="dt">UnansweredQuestionHider</span>
  <span class="dt">NO_ANSWER</span> = <span class="st">&quot;You haven't answered this question&quot;</span>.freeze

  <span class="kw">def</span> hide_answer_to_question(question)
    <span class="dt">Summary</span>.new(question.title, <span class="dt">NO_ANSWER</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The method references a constant from <code>Survey</code>, so we moved that, too.</p>
<p>Now we update <code>Survey</code> to compose our new class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summary_or_hidden_answer(summarizer, question, answered_by)
  <span class="kw">if</span> hide_unanswered_question?(question, answered_by)
    <span class="dt">UnansweredQuestionHider</span>.new.hide_answer_to_question(question)
  <span class="kw">else</span>
    question.summary_using(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>At this point, the <a href="https://github.com/thoughtbot/ruby-science/commit/af2e8318">decorated path is contained within the decorator</a>.</p>
</section>
<section id="move-conditional-logic-into-decorator" class="level4">
<h4><a href="#move-conditional-logic-into-decorator">Move Conditional Logic Into Decorator</a></h4>
<p>Next, we can move the conditional logic into the decorator. We've already extracted this to its own method on <code>Survey</code>, so we can simply move this method over:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">def</span> hide_unanswered_question?(question, user)
  user &amp;&amp; !question.answered_by?(user)
<span class="kw">end</span></code></pre>
<p>Note that the <code>answered_by</code> parameter was renamed to <code>user</code>. That's because the context is more specific now, so it's clear what role the user is playing.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summary_or_hidden_answer(summarizer, question, answered_by)
  hider = <span class="dt">UnansweredQuestionHider</span>.new
  <span class="kw">if</span> hider.hide_unanswered_question?(question, answered_by)
    hider.hide_answer_to_question(question)
  <span class="kw">else</span>
    question.summary_using(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
</section>
<section id="move-body-into-decorator" class="level4">
<h4><a href="#move-body-into-decorator">Move Body Into Decorator</a></h4>
<p><a href="https://github.com/thoughtbot/ruby-science/commit/9d0274f4">There's just one summary-related method left in <code>Survey</code></a>: <code>summary_or_hidden_answer</code>. Let's move this into the decorator:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">def</span> summary_or_hidden_answer(summarizer, question, user)
  <span class="kw">if</span> hide_unanswered_question?(question, user)
    hide_answer_to_question(question)
  <span class="kw">else</span>
    question.summary_using(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer, options = {})
  questions.map <span class="kw">do</span> |question|
    <span class="dt">UnansweredQuestionHider</span>.new.summary_or_hidden_answer(
      summarizer,
      question,
      options[<span class="st">:answered_by</span>]
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p><a href="https://github.com/thoughtbot/ruby-science/commit/4fd00a88">At this point</a>, every other method in the decorator can be made private.</p>
<p></p>
</section>
<section id="promote-parameters-to-instance-variables" class="level4">
<h4><a href="#promote-parameters-to-instance-variables">Promote Parameters to Instance Variables</a></h4>
<p>Now that we have a class to handle this logic, we can move some of the parameters into instance state. In <code>Survey#summaries_using</code>, we use the same summarizer and user instance; only the question varies as we iterate through questions to summarize. Let's move everything but the question into instance variables on the decorator:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">def</span> initialize(summarizer, user)
  <span class="ot">@summarizer</span> = summarizer
  <span class="ot">@user</span> = user
<span class="kw">end</span>

<span class="kw">def</span> summary_or_hidden_answer(question)
  <span class="kw">if</span> hide_unanswered_question?(question)
    hide_answer_to_question(question)
  <span class="kw">else</span>
    question.summary_using(<span class="ot">@summarizer</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer, options = {})
  questions.map <span class="kw">do</span> |question|
    <span class="dt">UnansweredQuestionHider</span>.new(summarizer, options[<span class="st">:answered_by</span>]).
      summary_or_hidden_answer(question)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p><a href="https://github.com/thoughtbot/ruby-science/commit/72801b57">Our decorator now just needs a <code>question</code> to generate a <code>Summary</code></a>.</p>
</section>
<section id="change-decorator-to-follow-component-interface" class="level4">
<h4><a href="#change-decorator-to-follow-component-interface">Change Decorator to Follow Component Interface</a></h4>
<p>In the end, the component we want to wrap with our decorator is the summarizer, so we want the decorator to obey the same interface as its component—the summarizer. Let's rename our only public method so that it follows the summarizer interface:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">def</span> summarize(question)</code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="dt">UnansweredQuestionHider</span>.new(summarizer, options[<span class="st">:answered_by</span>]).
  summarize(question)</code></pre>
<p><a href="https://github.com/thoughtbot/ruby-science/commit/61ca6784">Our decorator now follows the component interface in name</a>—but not behavior. In our application, summarizers return a string that represents the answers to a question, but our decorator is returning a <code>Summary</code> instead. Let's fix our decorator to follow the component interface by returning just a string:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">def</span> summarize(question)
  <span class="kw">if</span> hide_unanswered_question?(question)
    hide_answer_to_question(question)
  <span class="kw">else</span>
    <span class="ot">@summarizer</span>.summarize(question)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">def</span> hide_answer_to_question(question)
  <span class="dt">NO_ANSWER</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer, options = {})
  questions.map <span class="kw">do</span> |question|
    hider = <span class="dt">UnansweredQuestionHider</span>.new(summarizer, options[<span class="st">:answered_by</span>])
    question.summary_using(hider)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Our decorator now <a href="https://github.com/thoughtbot/ruby-science/commit/876ec976">follows the component interface</a>.</p>
<p>That last method on the decorator (<code>hide_answer_to_question</code>) isn't pulling its weight anymore: It just returns the value from a constant. Let's <a href="https://github.com/thoughtbot/ruby-science/commit/77b22c5a">inline it</a> to slim down our class a bit:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">def</span> summarize(question)
  <span class="kw">if</span> hide_unanswered_question?(question)
    <span class="dt">NO_ANSWER</span>
  <span class="kw">else</span>
    <span class="ot">@summarizer</span>.summarize(question)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now we have a decorator that can wrap any summarizer, nicely-factored and ready to use.</p>
</section>
<section id="invert-control" class="level4">
<h4><a href="#invert-control">Invert Control</a></h4>
<p>Now comes one of the most important steps: We can <a href="#dependency-inversion-principle">invert control</a> by removing any reference to the decorator from <code>Survey</code> and passing in an already-decorated summarizer.</p>
<p>The <code>summaries_using</code> method is simplified:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer)
  questions.map <span class="kw">do</span> |question|
    question.summary_using(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Instead of passing the Boolean flag down from the controller, we can <a href="https://github.com/thoughtbot/ruby-science/commit/256a9c92">make the decision to decorate there</a> and pass a decorated or undecorated summarizer:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> show
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="ot">@summaries</span> = <span class="ot">@survey</span>.summaries_using(decorated_summarizer)
<span class="kw">end</span>

<span class="kw">private</span>

<span class="kw">def</span> decorated_summarizer
  <span class="kw">if</span> include_unanswered?
    summarizer
  <span class="kw">else</span>
    <span class="dt">UnansweredQuestionHider</span>.new(summarizer, current_user)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This isolates the decision to one class and keeps the result of the decision close to the class that makes it.</p>
<p>Another important effect of this refactoring is that the <code>Survey</code> class is now reverted back to <a href="https://github.com/thoughtbot/ruby-science/blob/d97f7856/example_app/app/models/survey.rb">the way it was before we started hiding unanswered question summaries</a>. This means that we can now add similar changes without modifying <code>Survey</code> at all.</p>
</section>
</section>
<section id="drawbacks-3" class="level3">
<h3><a href="#drawbacks-3">Drawbacks</a></h3>
<ul>
<li>Decorators must keep up to date with their component interface. Our decorator follows the summarizer interface. Every decorator we add for this interface is one more class that will need to change any time we change the interface.</li>
<li>We removed a concern from <code>Survey</code> by hiding it behind a decorator, but this may make it harder for a developer to understand how a <code>Survey</code> might return the hidden response text, since that text doesn't appear anywhere in that class.</li>
<li>The component we decorated had the smallest possible interface: one public method. Classes with more public methods are more difficult to decorate.</li>
<li>Decorators can modify methods in the component interface easily, but adding new methods won't work with multiple decorators without meta-programming like <code>method_missing</code>. These constructs are harder to follow and should be used with care.</li>
</ul>
</section>
<section id="next-steps-6" class="level3">
<h3><a href="#next-steps-6">Next Steps</a></h3>
<ul>
<li>It's unlikely that your automated test suite has enough coverage to check every component implementation with every decorator. Run through the application in a browser after introducing new decorators. Test and fix any issues you run into.</li>
<li>Make sure that inverting control didn't push anything over the line into a <a href="#large-class">large class</a>.</li>
</ul>
</section>
</section>
<section id="extract-partial" class="level1">
<h1><a href="#extract-partial">Extract Partial</a></h1>
<p>Extracting a partial is a technique used for removing complex or duplicated view code from your application. This is the equivalent of using <a href="#long-method">long method</a> and <a href="#extract-method">extract method</a> in your views and templates.</p>
<section id="uses-7" class="level3">
<h3><a href="#uses-7">Uses</a></h3>
<ul>
<li>Removes <a href="#duplicated-code">duplicated code</a> from views.</li>
<li>Avoids <a href="#shotgun-surgery">shotgun surgery</a> by forcing changes to happen in one place.</li>
<li>Removes <a href="#divergent-change">divergent change</a> by removing a reason for the view to change.</li>
<li>Groups common code.</li>
<li>Reduces view size and complexity.</li>
<li>Makes view logic easier to reuse, which makes it easier to <a href="#dry">avoid duplication</a>.</li>
</ul>
</section>
<section id="steps" class="level3">
<h3><a href="#steps">Steps</a></h3>
<ul>
<li>Create a new file for partial prefixed with an underscore (_filename.html.erb).</li>
<li>Move common code into newly created file.</li>
<li>Render the partial from the source file.</li>
</ul>
</section>
<section id="example-20" class="level3">
<h3><a href="#example-20">Example</a></h3>
<p>Let's revisit the view code for <em>adding</em> and <em>editing</em> questions.</p>
<p>Note: There are a few small differences in the files (the URL endpoint and the label on the submit button).</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/new.html.erb
<span class="kw">&lt;h1&gt;</span>Add Question<span class="kw">&lt;/h1&gt;</span>

<span class="kw">&lt;%=</span> simple_form_for <span class="ot">@question</span>, as: <span class="st">:question</span>, url: survey_questions_path(<span class="ot">@survey</span>) <span class="kw">do</span> <span class="ch">|</span>form<span class="ch">|</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> form.hidden_field <span class="st">:type</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> form.input <span class="st">:title</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> render <span class="st">&quot;</span><span class="ot">#{@question</span>.to_partial_path<span class="ot">}</span><span class="st">_form&quot;</span>, question: <span class="ot">@question</span>, form: form <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> form.submit <span class="st">'Create Question'</span> <span class="kw">%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/edit.html.erb
<span class="kw">&lt;h1&gt;</span>Edit Question<span class="kw">&lt;/h1&gt;</span>

<span class="kw">&lt;%=</span> simple_form_for <span class="ot">@question</span>, as: <span class="st">:question</span>, url: question_path <span class="kw">do</span> <span class="ch">|</span>form<span class="ch">|</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> form.hidden_field <span class="st">:type</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> form.input <span class="st">:title</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> render <span class="st">&quot;</span><span class="ot">#{@question</span>.to_partial_path<span class="ot">}</span><span class="st">_form&quot;</span>, question: <span class="ot">@question</span>, form: form <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> form.submit <span class="st">'Update Question'</span> <span class="kw">%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
<p>First, extract the common code into a partial, remove any instance variables and use <code>question</code> and <code>url</code> as local variables:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/_form.html.erb
<span class="kw">&lt;%=</span> simple_form_for question, as: <span class="st">:question</span>, url: url <span class="kw">do</span> <span class="ch">|</span>form<span class="ch">|</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> form.hidden_field <span class="st">:type</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> form.input <span class="st">:title</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> render <span class="st">&quot;</span><span class="ot">#{</span>question.to_partial_path<span class="ot">}</span><span class="st">_form&quot;</span>, question: question, form: form <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> form.submit <span class="kw">%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
<p>Move the submit button text into the locales file:</p>
<pre><code># config/locales/en.yml
en:
  helpers:
    submit:
      question:
        create: 'Create Question'
        update: 'Update Question'</code></pre>
<p>Then render the partial from each of the views, passing in the values for <code>question</code> and <code>url</code>:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/new.html.erb
<span class="kw">&lt;h1&gt;</span>Add Question<span class="kw">&lt;/h1&gt;</span>

<span class="kw">&lt;%=</span> render <span class="st">'form'</span>, question: <span class="ot">@question</span>, url: survey_questions_path(<span class="ot">@survey</span>) <span class="kw">%&gt;</span></code></pre>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/edit.html.erb
<span class="kw">&lt;h1&gt;</span>Edit Question<span class="kw">&lt;/h1&gt;</span>

<span class="kw">&lt;%=</span> render <span class="st">'form'</span>, question: <span class="ot">@question</span>, url: question_path <span class="kw">%&gt;</span></code></pre>
</section>
<section id="next-steps-7" class="level3">
<h3><a href="#next-steps-7">Next Steps</a></h3>
<ul>
<li>Check for other occurrences of the duplicated view code in your application and replace them with the newly extracted partial.</li>
</ul>
</section>
</section>
<section id="extract-validator" class="level1">
<h1><a href="#extract-validator">Extract Validator</a></h1>
<p>Extract Validator is a form of <a href="#extract-class">extract class</a> that is used to remove complex validation details from <code>ActiveRecord</code> models. This technique also prevents duplication of validation code across several files.</p>
<section id="uses-8" class="level3">
<h3><a href="#uses-8">Uses</a></h3>
<ul>
<li>Keeps validation implementation details out of models.</li>
<li>Encapsulates validation details into a single file, following the <a href="#single-responsibility-principle">single responsibility principle</a>.</li>
<li>Removes duplication among classes performing the same validation logic.</li>
<li>Makes validation logic easier to reuse, which makes it easier to <a href="#dry">avoid duplication</a>.</li>
</ul>
</section>
<section id="example-21" class="level3">
<h3><a href="#example-21">Example</a></h3>
<p>The <code>Invitation</code> class has validation details in-line. It checks that the <code>recipient_email</code> matches the formatting of the regular expression <code>EMAIL_REGEX</code>.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">class</span> <span class="dt">Invitation</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span>
  <span class="dt">EMAIL_REGEX</span> = <span class="ot">/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/i</span>
  validates <span class="st">:recipient_email</span>, presence: <span class="dv">true</span>, format: <span class="dt">EMAIL_REGEX</span>
<span class="kw">end</span></code></pre>
<p>We extract the validation details into a new class <code>EmailValidator</code> and place the new class into the <code>app/validators</code> directory:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/validators/email_validator.rb</span>
<span class="kw">class</span> <span class="dt">EmailValidator</span> &lt; <span class="dt">ActiveModel</span>::<span class="dt">EachValidator</span>
  <span class="dt">EMAIL_REGEX</span> = <span class="ot">/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/i</span>
  <span class="kw">def</span> validate_each(record, attribute, value)
    <span class="kw">unless</span> value.match <span class="dt">EMAIL_REGEX</span>
      record.errors.add(attribute, <span class="st">&quot;</span><span class="ot">#{</span>value<span class="ot">}</span><span class="st"> is not a valid email&quot;</span>)
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Once the validator has been extracted, Rails has a convention for using the new validation class. <code>EmailValidator</code> is used by setting <code>email: true</code> in the validation arguments:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">class</span> <span class="dt">Invitation</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span>
  validates <span class="st">:recipient_email</span>, presence: <span class="dv">true</span>, email: <span class="dv">true</span>
<span class="kw">end</span></code></pre>
<p>The convention is to use the validation class name (in lower case, and removing <code>Validator</code> from the name). For example, if we were validating an attribute with <code>ZipCodeValidator</code>, we'd set <code>zip_code: true</code> as an argument to the validation call.</p>
<p>When validating an array of data as we do in <code>SurveyInviter</code>, we use the <code>EnumerableValidator</code> to loop over the contents of an array.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
validates_with <span class="dt">EnumerableValidator</span>,
  attributes: [<span class="st">:recipients</span>],
  <span class="kw">unless</span>: <span class="st">'recipients.nil?'</span>,
  validator: <span class="dt">EmailValidator</span></code></pre>
<p></p>
<p>The <code>EmailValidator</code> is passed in as an argument, and each element in the array is validated against it.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/validators/enumerable_validator.rb</span>
<span class="kw">class</span> <span class="dt">EnumerableValidator</span> &lt; <span class="dt">ActiveModel</span>::<span class="dt">EachValidator</span>
  <span class="kw">def</span> validate_each(record, attribute, enumerable)
    enumerable.each <span class="kw">do</span> |value|
      validator.validate_each(record, attribute, value)
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> validator
    options[<span class="st">:validator</span>].new(validator_options)
  <span class="kw">end</span>

  <span class="kw">def</span> validator_options
    options.except(<span class="st">:validator</span>).merge(attributes: attributes)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
</section>
<section id="next-steps-8" class="level3">
<h3><a href="#next-steps-8">Next Steps</a></h3>
<ul>
<li>Verify the extracted validator does not have any <a href="#long-methods">long methods</a>.</li>
<li>Check for other models that could use the validator.</li>
</ul>
</section>
</section>
<section id="introduce-explaining-variable" class="level1">
<h1><a href="#introduce-explaining-variable">Introduce Explaining Variable</a></h1>
<p>This refactoring allows you to break up a complex, hard-to-read statement by placing part of it in a local variable. The only difficult part is finding a good name for the variable.</p>
<section id="uses-9" class="level3">
<h3><a href="#uses-9">Uses</a></h3>
<ul>
<li>Improves legibility of code.</li>
<li>Makes it easier to <a href="#extract-method">extract methods</a> by breaking up long statements.</li>
<li>Removes the need for extra <a href="#comments">comments</a>.</li>
</ul>
</section>
<section id="example-22" class="level3">
<h3><a href="#example-22">Example</a></h3>
<p>This line of code was deemed hard enough to understand that adding a comment was necessary:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_question.rb</span>
<span class="kw">def</span> summary
  <span class="co"># Text for each answer in order as a comma-separated string</span>
  answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>).join(<span class="st">', '</span>)
<span class="kw">end</span></code></pre>
<p>Adding an explaining variable makes the line easy to understand without requiring a comment:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_question.rb</span>
<span class="kw">def</span> summary
  text_from_ordered_answers = answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>)
  text_from_ordered_answers.join(<span class="st">', '</span>)
<span class="kw">end</span></code></pre>
<p>You can follow up by using <a href="#replace-temp-with-query">replace temp with query</a>.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> summary
  text_from_ordered_answers.join(<span class="st">', '</span>)
<span class="kw">end</span>

<span class="kw">private</span>

<span class="kw">def</span> text_from_ordered_answers
  answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>)
<span class="kw">end</span></code></pre>
<p>This increases the overall size of the class and moves <code>text_from_ordered_answers</code> further away from <code>summary</code>, so you'll want to be careful when doing this. The most obvious reason to extract a method is to reuse the value of the variable.</p>
<p>However, there's another potential benefit: It changes the way developers read the code. Developers instinctively read code from the top down. Expressions based on variables place the details first, which means that developers will start with the details:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby">text_from_ordered_answers = answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>)</code></pre>
<p>And work their way down to the overall goal of a method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby">text_from_ordered_answers.join(<span class="st">', '</span>)</code></pre>
<p>Note that you naturally focus first on the code necessary to find the array of texts and then progress to see what happens to those texts.</p>
<p>Once a method is extracted, the high-level concept comes first:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> summary
  text_from_ordered_answers.join(<span class="st">', '</span>)
<span class="kw">end</span></code></pre>
<p>And then you progress to the details:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> text_from_ordered_answers
  answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>)
<span class="kw">end</span></code></pre>
<p>You can use this technique of extracting methods to ensure that developers focus on what's important first and only dive into the implementation details when necessary.</p>
</section>
<section id="next-steps-9" class="level3">
<h3><a href="#next-steps-9">Next Steps</a></h3>
<ul>
<li><a href="#replace-temp-with-query">Replace temp with query</a> if you want to reuse the expression or revert to the order in which a developer naturally reads the method.</li>
<li>Check the affected expression to make sure that it's easy to read. If it's still too dense, try extracting more variables or methods.</li>
<li>Check the extracted variable or method for <a href="#feature-envy">feature envy</a>.</li>
</ul>
</section>
</section>
<section id="introduce-form-object" class="level1">
<h1><a href="#introduce-form-object">Introduce Form Object</a></h1>
<p>This is a specialized type of <a href="#extract-class">extract class</a> that is used to remove business logic from controllers when processing data outside of an ActiveRecord model.</p>
<section id="uses-10" class="level3">
<h3><a href="#uses-10">Uses</a></h3>
<ul>
<li>Keeps business logic out of controllers and views.</li>
<li>Adds validation support to plain old Ruby objects.</li>
<li>Displays form validation errors using Rails conventions.</li>
<li>Sets the stage for <a href="#extract-validator">extract validator</a>.</li>
</ul>
</section>
<section id="example-23" class="level3">
<h3><a href="#example-23">Example</a></h3>
<p>The <code>create</code> action of our <code>InvitationsController</code> relies on user-submitted data for <code>message</code> and <code>recipients</code> (a comma-delimited list of email addresses).</p>
<p>It performs a number of tasks:</p>
<ul>
<li>Finds the current survey.</li>
<li>Validates that the <code>message</code> is present.</li>
<li>Validates each of the <code>recipients</code>' email addresses.</li>
<li>Creates an invitation for each of the recipients.</li>
<li>Sends an email to each of the recipients.</li>
<li>Sets view data for validation failures.</li>
</ul>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">class</span> <span class="dt">InvitationsController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="dt">EMAIL_REGEX</span> = <span class="ot">/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/</span>

  <span class="kw">def</span> new
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="kw">end</span>

  <span class="kw">def</span> create
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
    <span class="kw">if</span> valid_recipients? &amp;&amp; valid_message?
      recipient_list.each <span class="kw">do</span> |email|
        invitation = <span class="dt">Invitation</span>.create(
          survey: <span class="ot">@survey</span>,
          sender: current_user,
          recipient_email: email,
          status: <span class="st">'pending'</span>
        )
        <span class="dt">Mailer</span>.invitation_notification(invitation, message)
      <span class="kw">end</span>
      redirect_to survey_path(<span class="ot">@survey</span>), notice: <span class="st">'Invitation successfully sent'</span>
    <span class="kw">else</span>
      <span class="ot">@recipients</span> = recipients
      <span class="ot">@message</span> = message
      render <span class="st">'new'</span>
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> valid_recipients?
    invalid_recipients.empty?
  <span class="kw">end</span>

  <span class="kw">def</span> valid_message?
    message.present?
  <span class="kw">end</span>

  <span class="kw">def</span> invalid_recipients
    <span class="ot">@invalid_recipients</span> ||= recipient_list.map <span class="kw">do</span> |item|
      <span class="kw">unless</span> item.match(<span class="dt">EMAIL_REGEX</span>)
        item
      <span class="kw">end</span>
    <span class="kw">end</span>.compact
  <span class="kw">end</span>

  <span class="kw">def</span> recipient_list
    <span class="ot">@recipient_list</span> ||= recipients.gsub(<span class="ot">/\s+/</span>, <span class="st">''</span>).split(<span class="ot">/[\n,;]+/</span>)
  <span class="kw">end</span>

  <span class="kw">def</span> recipients
    params[<span class="st">:invitation</span>][<span class="st">:recipients</span>]
  <span class="kw">end</span>

  <span class="kw">def</span> message
    params[<span class="st">:invitation</span>][<span class="st">:message</span>]
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>By introducing a form object, we can move the concerns of data validation, invitation creation and notifications to the new model <code>SurveyInviter</code>.</p>
<p>Including <a href="https://github.com/rails/rails/blob/master/activemodel/lib/active_model/model.rb">ActiveModel::Model</a> allows us to leverage the familiar <a href="http://guides.rubyonrails.org/active_record_validations_callbacks.html">active record validation</a> syntax.</p>
<p></p>
<p>As we introduce the form object, we'll also extract an enumerable class <code>RecipientList</code> and validators <code>EnumerableValidator</code> and <code>EmailValidator</code>. These will be covered in the <a href="#extract-class">Extract Class</a> and <a href="#extract-validator">Extract Validator</a> chapters.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">class</span> <span class="dt">SurveyInviter</span>
  <span class="kw">include</span> <span class="dt">ActiveModel</span>::<span class="dt">Model</span>
  <span class="ot">attr_accessor</span> <span class="st">:recipients</span>, <span class="st">:message</span>, <span class="st">:sender</span>, <span class="st">:survey</span>

  validates <span class="st">:message</span>, presence: <span class="dv">true</span>
  validates <span class="st">:recipients</span>, length: { minimum: <span class="dv">1</span> }
  validates <span class="st">:sender</span>, presence: <span class="dv">true</span>
  validates <span class="st">:survey</span>, presence: <span class="dv">true</span>

  validates_with <span class="dt">EnumerableValidator</span>,
    attributes: [<span class="st">:recipients</span>],
    <span class="kw">unless</span>: <span class="st">'recipients.nil?'</span>,
    validator: <span class="dt">EmailValidator</span>

  <span class="kw">def</span> recipients=(recipients)
    <span class="ot">@recipients</span> = <span class="dt">RecipientList</span>.new(recipients)
  <span class="kw">end</span>

  <span class="kw">def</span> invite
    <span class="kw">if</span> valid?
      deliver_invitations
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> create_invitations
    recipients.map <span class="kw">do</span> |recipient_email|
      <span class="dt">Invitation</span>.create!(
        survey: survey,
        sender: sender,
        recipient_email: recipient_email,
        status: <span class="st">'pending'</span>
      )
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">def</span> deliver_invitations
    create_invitations.each <span class="kw">do</span> |invitation|
      <span class="dt">Mailer</span>.invitation_notification(invitation, message).deliver
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Moving business logic into the new form object dramatically reduces the size and complexity of the <code>InvitationsController</code>. The controller is now focused on the interaction between the user and the models.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/invitations_controller.rb</span>
<span class="kw">class</span> <span class="dt">InvitationsController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="kw">def</span> new
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
    <span class="ot">@survey_inviter</span> = <span class="dt">SurveyInviter</span>.new
  <span class="kw">end</span>

  <span class="kw">def</span> create
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
    <span class="ot">@survey_inviter</span> = <span class="dt">SurveyInviter</span>.new(survey_inviter_params)

    <span class="kw">if</span> <span class="ot">@survey_inviter</span>.invite
      redirect_to survey_path(<span class="ot">@survey</span>), notice: <span class="st">'Invitation successfully sent'</span>
    <span class="kw">else</span>
      render <span class="st">'new'</span>
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> survey_inviter_params
    params.require(<span class="st">:survey_inviter</span>).permit(
      <span class="st">:message</span>,
      <span class="st">:recipients</span>
    ).merge(
      sender: current_user,
      survey: <span class="ot">@survey</span>
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
</section>
<section id="next-steps-10" class="level3">
<h3><a href="#next-steps-10">Next Steps</a></h3>
<ul>
<li>Check that the controller no longer has <a href="#long-method">long methods</a>.</li>
<li>Verify the new form object is not a <a href="#large-class">large class</a>.</li>
<li>Check for places to re-use any new validators if <a href="#extract-validator">extract validator</a> was used during the refactoring.</li>
</ul>
</section>
</section>
<section id="introduce-parameter-object" class="level1">
<h1><a href="#introduce-parameter-object">Introduce Parameter Object</a></h1>
<p>This is a technique to reduce the number of input parameters to a method.</p>
<p>To introduce a Parameter Object:</p>
<ul>
<li>Pick a name for the object that represents the grouped parameters.</li>
<li>Replace the method's grouped parameters with the object.</li>
</ul>
<section id="uses-11" class="level3">
<h3><a href="#uses-11">Uses</a></h3>
<ul>
<li>Removes <a href="#long-parameter-list">long parameter lists</a>.</li>
<li>Groups parameters that naturally fit together.</li>
<li>Encapsulates behavior between related parameters.</li>
</ul>
<p></p>
</section>
<section id="example-24" class="level3">
<h3><a href="#example-24">Example</a></h3>
<p>Let's take a look at the example from <a href="#long-parameter-list">Long Parameter List</a> and improve it by grouping the related parameters into an object:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/mailers/mailer.rb</span>
<span class="kw">class</span> <span class="dt">Mailer</span> &lt; <span class="dt">ActionMailer</span>::<span class="dt">Base</span>
  default from: <span class="st">&quot;from@example.com&quot;</span>

  <span class="kw">def</span> completion_notification(first_name, last_name, email)
    <span class="ot">@first_name</span> = first_name
    <span class="ot">@last_name</span> = last_name

    mail(
      to: email,
      subject: <span class="st">'Thank you for completing the survey'</span>
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/mailer/completion_notification.html.erb
<span class="kw">&lt;%=</span> <span class="ot">@first_name</span> <span class="kw">%&gt;</span> <span class="kw">&lt;%=</span> <span class="ot">@last_name</span> <span class="kw">%&gt;</span></code></pre>
<p></p>
<p>By introducing the new parameter object <code>recipient</code> we can naturally group the attributes <code>first_name</code>, <code>last_name</code>, and <code>email</code> together.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/mailers/mailer.rb</span>
<span class="kw">class</span> <span class="dt">Mailer</span> &lt; <span class="dt">ActionMailer</span>::<span class="dt">Base</span>
  default from: <span class="st">&quot;from@example.com&quot;</span>

  <span class="kw">def</span> completion_notification(recipient)
    <span class="ot">@recipient</span> = recipient

    mail(
      to: recipient.email,
      subject: <span class="st">'Thank you for completing the survey'</span>
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This also gives us the opportunity to create a new <code>full_name</code> method on the <code>recipient</code> object to encapsulate behavior between the <code>first_name</code> and <code>last_name</code>.</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/mailer/completion_notification.html.erb
<span class="kw">&lt;%=</span> <span class="ot">@recipient</span>.full_name <span class="kw">%&gt;</span></code></pre>
</section>
<section id="next-steps-11" class="level3">
<h3><a href="#next-steps-11">Next Steps</a></h3>
<ul>
<li>Check to see if the same data clump exists elsewhere in the application and reuse the parameter object to group them together.</li>
<li>Verify the methods using the parameter object don't have <a href="#feature-envy">feature envy</a>.</li>
</ul>
</section>
</section>
<section id="use-class-as-factory" class="level1">
<h1><a href="#use-class-as-factory">Use Class as Factory</a></h1>
<p>An Abstract Factory is an object that knows how to build something, such as one of several possible strategies for summarizing answers to questions on a survey. An object that holds a reference to an abstract factory doesn't need to know what class is going to be used; it trusts the factory to return an object that responds to the required interface.</p>
<p>Because classes are objects in Ruby, every class can act as an abstract factory. Using a class as a factory allows us to remove most explicit factory objects.</p>
<section id="uses-12" class="level3">
<h3><a href="#uses-12">Uses</a></h3>
<ul>
<li>Removes <a href="#duplicated-code">duplicated code</a> and <a href="#shotgun-surgery">shotgun surgery</a> by cutting out crufty factory classes.</li>
<li>Combines with <a href="#convention-over-configuration">convention over configuration</a> to eliminate <a href="#shotgun-surgery">shotgun surgery</a> and <a href="#case-statement">case statements</a>.</li>
</ul>
<p></p>
</section>
<section id="example-25" class="level3">
<h3><a href="#example-25">Example</a></h3>
<p>This controller uses one of several possible summarizer strategies to generate a summary of answers to the questions on a survey:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">class</span> <span class="dt">SummariesController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="kw">def</span> show
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
    <span class="ot">@summaries</span> = <span class="ot">@survey</span>.summarize(summarizer)
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> summarizer
    <span class="kw">case</span> params[<span class="st">:id</span>]
    <span class="kw">when</span> <span class="st">'breakdown'</span>
      <span class="dt">Breakdown</span>.new
    <span class="kw">when</span> <span class="st">'most_recent'</span>
      <span class="dt">MostRecent</span>.new
    <span class="kw">when</span> <span class="st">'your_answers'</span>
      <span class="dt">UserAnswer</span>.new(current_user)
    <span class="kw">else</span>
      raise <span class="st">&quot;Unknown summary type: </span><span class="ot">#{</span>params[<span class="st">:id</span>]<span class="ot">}</span><span class="st">&quot;</span>
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The <code>summarizer</code> method is a Factory Method. It returns a summarizer object based on <code>params[:id]</code>.</p>
<p></p>
<p>We can refactor that using the abstract factory pattern:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> summarizer
  summarizer_factory.build
<span class="kw">end</span>

<span class="kw">def</span> summarizer_factory
  <span class="kw">case</span> params[<span class="st">:id</span>]
  <span class="kw">when</span> <span class="st">'breakdown'</span>
    <span class="dt">BreakdownFactory</span>.new
  <span class="kw">when</span> <span class="st">'most_recent'</span>
    <span class="dt">MostRecentFactory</span>.new
  <span class="kw">when</span> <span class="st">'your_answers'</span>
    <span class="dt">UserAnswerFactory</span>.new(current_user)
  <span class="kw">else</span>
    raise <span class="st">&quot;Unknown summary type: </span><span class="ot">#{</span>params[<span class="st">:id</span>]<span class="ot">}</span><span class="st">&quot;</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now the <code>summarizer</code> method asks the <code>summarizer_factory</code> method for an abstract factory, and it asks the factory to build the actual summarizer instance.</p>
<p>However, this means we need to provide an abstract factory for each summarizer strategy:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">BreakdownFactory</span>
  <span class="kw">def</span> build
    <span class="dt">Breakdown</span>.new
  <span class="kw">end</span>
<span class="kw">end</span>

<span class="kw">class</span> <span class="dt">MostRecentFactory</span>
  <span class="kw">def</span> build
    <span class="dt">MostRecent</span>.new
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">UserAnswerFactory</span>
  <span class="kw">def</span> initialize(user)
    <span class="ot">@user</span> = user
  <span class="kw">end</span>

  <span class="kw">def</span> build
    <span class="dt">UserAnswer</span>.new(<span class="ot">@user</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>These factory classes are repetitive and don't pull their weight. We can rip two of these classes out by using the actual summarizer class as the factory instance. First, let's rename the <code>build</code> method to <code>new</code>, to follow the Ruby convention:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> summarizer
  summarizer_factory.new
<span class="kw">end</span>

<span class="kw">class</span> <span class="dt">BreakdownFactory</span>
  <span class="kw">def</span> new
    <span class="dt">Breakdown</span>.new
  <span class="kw">end</span>
<span class="kw">end</span>

<span class="kw">class</span> <span class="dt">MostRecentFactory</span>
  <span class="kw">def</span> new
    <span class="dt">MostRecent</span>.new
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">UserAnswerFactory</span>
  <span class="kw">def</span> initialize(user)
    <span class="ot">@user</span> = user
  <span class="kw">end</span>

  <span class="kw">def</span> new
    <span class="dt">UserAnswer</span>.new(<span class="ot">@user</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now, an instance of <code>BreakdownFactory</code> acts exactly like the <code>Breakdown</code> class itself, and the same is true of <code>MostRecentFactory</code> and <code>MostRecent</code>. Therefore, let's use the classes themselves instead of instances of the factory classes:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> summarizer_factory
  <span class="kw">case</span> params[<span class="st">:id</span>]
  <span class="kw">when</span> <span class="st">'breakdown'</span>
    <span class="dt">Breakdown</span>
  <span class="kw">when</span> <span class="st">'most_recent'</span>
    <span class="dt">MostRecent</span>
  <span class="kw">when</span> <span class="st">'your_answers'</span>
    <span class="dt">UserAnswerFactory</span>.new(current_user)
  <span class="kw">else</span>
    raise <span class="st">&quot;Unknown summary type: </span><span class="ot">#{</span>params[<span class="st">:id</span>]<span class="ot">}</span><span class="st">&quot;</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now we can delete two of our factory classes.</p>
</section>
<section id="next-steps-12" class="level3">
<h3><a href="#next-steps-12">Next Steps</a></h3>
<ul>
<li><a href="#use-convention-over-configuration">Use convention over configuration</a> to remove manual mappings and possibly remove more classes.</li>
</ul>
</section>
</section>
<section id="move-method" class="level1">
<h1><a href="#move-method">Move Method</a></h1>
<p>Moving methods is generally easy. Moving a method allows you to place a method closer to the state it uses by moving it to the class that owns the related state.</p>
<p>To move a method:</p>
<ul>
<li>Move the entire method definition and body into the new class.</li>
<li>Change any parameters that are part of the state of the new class to simply reference the instance variables or methods.</li>
<li>Introduce any necessary parameters because of state which belongs to the old class.</li>
<li>Rename the method if the new name no longer makes sense in the new context (for example, rename <code>invite_user</code> to <code>invite</code> once the method is moved to the <code>User</code> class).</li>
<li>Replace calls to the old method to calls to the new method. This may require introducing delegation or building an instance of the new class.</li>
</ul>
<section id="uses-13" class="level3">
<h3><a href="#uses-13">Uses</a></h3>
<ul>
<li>Removes <a href="#feature-envy">feature envy</a> by moving a method to the class where the envied methods live.</li>
<li>Makes private, parameterized methods easier to reuse by moving them to public, unparameterized methods.</li>
<li>Improves readability by keeping methods close to the other methods they use.</li>
</ul>
<p>Let's take a look at an example method that suffers from <a href="#feature-envy">feature envy</a> and use <a href="#extract-method">extract method</a> and <a href="#move-method">move method</a> to improve it:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/completion.rb</span>
<span class="kw">def</span> score
  answers.inject(<span class="dv">0</span>) <span class="kw">do</span> |result, answer|
    question = answer.question
    result + question.score(answer.text)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The block in this method suffers from <a href="#feature-envy">feature envy</a>: It references <code>answer</code> more than it references methods or instance variables from its own class. We can't move the entire method; we only want to move the block, so let's first extract a method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/completion.rb</span>
<span class="kw">def</span> score
  answers.inject(<span class="dv">0</span>) <span class="kw">do</span> |result, answer|
    result + score_for_answer(answer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/completion.rb</span>
<span class="kw">def</span> score_for_answer(answer)
  question = answer.question
  question.score(answer.text)
<span class="kw">end</span></code></pre>
<p>The <code>score</code> method no longer suffers from <a href="#feature-envy">feature envy</a>, and the new <code>score_for_answer</code> method is easy to move, because it only references its own state. See the <a href="#extract-method">Extract Method</a> chapter for details on the mechanics and properties of this refactoring.</p>
<p>Now that the <a href="#feature-envy">feature envy</a> is isolated, let's resolve it by moving the method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/completion.rb</span>
<span class="kw">def</span> score
  answers.inject(<span class="dv">0</span>) <span class="kw">do</span> |result, answer|
    result + answer.score
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/answer.rb</span>
<span class="kw">def</span> score
  question.score(text)
<span class="kw">end</span></code></pre>
<p>The newly extracted and moved <code>Question#score</code> method no longer suffers from <a href="#feature-envy">feature envy</a>. It's easier to reuse, because the logic is freed from the internal block in <code>Completion#score</code>. It's also available to other classes because it's no longer a private method. Both methods are also easier to follow because the methods they invoke are close to the methods they depend on.</p>
</section>
<section id="dangerous-move-and-extract-at-the-same-time" class="level3">
<h3><a href="#dangerous-move-and-extract-at-the-same-time">Dangerous: Move and Extract at the Same Time</a></h3>
<p>It's tempting to do everything as one change: create a new method in <code>Answer</code>, move the code over from <code>Completion</code> and change <code>Completion#score</code> to call the new method. Although this frequently works without a hitch, with practice, you can perform the two, smaller refactorings just as quickly as the single, larger refactoring. By breaking the refactoring into two steps, you reduce the duration of &quot;down time&quot; for your code; that is, you reduce the amount of time during which something is broken. Improving code in smaller steps makes it easier to debug when something goes wrong and prevents you from writing more code than you need to. Because the code still works after each step, you can simply stop whenever you're happy with the results.</p>
</section>
<section id="next-steps-13" class="level3">
<h3><a href="#next-steps-13">Next Steps</a></h3>
<ul>
<li>Make sure the new method doesn't suffer from <a href="#feature-envy">feature envy</a> because of state it used from its original class. If it does, try splitting the method up and moving part of it back.</li>
<li>Check the class of the new method to make sure it's not a <a href="#large-class">large class</a>.</li>
</ul>
</section>
</section>
<section id="inline-class" class="level1">
<h1><a href="#inline-class">Inline Class</a></h1>
<p>As an application evolves, new classes are introduced as new features are added and existing code is refactored. <a href="#extract-class">Extracting classes</a> will help keep existing classes maintainable and make it easier to add new features. However, features can also be removed or simplified, and you'll inevitably find that some classes just aren't pulling their weight. Removing dead-weight classes is just as important as splitting up <a href="#large-class">large classes</a>; inlining a class is the easiest way to remove it.</p>
<p>Inlining a class is straightforward:</p>
<ul>
<li>For each consumer class that uses the inlined class, inline or move each method from the inlined class into the consumer class.</li>
<li>Remove the inlined class.</li>
</ul>
<p>Note that this refactoring is difficult (and unwise!) if you have more than one or two consumer classes.</p>
<section id="uses-14" class="level3">
<h3><a href="#uses-14">Uses</a></h3>
<ul>
<li>Makes classes easier to understand by eliminating the number of methods, classes, and files developers need to look through.</li>
<li>Eliminates <a href="#shotgun-surgery">shotgun surgery</a> from changes that cascade through useless classes.</li>
<li>Eliminates <a href="#feature-envy">feature envy</a> when the envied class can be inlined into the envious class.</li>
</ul>
</section>
<section id="example-26" class="level3">
<h3><a href="#example-26">Example</a></h3>
<p>In our example application, users can create surveys and invite other users to answer them. Users are invited by listing email addresses to invite.</p>
<p>Any email addresses that match up with existing users are sent using a private message that the user will see the next time he or she signs in. Invitations to unrecognized addresses are sent using email messages.</p>
<p>The <code>Invitation</code> model delegates to a different strategy class based on whether or not its recipient email is recognized as an existing user:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">def</span> deliver
  <span class="kw">if</span> recipient_user
    <span class="dt">MessageInviter</span>.new(<span class="dv">self</span>, recipient_user).deliver
  <span class="kw">else</span>
    <span class="dt">EmailInviter</span>.new(<span class="dv">self</span>).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>We've decided that the private messaging feature isn't getting enough use, so we're going to remove it. This means that all invitations will now be delivered via email, so we can simplify <code>Invitation#deliver</code> to always use the same strategy:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">def</span> deliver
  <span class="dt">EmailInviter</span>.new(<span class="dv">self</span>).deliver
<span class="kw">end</span></code></pre>
<p>The <code>EmailInviter</code> class was useful as a strategy, but now that the strategy no longer varies, it doesn't bring much to the table:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/email_inviter.rb</span>
<span class="kw">class</span> <span class="dt">EmailInviter</span>
  <span class="kw">def</span> initialize(invitation)
    <span class="ot">@invitation</span> = invitation
    <span class="ot">@body</span> = <span class="dt">InvitationMessage</span>.new(<span class="ot">@invitation</span>).body
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Mailer</span>.invitation_notification(<span class="ot">@invitation</span>, <span class="ot">@body</span>).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>It doesn't handle any concerns that aren't already well-encapsulated by <code>InvitationMessage</code> and <code>Mailer</code>, and it's only used once (in <code>Invitation</code>). We can inline this class into <code>Invitation</code> and eliminate some complexity and indirection from our application.</p>
<p>First, <a href="https://github.com/thoughtbot/ruby-science/commit/dcc40d60">let's inline the <code>EmailInviter#deliver</code> method</a> (and its dependent variables from <code>EmailInviter#initialize</code>):</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">def</span> deliver
  body = <span class="dt">InvitationMessage</span>.new(<span class="dv">self</span>).body
  <span class="dt">Mailer</span>.invitation_notification(<span class="dv">self</span>, body).deliver
<span class="kw">end</span></code></pre>
<p>Next, we can <a href="https://github.com/thoughtbot/ruby-science/commit/bc863108">delete <code>EmailInviter</code> entirely</a>.</p>
<p>After inlining the class, it requires fewer jumps through methods, classes and files to understand how invitations are delivered. Additionally, the application is less complex, overall. Flog gives us a total complexity score of 424.7 after this refactoring, down slightly from 427.6. That isn't a huge gain, but this was an easy refactoring, and continually deleting or inlining unnecessary classes and methods will have broader long-term effects.</p>
</section>
<section id="drawbacks-4" class="level3">
<h3><a href="#drawbacks-4">Drawbacks</a></h3>
<ul>
<li>Attempting to inline a class with multiple consumers will likely introduce <a href="#duplicated-code">duplicated code</a>.</li>
<li>Inlining a class may create <a href="#large-class">large classes</a> and cause <a href="#divergent-change">divergent change</a>.</li>
<li>Inlining a class will usually increase per-class or per-method complexity, even if it reduces total complexity.</li>
</ul>
</section>
<section id="next-steps-14" class="level3">
<h3><a href="#next-steps-14">Next Steps</a></h3>
<ul>
<li>Use <a href="#extract-method">extract method</a> if any inlined methods introduced <a href="#long-method">long methods</a>.</li>
<li>Use <a href="#extract-class">extract class</a> if the merged class is a <a href="#large-class">large class</a> or is suffering from <a href="#divergent-change">divergent change</a>.</li>
</ul>
</section>
</section>
<section id="inject-dependencies" class="level1">
<h1><a href="#inject-dependencies">Inject Dependencies</a></h1>
<p>Injecting dependencies allows you to keep dependency resolutions close to the logic that affects them. It can prevent sub-dependencies from leaking throughout the code base, and it simplifies changing the behavior of related components <a href="#openclosed-principle">without modifying those components' classes</a>.</p>
<p>Although many people think of dependency injection frameworks and XML when they hear &quot;dependency injection,&quot; injecting a dependency is usually as simple as passing it as a parameter.</p>
<p>Changing code to use dependency injection only takes a few steps:</p>
<ol type="1">
<li>Move the dependency decision to a higher level component.</li>
<li>Pass the dependency as a parameter to the lower level component.</li>
<li>Remove any sub-dependencies from the lower level component.</li>
</ol>
<p>Injecting dependencies is the simplest way to <a href="#dependency-inversion-principle">invert control</a>.</p>
<section id="uses-15" class="level3">
<h3><a href="#uses-15">Uses</a></h3>
<ul>
<li>Eliminates <a href="#shotgun-surgery">shotgun surgery</a> from leaking sub-dependencies.</li>
<li>Eliminates <a href="#divergent-change">divergent change</a> by allowing runtime composition patterns, such as <a href="#extract-decorator">decorators</a> and strategies.</li>
<li>Makes it easier to avoid subclassing, following <a href="#composition-over-inheritance">composition over inheritance</a>.</li>
<li>Extend existing classes without modifying them, following the <a href="#openclosed-principle">open/closed principle</a>.</li>
<li>Avoids burdening classes with the knowledge of constructing their own dependencies, following the <a href="#single-responsibility-principle">single responsibility principle</a>.</li>
</ul>
</section>
<section id="example-27" class="level3">
<h3><a href="#example-27">Example</a></h3>
<p>In our example applications, users can view a summary of the answers to each question on a survey. Users can select from one of several different summary types to view. For example, they can see the most recent answer to each question, or they can see a percentage breakdown of the answers to a multiple choice question.</p>
<p>The controller passes in the name of the summarizer that the user selected:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> show
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="ot">@summaries</span> = <span class="ot">@survey</span>.summaries_using(summarizer, options)
<span class="kw">end</span>

<span class="kw">private</span>

<span class="kw">def</span> summarizer
  params[<span class="st">:id</span>]
<span class="kw">end</span></code></pre>
<p><code>Survey#summaries_using</code> asks each of its questions for a summary using that summarizer and the given options:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
question.summary_using(summarizer, options)</code></pre>
<p><code>Question#summary_using</code> instantiates the requested summarizer with the requested options, then asks the summarizer to summarize the question:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summary_using(summarizer_name, options)
  summarizer_factory = <span class="st">&quot;Summarizer::</span><span class="ot">#{</span>summarizer_name.classify<span class="ot">}</span><span class="st">&quot;</span>.constantize
  summarizer = summarizer_factory.new(options)
  value = summarizer.summarize(<span class="dv">self</span>)
  <span class="dt">Summary</span>.new(title, value)
<span class="kw">end</span></code></pre>
<p>This is hard to follow and causes <a href="#shotgun-surgery">shotgun surgery</a> because the logic of building the summarizer is in <code>Question</code>, far away from the choice of which summarizer to use, which is in <code>SummariesController</code>. Additionally, the <code>options</code> parameter needs to be passed down several levels so that summarizer-specific options can be provided when building the summarizer.</p>
<p>Let's remedy this by having the controller build the actual summarizer instance. First, we'll move that logic from <code>Question</code> to <code>SummariesController</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> show
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="ot">@summaries</span> = <span class="ot">@survey</span>.summaries_using(summarizer, options)
<span class="kw">end</span>

<span class="kw">private</span>

<span class="kw">def</span> summarizer
  summarizer_name = params[<span class="st">:id</span>]
  summarizer_factory = <span class="st">&quot;Summarizer::</span><span class="ot">#{</span>summarizer_name.classify<span class="ot">}</span><span class="st">&quot;</span>.constantize
  summarizer_factory.new(options)
<span class="kw">end</span></code></pre>
<p>Then, we'll change <code>Question#summary_using</code> to take an instance instead of a name:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summary_using(summarizer, options)
  value = summarizer.summarize(<span class="dv">self</span>)
  <span class="dt">Summary</span>.new(title, value)
<span class="kw">end</span></code></pre>
<p>That <code>options</code> argument is no longer necessary because it was only used to build the summarizer—which is now handled by the controller. Let's remove it:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summary_using(summarizer)
  value = summarizer.summarize(<span class="dv">self</span>)
  <span class="dt">Summary</span>.new(title, value)
<span class="kw">end</span></code></pre>
<p>We also don't need to pass it from <code>Survey</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
question.summary_using(summarizer)</code></pre>
<p>This interaction has already improved, because the <code>options</code> argument is no longer uselessly passed around through two models. It's only used in the controller where the summarizer instance is built. Building the summarizer in the controller is appropriate, because the controller knows the name of the summarizer we want to build, as well as which options are used when building it.</p>
<p>Now that we're using dependency injection, we can take this even further.</p>
<p>By default, in order to prevent the summary from influencing a user's own answers, users don't see summaries for questions they haven't answered yet. Users can click a link to override this decision and view the summary for every question.</p>
<p>The information that determines whether or not to hide unanswered questions lives in the controller:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> constraints
  <span class="kw">if</span> include_unanswered?
    {}
  <span class="kw">else</span>
    { answered_by: current_user }
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>However, this information is passed into <code>Survey#summaries_using</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="ot">@summaries</span> = <span class="ot">@survey</span>.summaries_using(summarizer, options)</code></pre>
<p><code>Survey#summaries_using</code> decides whether to hide the answer to each question based on that setting:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
  <span class="kw">def</span> summaries_using(summarizer, options = {})
    questions.map <span class="kw">do</span> |question|
      summary_or_hidden_answer(summarizer, question, options)
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> summary_or_hidden_answer(summarizer, question, options)
    <span class="kw">if</span> hide_unanswered_question?(question, options[<span class="st">:answered_by</span>])
      hide_answer_to_question(question)
    <span class="kw">else</span>
      question.summary_using(summarizer)
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">def</span> hide_unanswered_question?(question, answered_by)
    answered_by &amp;&amp; !question.answered_by?(answered_by)
  <span class="kw">end</span>

  <span class="kw">def</span> hide_answer_to_question(question)
    <span class="dt">Summary</span>.new(question.title, <span class="dt">NO_ANSWER</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Again, the decision is far away from the dependent behavior.</p>
<p>We can combine our dependency injection with a <a href="#extract-decorator">decorator</a> to remove the duplicate decision:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">class</span> <span class="dt">UnansweredQuestionHider</span>
  <span class="dt">NO_ANSWER</span> = <span class="st">&quot;You haven't answered this question&quot;</span>.freeze

  <span class="kw">def</span> initialize(summarizer, user)
    <span class="ot">@summarizer</span> = summarizer
    <span class="ot">@user</span> = user
  <span class="kw">end</span>

  <span class="kw">def</span> summarize(question)
    <span class="kw">if</span> hide_unanswered_question?(question)
      <span class="dt">NO_ANSWER</span>
    <span class="kw">else</span>
      <span class="ot">@summarizer</span>.summarize(question)
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> hide_unanswered_question?(question)
    !question.answered_by?(<span class="ot">@user</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>We'll decide whether or not to decorate the base summarizer in our controller:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> decorated_summarizer
  <span class="kw">if</span> include_unanswered?
    summarizer
  <span class="kw">else</span>
    <span class="dt">UnansweredQuestionHider</span>.new(summarizer, current_user)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now, the decision of whether or not to hide answers is completely removed from <code>Survey</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer)
  questions.map <span class="kw">do</span> |question|
    question.summary_using(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>For more explanation of using decorators, as well as step-by-step instructions for how to introduce them, see the <a href="#extract-decorator">Extract Decorator</a> chapter.</p>
</section>
<section id="drawbacks-5" class="level3">
<h3><a href="#drawbacks-5">Drawbacks</a></h3>
<p>Injecting dependencies in our example made each class—<code>SummariesController</code>, <code>Survey</code>, <code>Question</code> and <code>UnansweredQuestionHider</code>—easier to understand as a unit. However, it's now difficult to understand what kind of summaries will be produced just by looking at <code>Survey</code> or <code>Question</code>. You need to follow the stack up to <code>SummariesController</code> to understand the dependencies and then look at each class to understand how they're used.</p>
<p>In this case, we believe that using dependency injection resulted in an overall win for readability and flexibility. However, it's important to remember that the further you move a dependency's resolution from its use, the harder it is to figure out what's actually being used in lower level components.</p>
<p>In our example, there isn't an easy way to know which class will be instantiated for the <code>summarizer</code> parameter to <code>Question#summary_using</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> summary_using(summarizer)
  value = summarizer.summarize(<span class="dv">self</span>)
  <span class="dt">Summary</span>.new(title, value)
<span class="kw">end</span></code></pre>
<p>In our case, that will be one of <code>Summarizer::Breakdown</code>, <code>Summarizer::MostRecent</code> or <code>Summarizer::UserAnswer</code>, or a <code>UnansweredQuestionHider</code> that decorates one of the above. Developers will need to trace back up through <code>Survey</code> to <code>SummariesController</code> to gather all the possible implementations.</p>
</section>
<section id="next-steps-15" class="level3">
<h3><a href="#next-steps-15">Next Steps</a></h3>
<ul>
<li>When pulling dependency resolution up into a higher level class, check that class to make sure it doesn't become a <a href="#large-class">large class</a> because of all the logic surrounding dependency resolution.</li>
<li>If a class is suffering from <a href="#divergent-change">divergent change</a> because of new or modified dependencies, try moving dependency resolution further up the stack to a container class whose sole responsibility is managing dependencies.</li>
<li>If methods contain <a href="#long-parameter-list">long parameter lists</a>, consider wrapping up several dependencies in a <a href="#introduce-parameter-object">parameter object</a> or facade.</li>
</ul>
</section>
</section>
<section id="replace-subclasses-with-strategies" class="level1">
<h1><a href="#replace-subclasses-with-strategies">Replace Subclasses with Strategies</a></h1>
<p>Subclasses are a common method of achieving reuse and polymorphism, but inheritance has its drawbacks. See <a href="#composition-over-inheritance">composition over inheritance</a> for reasons why you might decide to avoid an inheritance-based model.</p>
<p>During this refactoring, we will replace the subclasses with individual strategy classes. Each strategy class will implement a common interface. The original base class is promoted from an abstract class to the composition root, which composes the strategy classes.</p>
<p>This allows for smaller interfaces, stricter separation of concerns and easier testing. It also makes it possible to swap out part of the structure, which, in an inheritance-based model, would require converting to a new type.</p>
<p>When applying this refactoring to an <code>ActiveRecord::Base</code> subclass, <a href="#single-table-inheritance-sti">STI</a> is removed, often in favor of a polymorphic association.</p>
<section id="uses-16" class="level3">
<h3><a href="#uses-16">Uses</a></h3>
<ul>
<li>Eliminates <a href="#large-class">large classes</a> by splitting up a bloated base class.</li>
<li>Converts <a href="#single-table-inheritance-sti">STI</a> to a composition-based scheme.</li>
<li>Makes it easier to change part of the structure by separating the parts that change from the parts that don't.</li>
</ul>
</section>
<section id="example-28" class="level3">
<h3><a href="#example-28">Example</a></h3>
<p>The <code>switch_to</code> method on <code>Question</code> changes the question to a new type. Any necessary attributes for the new subclass are provided to the <code>attributes</code> method.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> switch_to(type, new_attributes)
  attributes = <span class="dv">self</span>.attributes.merge(new_attributes)
  new_question = type.constantize.new(attributes.except(<span class="st">'id'</span>, <span class="st">'type'</span>))
  new_question.id = id

  <span class="kw">begin</span>
    <span class="dt">Question</span>.transaction <span class="kw">do</span>
      destroy
      new_question.save!
    <span class="kw">end</span>
  <span class="kw">rescue</span> <span class="dt">ActiveRecord</span>::<span class="dt">RecordInvalid</span>
  <span class="kw">end</span>

  new_question
<span class="kw">end</span></code></pre>
<p>Using inheritance makes changing question types awkward for a number of reasons:</p>
<ul>
<li>You can't actually change the class of an instance in Ruby, so you need to return the instance of the new class.</li>
<li>The implementation requires deleting and creating records, but part of the transaction (<code>destroy</code>) must execute before we can validate the new instance. This results in control flow using exceptions.</li>
<li>It's hard to understand why this method is implemented the way it is, so other developers fixing bugs or refactoring in the future will have a hard time navigating it.</li>
</ul>
<p>We can make this operation easier by using composition instead of inheritance.</p>
<p>This is a difficult change that becomes larger as more behavior is added to the inheritance tree. We can make the change easier by breaking it down into smaller steps, ensuring that the application is in a fully functional state with passing tests after each change. This allows us to debug in smaller sessions and create safe checkpoint commits that we can retreat to if something goes wrong.</p>
<section id="use-extract-class-to-extract-non-railsy-methods-from-subclasses" class="level4">
<h4><a href="#use-extract-class-to-extract-non-railsy-methods-from-subclasses">Use Extract Class to Extract Non-Railsy Methods from Subclasses</a></h4>
<p>The easiest way to start is by extracting a strategy class from each subclass and moving (and delegating) as many methods as you can to the new class. There's some class-level wizardry that goes on in some Rails features, like associations, so let's start by moving simple, instance-level methods that aren't part of the framework.</p>
<p>Let's start with a simple subclass: <code>OpenQuestion.</code></p>
<p>Here's the <code>OpenQuestion</code> class using an STI model:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_question.rb</span>
<span class="kw">class</span> <span class="dt">OpenQuestion</span> &lt; <span class="dt">Question</span>
  <span class="kw">def</span> score(text)
    <span class="dv">0</span>
  <span class="kw">end</span>

  <span class="kw">def</span> breakdown
    text_from_ordered_answers = answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>)
    text_from_ordered_answers.join(<span class="st">', '</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>We can start by creating a new strategy class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">OpenSubmittable</span>
<span class="kw">end</span></code></pre>
<p>When switching from inheritance to composition, you need to add a new word to the application's vocabulary. Before, we had questions, and different subclasses of questions handled the variations in behavior and data. Now, we're switching to a model where there's only one question class, and the question will compose <em>something</em> that will handle the variations. In our case, that <em>something</em> is a &quot;submittable.&quot; In our new model, each question is just a question, and every question composes a submittable that decides how the question can be submitted. Thus, our first extracted class is called <code>OpenSubmittable,</code> extracted from <code>OpenQuestion.</code></p>
<p>Let's move our first method over to <code>OpenSubmittable</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_submittable.rb</span>
<span class="kw">class</span> <span class="dt">OpenSubmittable</span>
  <span class="kw">def</span> score(text)
    <span class="dv">0</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>And change <code>OpenQuestion</code> to delegate to it:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_question.rb</span>
<span class="kw">class</span> <span class="dt">OpenQuestion</span> &lt; <span class="dt">Question</span>
  <span class="kw">def</span> score(text)
    submittable.score(text)
  <span class="kw">end</span>

  <span class="kw">def</span> breakdown
    text_from_ordered_answers = answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>)
    text_from_ordered_answers.join(<span class="st">', '</span>)
  <span class="kw">end</span>

  <span class="kw">def</span> submittable
    <span class="dt">OpenSubmittable</span>.new
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Each question subclass implements the <code>score</code> method, so we repeat this process for <code>MultipleChoiceQuestion</code> and <code>ScaleQuestion</code>. You can see the full change for this step in the <a href="https://github.com/thoughtbot/ruby-science/commit/7747366a12b3f6f21d0008063c5655faba8e4890">example app</a>.</p>
<p>At this point, we've introduced a parallel inheritance hierarchy. During a longer refactor, things may get worse before they get better. This is one of several reasons that it's always best to refactor on a branch, separately from any feature work. We'll make sure that the parallel inheritance hierarchy is removed before merging.</p>
</section>
<section id="pull-up-delegate-method-into-base-class" class="level4">
<h4><a href="#pull-up-delegate-method-into-base-class">Pull Up Delegate Method into Base Class</a></h4>
<p>After the first step, each subclass implements a <code>submittable</code> method to build its parallel strategy class. The <code>score</code> method in each subclass simply delegates to its submittable. We can now pull the <code>score</code> method up into the base <code>Question</code> class, completely removing this concern from the subclasses.</p>
<p>First, we add a delegator to <code>Question</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
delegate <span class="st">:score</span>, to: <span class="st">:submittable</span></code></pre>
<p>Then, we remove the <code>score</code> method from each subclass.</p>
<p>You can see this change in full in the <a href="https://github.com/thoughtbot/ruby-science/commit/9c2ddc65e7248bab1f010d8a2c74c8f994a8b26d">example app</a>.</p>
</section>
<section id="move-remaining-common-api-into-strategies" class="level4">
<h4><a href="#move-remaining-common-api-into-strategies">Move Remaining Common API into Strategies</a></h4>
<p>We can now repeat the first two steps for every non-Railsy method that the subclasses implement. In our case, this is just the <code>breakdown</code> method.</p>
<p>The most interesting part of this change is that the <code>breakdown</code> method requires state from the subclasses, so the question is now provided to the submittable:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/multiple_choice_question.rb</span>
<span class="kw">def</span> submittable
  <span class="dt">MultipleChoiceSubmittable</span>.new(<span class="dv">self</span>)
<span class="kw">end</span></code></pre>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/multiple_choice_submittable.rb</span>
<span class="kw">def</span> answers
  <span class="ot">@question</span>.answers
<span class="kw">end</span>

<span class="kw">def</span> options
  <span class="ot">@question</span>.options
<span class="kw">end</span></code></pre>
<p>You can view this change in the <a href="https://github.com/thoughtbot/ruby-science/commit/db3658cd1c4601c07f49a7c666f57c00f5c22ffd">example app</a>.</p>
</section>
<section id="move-remaining-non-railsy-public-methods-into-strategies" class="level4">
<h4><a href="#move-remaining-non-railsy-public-methods-into-strategies">Move Remaining Non-Railsy Public Methods into Strategies</a></h4>
<p>We can take a similar approach for the uncommon API; that is, public methods that are only implemented in one subclass.</p>
<p>First, move the body of the method into the strategy:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/scale_submittable.rb</span>
<span class="kw">def</span> steps
  (<span class="ot">@question</span>.minimum..<span class="ot">@question</span>.maximum).to_a
<span class="kw">end</span></code></pre>
<p>Then, add a delegator. This time, the delegator can live directly on the subclass, rather than the base class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/scale_question.rb</span>
<span class="kw">def</span> steps
  submittable.steps
<span class="kw">end</span></code></pre>
<p>Repeat this step for the remaining public methods that aren't part of the Rails framework. You can see the full change for this step in our <a href="https://github.com/thoughtbot/ruby-science/commit/2bce7f7b0812b417dc41af369d18b83e057419ac">example app</a>.</p>
</section>
<section id="remove-delegators-from-subclasses" class="level4">
<h4><a href="#remove-delegators-from-subclasses">Remove Delegators from Subclasses</a></h4>
<p>Our subclasses now contain only delegators, code to instantiate the submittable, and framework code. Eventually, we want to completely delete these subclasses, so let's start stripping them down. The delegators are easiest to delete, so let's take them on before the framework code.</p>
<p>First, find where the delegators are used:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/multiple_choice_questions/_multiple_choice_question_form.html.erb
<span class="kw">&lt;%=</span> form.fields_for(<span class="st">:options</span>, question.options_for_form) <span class="kw">do</span> <span class="ch">|</span>option_fields<span class="ch">|</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> option_fields.input <span class="st">:text</span>, label: <span class="st">'Option'</span> <span class="kw">%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
<p>And change the code to directly use the strategy instead:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/multiple_choice_questions/_multiple_choice_question_form.html.erb
<span class="kw">&lt;%=</span> form.fields_for(<span class="st">:options</span>, submittable.options_for_form) <span class="kw">do</span> <span class="ch">|</span>option_fields<span class="ch">|</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> option_fields.input <span class="st">:text</span>, label: <span class="st">'Option'</span> <span class="kw">%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
<p>You may need to pass the strategy in where the subclass was used before:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/_form.html.erb
<span class="kw">&lt;%=</span> render(
  <span class="st">&quot;</span><span class="ot">#{</span>question.to_partial_path<span class="ot">}</span><span class="st">_form&quot;</span>,
  submittable: question.submittable,
  form: form
) <span class="kw">%&gt;</span></code></pre>
<p>We can come back to these locations later and see if we need to pass in the question at all.</p>
<p>After fixing the code that uses the delegator, remove the delegator from the subclass. Repeat this process for each delegator until they've all been removed.</p>
<p>You can see how we do this in the <a href="https://github.com/thoughtbot/ruby-science/commit/c7a61dadfed53b9d93b578064d982f22d62f7b8d">example app</a>.</p>
</section>
<section id="instantiate-strategy-directly-from-base-class" class="level4">
<h4><a href="#instantiate-strategy-directly-from-base-class">Instantiate Strategy Directly from Base Class</a></h4>
<p>If you look carefully at the <code>submittable</code> method from each question subclass, you'll notice that it simply instantiates a class based on its own class name and passes itself to the <code>initialize</code> method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_question.rb</span>
<span class="kw">def</span> submittable
  <span class="dt">OpenSubmittable</span>.new(<span class="dv">self</span>)
<span class="kw">end</span></code></pre>
<p>This is a pretty strong convention, so let's apply some <a href="#use-convention-over-configuration">convention over configuration</a> and pull the method up into the base class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> submittable
  submittable_class_name = type.sub(<span class="st">'Question'</span>, <span class="st">'Submittable'</span>)
  submittable_class_name.constantize.new(<span class="dv">self</span>)
<span class="kw">end</span></code></pre>
<p>We can then delete <code>submittable</code> from each of the subclasses.</p>
<p>At this point, the subclasses contain only Rails-specific code, like associations and validations.</p>
<p>You can see the full change in the <a href="https://github.com/thoughtbot/ruby-science/commit/75075985e6050e5c1008010855e75df14547890c">example app</a>.</p>
<p>Also, note that you may want to <a href="#scoping-constantize">scope the <code>constantize</code> call</a> in order to make the strategies easy for developers to discover and close potential security vulnerabilities.</p>
</section>
<section id="a-fork-in-the-road" class="level4">
<h4><a href="#a-fork-in-the-road">A Fork in the Road</a></h4>
<p>At this point, we're faced with a difficult decision. At first glance, it seems as though only associations and validations live in our subclasses, and we could easily move those to our strategy. However, there are two major issues.</p>
<p>First, you can't move the association to a strategy class without making that strategy an <code>ActiveRecord::Base</code> subclass. Associations are deeply coupled with <code>ActiveRecord::Base</code> and they simply won't work in other situations.</p>
<p>Also, one of our submittable strategies has state specific to that strategy. Scale questions have a minimum and maximum. These fields are only used by scale questions, but they're on the questions table. We can't remove this pollution without creating a table for scale questions.</p>
<p>There are two obvious ways to proceed:</p>
<ul>
<li>Continue without making the strategies <code>ActiveRecord::Base</code> subclasses. Keep the association for multiple choice questions and the minimum and maximum for scale questions on the <code>Question</code> class, and use that data from the strategy. This will result in <a href="#divergent-change">divergent change</a> and probably a <a href="#large-class">large class</a> on <code>Question</code>, as every change in the data required for new or existing strategies will require new behavior on <code>Question</code>.</li>
<li>Convert the strategies to <code>ActiveRecord::Base</code> subclasses. Move the association and state specific to strategies to those classes. This involves creating a table for each strategy and adding a polymorphic association to <code>Question.</code> This will avoid polluting the <code>Question</code> class with future strategy changes, but is awkward right now, because the tables for multiple choice questions and open questions would contain no data except the primary key. These tables provide a placeholder for future strategy-specific data, but those strategies may never require any more data and until they do, the tables are a waste of queries and the developer's mental space.</li>
</ul>
<p>In this example, we'll move forward with the second approach, because:</p>
<ul>
<li>It's easier with ActiveRecord. ActiveRecord will take care of instantiating the strategy in most situations if it's an association, and it has special behavior for associations using nested attribute forms.</li>
<li>It's the easiest way to avoid <a href="#divergent-change">divergent change</a> and <a href="#large-class">large classes</a> in a Rails application. Both of these smells can cause problems that are hard to fix if you wait too long.</li>
</ul>
</section>
<section id="convert-strategies-to-activerecord-subclasses" class="level4">
<h4><a href="#convert-strategies-to-activerecord-subclasses">Convert Strategies to ActiveRecord Subclasses</a></h4>
<p>Continuing with our refactor, we'll change each of our strategy classes to inherit from <code>ActiveRecord::Base</code>.</p>
<p>First, simply declare that the class is a child of <code>ActiveRecord::Base</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_submittable.rb</span>
<span class="kw">class</span> <span class="dt">OpenSubmittable</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span></code></pre>
<p>Your tests will complain that the corresponding table doesn't exist, so create it:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># db/migrate/20130131205432_create_open_submittables.rb</span>
<span class="kw">class</span> <span class="dt">CreateOpenSubmittables</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Migration</span>
  <span class="kw">def</span> change
    create_table <span class="st">:open_submittables</span> <span class="kw">do</span> |table|
      table.timestamps null: <span class="dv">false</span>
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Our strategies currently accept the question as a parameter to <code>initialize</code> and assign it as an instance variable. In an <code>ActiveRecord::Base</code> subclass, we don't control <code>initialize</code>, so let's change <code>question</code> from an instance variable to an association and pass a hash:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/open_submittable.rb</span>
<span class="kw">class</span> <span class="dt">OpenSubmittable</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span>
  has_one <span class="st">:question</span>, as: <span class="st">:submittable</span>

  <span class="kw">def</span> breakdown
    text_from_ordered_answers = answers.order(<span class="st">:created_at</span>).pluck(<span class="st">:text</span>)
    text_from_ordered_answers.join(<span class="st">', '</span>)
  <span class="kw">end</span>

  <span class="kw">def</span> score(text)
    <span class="dv">0</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> answers
    question.answers
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> submittable
  submittable_class = type.sub(<span class="st">'Question'</span>, <span class="st">'Submittable'</span>).constantize
  submittable_class.new(question: <span class="dv">self</span>)
<span class="kw">end</span></code></pre>
<p>Our strategies are now ready to use Rails-specific functionality, like associations and validations.</p>
<p>View the full change on <a href="https://github.com/thoughtbot/ruby-science/commit/e4809cd43da76bf1e6b0933040bffd9cc3ea810c">GitHub</a>.</p>
</section>
<section id="introduce-a-polymorphic-association" class="level4">
<h4><a href="#introduce-a-polymorphic-association">Introduce a Polymorphic Association</a></h4>
<p>Now that our strategies are persistable using ActiveRecord, we can use them in a polymorphic association. Let's add the association:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
belongs_to <span class="st">:submittable</span>, polymorphic: <span class="dv">true</span></code></pre>
<p>And add the necessary columns:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># db/migrate/20130131203344_add_submittable_type_and_id_to_questions.rb</span>
<span class="kw">class</span> <span class="dt">AddSubmittableTypeAndIdToQuestions</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Migration</span>
  <span class="kw">def</span> change
    add_column <span class="st">:questions</span>, <span class="st">:submittable_id</span>, <span class="st">:integer</span>
    add_column <span class="st">:questions</span>, <span class="st">:submittable_type</span>, <span class="st">:string</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>We're currently defining a <code>submittable</code> method that overrides the association. Let's change that to a method that will build the association based on the STI type:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> build_submittable
  submittable_class = type.sub(<span class="st">'Question'</span>, <span class="st">'Submittable'</span>).constantize
  <span class="dv">self</span>.submittable = submittable_class.new(question: <span class="dv">self</span>)
<span class="kw">end</span></code></pre>
<p>Previously, the <code>submittable</code> method built the submittable on demand, but now it's persisted in an association and built explicitly. Let's change our controllers accordingly:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
<span class="kw">def</span> build_question
  <span class="ot">@question</span> = type.constantize.new(question_params)
  <span class="ot">@question</span>.build_submittable
  <span class="ot">@question</span>.survey = <span class="ot">@survey</span>
<span class="kw">end</span></code></pre>
<p>View the full change on <a href="https://github.com/thoughtbot/ruby-science/commit/7d6e294ef8d0e427f83710f74448768da80af2d4">GitHub</a>.</p>
</section>
<section id="pass-attributes-to-strategies" class="level4">
<h4><a href="#pass-attributes-to-strategies">Pass Attributes to Strategies</a></h4>
<p>We're persisting the strategy as an association, but the strategies currently don't have any state. We need to change that, since scale submittables need a minimum and maximum.</p>
<p>Let's change our <code>build_submittable</code> method to accept attributes:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> build_submittable(attributes)
  submittable_class = type.sub(<span class="st">'Question'</span>, <span class="st">'Submittable'</span>).constantize
  <span class="dv">self</span>.submittable = submittable_class.new(attributes.merge(question: <span class="dv">self</span>))
<span class="kw">end</span></code></pre>
<p>We can quickly change the invocations to pass an empty hash, and we're back to green.</p>
<p>Next, let's move the <code>minimum</code> and <code>maximum</code> fields over to the <code>scale_submittables</code> table:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># db/migrate/20130131211856_move_scale_question_state_to_scale_submittable.rb</span>
add_column <span class="st">:scale_submittables</span>, <span class="st">:minimum</span>, <span class="st">:integer</span>
add_column <span class="st">:scale_submittables</span>, <span class="st">:maximum</span>, <span class="st">:integer</span></code></pre>
<p>Note that this migration is <a href="https://github.com/thoughtbot/ruby-science/blob/41b49f49706135572a1b907f6a4c9747fb8446bb/example_app/db/migrate/20130131211856_move_scale_question_state_to_scale_submittable.rb">rather lengthy</a>, because we also need to move over the minimum and maximum values for existing questions. The SQL in our example app will work on most databases, but is cumbersome. If you're using PostgreSQL, you can handle the <code>down</code> method easier using an <code>UPDATE FROM</code> statement.</p>
<p>Next, we'll move validations for these attributes over from <code>ScaleQuestion</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/scale_submittable.rb</span>
validates <span class="st">:maximum</span>, presence: <span class="dv">true</span>
validates <span class="st">:minimum</span>, presence: <span class="dv">true</span></code></pre>
<p>And change <code>ScaleSubmittable</code> methods to use those attributes directly, rather than looking for them on <code>question</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/scale_submittable.rb</span>
<span class="kw">def</span> steps
  (minimum..maximum).to_a
<span class="kw">end</span></code></pre>
<p>We can pass those attributes in our form by using <code>fields_for</code> and <code>accepts_nested_attributes_for</code>:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/scale_questions/_scale_question_form.html.erb
<span class="kw">&lt;%=</span> form.fields_for <span class="st">:submittable</span> <span class="kw">do</span> <span class="ch">|</span>submittable_fields<span class="ch">|</span> <span class="kw">-%&gt;</span>
  <span class="kw">&lt;%=</span> submittable_fields.input <span class="st">:minimum</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> submittable_fields.input <span class="st">:maximum</span> <span class="kw">%&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">-%&gt;</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
accepts_nested_attributes_for <span class="st">:submittable</span></code></pre>
<p>In order to make sure the <code>Question</code> fails when its submittable is invalid, we can cascade the validation:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
validates <span class="st">:submittable</span>, associated: <span class="dv">true</span></code></pre>
<p>Now, we just need our controllers to pass the appropriate submittable parameters:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
<span class="kw">def</span> build_question
  <span class="ot">@question</span> = type.constantize.new(question_params)
  <span class="ot">@question</span>.build_submittable(submittable_params)
  <span class="ot">@question</span>.survey = <span class="ot">@survey</span>
<span class="kw">end</span></code></pre>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
<span class="kw">def</span> question_params
  params.
    require(<span class="st">:question</span>).
    permit(<span class="st">:title</span>, <span class="st">:options_attributes</span>)
<span class="kw">end</span>

<span class="kw">def</span> submittable_params
  <span class="kw">if</span> submittable_attributes = params[<span class="st">:question</span>][<span class="st">:submittable_attributes</span>]
    submittable_attributes.permit(<span class="st">:minimum</span>, <span class="st">:maximum</span>)
  <span class="kw">else</span>
    {}
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>All behavior and state is now moved from <code>ScaleQuestion</code> to <code>ScaleSubmittable</code>, and the <code>ScaleQuestion</code> class is completely empty.</p>
<p>You can view the full change in the <a href="https://github.com/thoughtbot/ruby-science/commit/41b49f49706135572a1b907f6a4c9747fb8446bb">example app</a>.</p>
</section>
<section id="move-remaining-railsy-behavior-out-of-subclasses" class="level4">
<h4><a href="#move-remaining-railsy-behavior-out-of-subclasses">Move Remaining Railsy Behavior Out of Subclasses</a></h4>
<p>We can now repeat this process for remaining Rails-specific behavior. In our case, this is the logic to handle the <code>options</code> association for multiple choice questions.</p>
<p>We can move the association and behavior over to the strategy class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/multiple_choice_submittable.rb</span>
has_many <span class="st">:options</span>, foreign_key: <span class="st">:question_id</span>
has_one <span class="st">:question</span>, as: <span class="st">:submittable</span>

accepts_nested_attributes_for <span class="st">:options</span>, reject_if: <span class="st">:all_blank</span></code></pre>
<p>Again, we remove the <code>options</code> method which delegated to <code>question</code> and rely on <code>options</code> being directly available. Then we update the form to use <code>fields_for</code> and move the allowed attributes in the controller from <code>question</code> to <code>submittable</code>.</p>
<p>At this point, every question subclass is completely empty.</p>
<p>You can view the full change in the <a href="https://github.com/thoughtbot/ruby-science/commit/662e50874a377f8050ea2ad1326a7a4e47125f86">example app</a>.</p>
</section>
<section id="backfill-strategies-for-existing-records" class="level4">
<h4><a href="#backfill-strategies-for-existing-records">Backfill Strategies for Existing Records</a></h4>
<p>Now that everything is moved over to the strategies, we need to make sure that submittables exist for every existing question. We can write a quick backfill migration to take care of that:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># db/migrate/20130207164259_backfill_submittables.rb</span>
<span class="kw">class</span> <span class="dt">BackfillSubmittables</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Migration</span>
  <span class="kw">def</span> up
    backfill <span class="st">'open'</span>
    backfill <span class="st">'multiple_choice'</span>
  <span class="kw">end</span>

  <span class="kw">def</span> down
    connection.delete <span class="st">'DELETE FROM open_submittables'</span>
    connection.delete <span class="st">'DELETE FROM multiple_choice_submittables'</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> backfill(type)
    say_with_time <span class="st">&quot;Backfilling </span><span class="ot">#{</span>type<span class="ot">}</span><span class="st">  submittables&quot;</span> <span class="kw">do</span>
      connection.update(&lt;&lt;-<span class="kw">SQL</span><span class="ot">)</span>
<span class="ot">        UPDATE questions</span>
<span class="ot">        SET</span>
<span class="ot">          submittable_id = id,</span>
<span class="ot">          submittable_type = '#{</span>type.camelize<span class="ot">}Submittable'</span>
<span class="ot">        WHERE type = '#{</span>type.camelize<span class="ot">}Question'</span>
<span class="ot">      SQL</span>
<span class="ot">      connection.insert(&lt;&lt;-SQL)</span>
<span class="ot">        INSERT INTO #{</span>type<span class="ot">}_submittables</span>
<span class="ot">          (id, created_at, updated_at)</span>
<span class="ot">        SELECT</span>
<span class="ot">          id, created_at, updated_at</span>
<span class="ot">        FROM questions</span>
<span class="ot">        WHERE questions.type = '#{</span>type.camelize<span class="ot">}Question'</span>
<span class="ot">      SQL</span>
<span class="ot">    end</span>
<span class="ot">  end</span>
<span class="ot">end</span></code></pre>
<p>We don't port over scale questions, because we took care of them in a <a href="https://github.com/thoughtbot/ruby-science/blob/41b49f49706135572a1b907f6a4c9747fb8446bb/example_app/db/migrate/20130131211856_move_scale_question_state_to_scale_submittable.rb">previous migration</a>.</p>
</section>
<section id="pass-the-type-when-instantiating-the-strategy" class="level4">
<h4><a href="#pass-the-type-when-instantiating-the-strategy">Pass the Type When Instantiating the Strategy</a></h4>
<p>At this point, the subclasses are just dead weight. However, we can't delete them just yet. We're relying on the <code>type</code> column to decide what type of strategy to build, and Rails will complain if we have a <code>type</code> column without corresponding subclasses.</p>
<p>Let's remove our dependence on that <code>type</code> column. Accept a <code>type</code> when building the submittable:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> build_submittable(type, attributes)
  submittable_class = type.sub(<span class="st">'Question'</span>, <span class="st">'Submittable'</span>).constantize
  <span class="dv">self</span>.submittable = submittable_class.new(attributes.merge(question: <span class="dv">self</span>))
<span class="kw">end</span></code></pre>
<p>And pass it in when calling:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
<span class="ot">@question</span>.build_submittable(type, submittable_params)</code></pre>
<p><a href="https://github.com/thoughtbot/ruby-science/commit/a3b36db9f0ec2d66e0ec1e7732662732380e6fc8">Full Change</a></p>
</section>
<section id="always-instantiate-the-base-class" class="level4">
<h4><a href="#always-instantiate-the-base-class">Always Instantiate the Base Class</a></h4>
<p>Now we can remove our dependence on the STI subclasses by always building an instance of <code>Question</code>.</p>
<p>In our controller, we change this line:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
<span class="ot">@question</span> = type.constantize.new(question_params)</code></pre>
<p>To this:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
<span class="ot">@question</span> = <span class="dt">Question</span>.new(question_params)</code></pre>
<p>We're still relying on <code>type</code> as a parameter in forms and links to decide what type of submittable to build. Let's change that to <code>submittable_type</code>, which is already available because of our polymorphic association:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/questions_controller.rb</span>
params[<span class="st">:question</span>][<span class="st">:submittable_type</span>]</code></pre>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/questions/_form.html.erb
<span class="kw">&lt;%=</span> form.hidden_field <span class="st">:submittable_type</span> <span class="kw">%&gt;</span></code></pre>
<p>We'll also need to revisit views that rely on <a href="#polymorphic-partials">polymorphic partials</a> based on the question type and change them to rely on the submittable type instead:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"># app/views/surveys/show.html.erb
<span class="kw">&lt;%=</span> render(
  question.submittable,
  submission_fields: submission_fields
) <span class="kw">%&gt;</span></code></pre>
<p>Now we can finally remove our <code>type</code> column entirely:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># db/migrate/20130207214017_remove_questions_type.rb</span>
<span class="kw">class</span> <span class="dt">RemoveQuestionsType</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Migration</span>
  <span class="kw">def</span> up
    remove_column <span class="st">:questions</span>, <span class="st">:type</span>
  <span class="kw">end</span>

  <span class="kw">def</span> down
    add_column <span class="st">:questions</span>, <span class="st">:type</span>, <span class="st">:string</span>

    connection.update(&lt;&lt;-<span class="kw">SQL</span><span class="ot">)</span>
<span class="ot">      UPDATE questions</span>
<span class="ot">      SET type = REPLACE(submittable_type, 'Submittable', 'Question')</span>
<span class="ot">    </span><span class="kw">SQL</span>

    change_column_null <span class="st">:questions</span>, <span class="st">:type</span>, <span class="dv">true</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p><a href="https://github.com/thoughtbot/ruby-science/commit/19ee3047f57807f342cb7cefd1b6589aff15ea6b">Full Change</a></p>
</section>
<section id="remove-subclasses" class="level4">
<h4><a href="#remove-subclasses">Remove Subclasses</a></h4>
<p>Now for a quick, glorious change: those <code>Question</code> subclasses are entirely empty and unused, so we can <a href="https://github.com/thoughtbot/ruby-science/commit/c6f0e545ae9b3da017b3318f2882cb40954213ee">delete them</a>.</p>
<p>This also removes the parallel inheritance hierarchy that we introduced earlier.</p>
<p>At this point, the code is as good as we found it.</p>
</section>
<section id="simplify-type-switching" class="level4">
<h4><a href="#simplify-type-switching">Simplify Type Switching</a></h4>
<p>If you were previously switching from one subclass to another as we did to change question types, you can now greatly simplify that code.</p>
<p>Instead of deleting the old question and cloning it with a merged set of old generic attributes and new specific attributes, you can simply swap in a new strategy for the old one.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/question.rb</span>
<span class="kw">def</span> switch_to(type, attributes)
  old_submittable = submittable
  build_submittable type, attributes

  transaction <span class="kw">do</span>
    <span class="kw">if</span> save
      old_submittable.destroy
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Our new <code>switch_to</code> method is greatly improved:</p>
<ul>
<li>This method no longer needs to return anything, because there's no need to clone. This is nice because <code>switch_to</code> is no longer a mixed command and query method (i.e., it does something and returns something), but simply a command method (i.e., it just does something).</li>
<li>The method no longer needs to delete the old question, and the new submittable is valid before we delete the old one. This means we no longer need to use exceptions for control flow.</li>
<li>It's simpler and its code is obvious, so other developers will have no trouble refactoring or fixing bugs.</li>
</ul>
<p>You can see the full change that resulted in our new method in the <a href="https://github.com/thoughtbot/ruby-science/commit/5f4a14ff6c43bf5b846d1c58d7509861c6fe3ac1">example app</a>.</p>
</section>
<section id="conclusion" class="level4">
<h4><a href="#conclusion">Conclusion</a></h4>
<p>Our new, composition-based model is improved in a number of ways:</p>
<ul>
<li>It's easy to change types.</li>
<li>Each submittable is easy to use independently of its question, reducing coupling.</li>
<li>There's a clear boundary in the API for questions and submittables, making it easier to test—and less likely that concerns leak between the two.</li>
<li>Shared behavior happens via composition, making it less likely that the base class will become a <a href="#large-class">large class</a>.</li>
<li>It's easy to add new state without effecting other types, because strategy-specific state is stored on a table for that strategy.</li>
</ul>
<p>You can view the entire refactor with all steps combined in the <a href="https://github.com/thoughtbot/ruby-science/compare/4939d3e3c539c5caaa36400d75258cc3f3f4e7d8...5f4a14ff6c43bf5b846d1c58d7509861c6fe3ac1">example app</a> to get an idea of what changed at the macro level.</p>
<p>This is a difficult transition to make, and the more behavior and data that you shove into an inheritance scheme, the harder it becomes. Regarding situations in which <a href="#single-table-inheritance-sti">STI</a> is not significantly easier than using a polymorphic relationship, it's better to start with composition. STI provides few advantages over composition, and it's easier to merge models than to split them.</p>
</section>
</section>
<section id="drawbacks-6" class="level3">
<h3><a href="#drawbacks-6">Drawbacks</a></h3>
<p>Our application also got worse in a number of ways:</p>
<ul>
<li>We introduced a new word into the application vocabulary. This can increase understanding of a complex system, but vocabulary overload makes simpler systems unnecessarily hard to learn.</li>
<li>We now need two queries to get a question's full state, and we'll need to query up to four tables to get information about a set of questions.</li>
<li>We introduced useless tables for two of our question types. This will happen whenever you use ActiveRecord to back a strategy without state.</li>
<li>We increased the overall complexity of the system. In this case, it may have been worth it, because we reduced the complexity per component. However, it's worth keeping an eye on.</li>
</ul>
<p>Before performing a large change like this, try to imagine what currently difficult changes will be easier to make in the new version.</p>
<p>After performing a large change, keep track of difficult changes you make. Would they have been easier in the old version?</p>
<p>Answering these questions will increase your ability to judge whether or not to use composition or inheritance in future situations.</p>
</section>
<section id="next-steps-16" class="level3">
<h3><a href="#next-steps-16">Next Steps</a></h3>
<ul>
<li>Check the extracted strategy classes to make sure they don't have <a href="#feature-envy">feature envy</a> related to the original base class. You may want to use <a href="#move-method">move method</a> to move methods between strategies and the root class.</li>
<li>Check the extracted strategy classes for <a href="#duplicated-code">duplicated code</a> introduced while splitting up the base class. Use <a href="#extract-method">extract method</a> or <a href="#extract-class">extract class</a> to extract common behavior.</li>
</ul>
</section>
</section>
<section id="replace-mixin-with-composition" class="level1">
<h1><a href="#replace-mixin-with-composition">Replace Mixin with Composition</a></h1>
<p>Mixins are one of two mechanisms for inheritance in Ruby. This refactoring provides safe steps for cleanly removing mixins that have become troublesome.</p>
<p>Removing a mixin in favor of composition involves the following steps:</p>
<ul>
<li>Extract a class for the mixin.</li>
<li>Compose and delegate to the extracted class from each mixed in method.</li>
<li>Replace references to mixed in methods with references to the composed class.</li>
<li>Remove the mixin.</li>
</ul>
<section id="uses-17" class="level3">
<h3><a href="#uses-17">Uses</a></h3>
<ul>
<li>Liberates business logic trapped in mixins.</li>
<li>Eliminates name clashes from multiple mixins.</li>
<li>Makes methods in the mixins easier to test.</li>
</ul>
</section>
<section id="example-29" class="level3">
<h3><a href="#example-29">Example</a></h3>
<p>In our example applications, invitations can be delivered either by email or private message (to existing users). Each invitation method is implemented in its own class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/message_inviter.rb</span>
<span class="kw">class</span> <span class="dt">MessageInviter</span> &lt; <span class="dt">AbstractController</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">Inviter</span>

  <span class="kw">def</span> initialize(invitation, recipient)
    <span class="ot">@invitation</span> = invitation
    <span class="ot">@recipient</span> = recipient
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Message</span>.create!(
      recipient: <span class="ot">@recipient</span>,
      sender: <span class="ot">@invitation</span>.sender,
      body: render_message_body
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/email_inviter.rb</span>
<span class="kw">class</span> <span class="dt">EmailInviter</span> &lt; <span class="dt">AbstractController</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">Inviter</span>

  <span class="kw">def</span> initialize(invitation)
    <span class="ot">@invitation</span> = invitation
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Mailer</span>.invitation_notification(<span class="ot">@invitation</span>, render_message_body).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The logic to generate the invitation message is the same regardless of the delivery mechanism, so this behavior has been extracted.</p>
<p>It's currently extracted using a mixin:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/inviter.rb</span>
<span class="kw">module</span> <span class="dt">Inviter</span>
  extend <span class="dt">ActiveSupport</span>::<span class="dt">Concern</span>

  included <span class="kw">do</span>
    <span class="kw">include</span> <span class="dt">AbstractController</span>::<span class="dt">Rendering</span>
    <span class="kw">include</span> <span class="dt">Rails</span>.application.routes.url_helpers

    <span class="dv">self</span>.view_paths = <span class="st">'app/views'</span>
    <span class="dv">self</span>.default_url_options = <span class="dt">ActionMailer</span>::<span class="dt">Base</span>.default_url_options
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> render_message_body
    render template: <span class="st">'invitations/message'</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Let's replace this mixin with a composition.</p>
<p>First, we'll <a href="#extract-class">extract a new class</a> for the mixin:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation_message.rb</span>
<span class="kw">class</span> <span class="dt">InvitationMessage</span> &lt; <span class="dt">AbstractController</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">AbstractController</span>::<span class="dt">Rendering</span>
  <span class="kw">include</span> <span class="dt">Rails</span>.application.routes.url_helpers

  <span class="dv">self</span>.view_paths = <span class="st">'app/views'</span>
  <span class="dv">self</span>.default_url_options = <span class="dt">ActionMailer</span>::<span class="dt">Base</span>.default_url_options

  <span class="kw">def</span> initialize(invitation)
    <span class="ot">@invitation</span> = invitation
  <span class="kw">end</span>

  <span class="kw">def</span> body
    render template: <span class="st">'invitations/message'</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This class contains all the behavior that formerly resided in the mixin. In order to keep everything working, we'll compose and delegate to the extracted class from the mixin:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/inviter.rb</span>
<span class="kw">module</span> <span class="dt">Inviter</span>
  <span class="kw">private</span>

  <span class="kw">def</span> render_message_body
    <span class="dt">InvitationMessage</span>.new(<span class="ot">@invitation</span>).body
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<p>Next, we can replace references to the mixed in methods (<code>render_message_body</code> in this case) with direct references to the composed class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/message_inviter.rb</span>
<span class="kw">class</span> <span class="dt">MessageInviter</span>
  <span class="kw">def</span> initialize(invitation, recipient)
    <span class="ot">@invitation</span> = invitation
    <span class="ot">@recipient</span> = recipient
    <span class="ot">@body</span> = <span class="dt">InvitationMessage</span>.new(<span class="ot">@invitation</span>).body
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Message</span>.create!(
      recipient: <span class="ot">@recipient</span>,
      sender: <span class="ot">@invitation</span>.sender,
      body: <span class="ot">@body</span>
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/email_inviter.rb</span>
<span class="kw">class</span> <span class="dt">EmailInviter</span>
  <span class="kw">def</span> initialize(invitation)
    <span class="ot">@invitation</span> = invitation
    <span class="ot">@body</span> = <span class="dt">InvitationMessage</span>.new(<span class="ot">@invitation</span>).body
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Mailer</span>.invitation_notification(<span class="ot">@invitation</span>, <span class="ot">@body</span>).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>In our case, there was only one method to move. If your mixin has multiple methods, it's best to move them one at a time.</p>
<p>Once every reference to a mixed in method is replaced, you can remove the mixed in method. Once every mixed in method is removed, you can remove the mixin entirely.</p>
</section>
<section id="next-steps-17" class="level3">
<h3><a href="#next-steps-17">Next Steps</a></h3>
<ul>
<li><a href="#inject-dependencies">Inject dependencies</a> to <a href="#dependency-inversion-principle">invert control</a> and allow the composing classes to use different implementations for the composed class.</li>
<li>Check the composing class for <a href="#feature-envy">feature envy</a> of the extracted class. Tight coupling is common between mixin methods and host methods, so you may need to use <a href="#move-method">move method</a> a few times to get the balance right.</li>
</ul>
</section>
</section>
<section id="replace-callback-with-method" class="level1">
<h1><a href="#replace-callback-with-method">Replace Callback with Method</a></h1>
<p>If your models are hard to use and change because their persistence logic is coupled with business logic, one way to loosen things up is by replacing <a href="#callback">callbacks</a>.</p>
<section id="uses-18" class="level3">
<h3><a href="#uses-18">Uses</a></h3>
<ul>
<li>Reduces coupling of persistence logic with business logic.</li>
<li>Makes it easier to extract concerns from models.</li>
<li>Fixes bugs from accidentally triggered callbacks.</li>
<li>Fixes bugs from callbacks with side effects when transactions roll back.</li>
</ul>
</section>
<section id="steps-1" class="level3">
<h3><a href="#steps-1">Steps</a></h3>
<ul>
<li>Use <a href="#extract-method">extract method</a> if the callback is an anonymous block.</li>
<li>Promote the callback method to a public method if it's private.</li>
<li>Call the public method explicitly, rather than relying on <code>save</code> and callbacks.</li>
</ul>
<p></p>
</section>
<section id="example-30" class="level3">
<h3><a href="#example-30">Example</a></h3>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> deliver_invitations
  recipients.map <span class="kw">do</span> |recipient_email|
    <span class="dt">Invitation</span>.create!(
      survey: survey,
      sender: sender,
      recipient_email: recipient_email,
      status: <span class="st">'pending'</span>,
      message: <span class="ot">@message</span>
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
after_create <span class="st">:deliver</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">private</span>

<span class="kw">def</span> deliver
  <span class="dt">Mailer</span>.invitation_notification(<span class="dv">self</span>).deliver
<span class="kw">end</span></code></pre>
<p>In the above code, the <code>SurveyInviter</code> is simply creating <code>Invitation</code> records, and the actual delivery of the invitation email is hidden behind <code>Invitation.create!</code> via a callback.</p>
<p>If one of several invitations fails to save, the user will see a 500 page, but some of the invitations will already have been saved and delivered. The user will be unable to tell which invitations were sent.</p>
<p>Because delivery is coupled with persistence, there's no way to make sure that all the invitations are saved before starting to deliver emails.</p>
<p>Let's make the callback method public so that it can be called from <code>SurveyInviter</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">def</span> deliver
  <span class="dt">Mailer</span>.invitation_notification(<span class="dv">self</span>).deliver
<span class="kw">end</span>

<span class="kw">private</span></code></pre>
<p>Then remove the <code>after_create</code> line to detach the method from persistence.</p>
<p>Now we can split invitations into separate persistence and delivery phases:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> deliver_invitations
  create_invitations.each(&amp;<span class="st">:deliver</span>)
<span class="kw">end</span>

<span class="kw">def</span> create_invitations
  <span class="dt">Invitation</span>.transaction <span class="kw">do</span>
    recipients.map <span class="kw">do</span> |recipient_email|
      <span class="dt">Invitation</span>.create!(
        survey: survey,
        sender: sender,
        recipient_email: recipient_email,
        status: <span class="st">'pending'</span>,
        message: <span class="ot">@message</span>
      )
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>If any of the invitations fail to save, the transaction will roll back. Nothing will be committed and no messages will be delivered.</p>
</section>
<section id="next-steps-18" class="level3">
<h3><a href="#next-steps-18">Next Steps</a></h3>
<ul>
<li>Find other instances where the model is saved, to make sure that the extracted method doesn't need to be called.</li>
</ul>
</section>
</section>
<section id="use-convention-over-configuration" class="level1">
<h1><a href="#use-convention-over-configuration">Use Convention Over Configuration</a></h1>
<p>Ruby's meta-programming allows us to avoid boilerplate code and duplication by relying on conventions for class names, file names and directory structure. Although depending on class names can be constricting in some situations, careful use of conventions will make your applications less tedious and more bug-proof.</p>
<section id="uses-19" class="level3">
<h3><a href="#uses-19">Uses</a></h3>
<ul>
<li>Eliminates <a href="#case-statement">case statements</a> by finding classes by name.</li>
<li>Eliminates <a href="#shotgun-surgery">shotgun surgery</a> by removing the need to register or configure new strategies and services.</li>
<li>Eliminates <a href="#duplicated-code">duplicated code</a> by removing manual associations from identifiers to class names.</li>
<li>Prevents future duplication, making it easier to <a href="#dry">avoid duplication</a>.</li>
</ul>
<p></p>
</section>
<section id="example-31" class="level3">
<h3><a href="#example-31">Example</a></h3>
<p>This controller accepts an <code>id</code> parameter identifying which summarizer strategy to use and renders a summary of the survey based on the chosen strategy:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">class</span> <span class="dt">SummariesController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="kw">def</span> show
    <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
    <span class="ot">@summaries</span> = <span class="ot">@survey</span>.summarize(summarizer)
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> summarizer
    <span class="kw">case</span> params[<span class="st">:id</span>]
    <span class="kw">when</span> <span class="st">'breakdown'</span>
      <span class="dt">Breakdown</span>.new
    <span class="kw">when</span> <span class="st">'most_recent'</span>
      <span class="dt">MostRecent</span>.new
    <span class="kw">when</span> <span class="st">'your_answers'</span>
      <span class="dt">UserAnswer</span>.new(current_user)
    <span class="kw">else</span>
      raise <span class="st">&quot;Unknown summary type: </span><span class="ot">#{</span>params[<span class="st">:id</span>]<span class="ot">}</span><span class="st">&quot;</span>
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The controller is manually mapping a given strategy name to an object that can perform the strategy with the given name. In most cases, a strategy name directly maps to a class of the same name.</p>
<p>We can use the <code>constantize</code> method from Rails to retrieve a class by name:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby">params[<span class="st">:id</span>].classify.constantize</code></pre>
<p>This will find the <code>MostRecent</code> class from the string <code>&quot;most_recent&quot;</code>, and so on. This means we can rely on a convention for our summarizer strategies: Each named strategy will map to a class implementing that strategy. The controller can <a href="#use-class-as-factory">use the class as an abstract factory</a> and obtain a summarizer.</p>
<p>However, we can't immediately start using <code>constantize</code> in our example, because there's one outlier case: The <code>UserAnswer</code> class is referenced using <code>&quot;your_answers&quot;</code> instead of <code>&quot;user_answer&quot;</code>, and <code>UserAnswer</code> takes different parameters than the other two strategies.</p>
<p>Before refactoring the code to rely on our new convention, let's refactor to obey it. All our names should map directly to class names and each class should accept the same parameters:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> summarizer
  <span class="kw">case</span> params[<span class="st">:id</span>]
  <span class="kw">when</span> <span class="st">'breakdown'</span>
    <span class="dt">Breakdown</span>.new(user: current_user)
  <span class="kw">when</span> <span class="st">'most_recent'</span>
    <span class="dt">MostRecent</span>.new(user: current_user)
  <span class="kw">when</span> <span class="st">'user_answer'</span>
    <span class="dt">UserAnswer</span>.new(user: current_user)
  <span class="kw">else</span>
    raise <span class="st">&quot;Unknown summary type: </span><span class="ot">#{</span>params[<span class="st">:id</span>]<span class="ot">}</span><span class="st">&quot;</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<p>Now that we know we can instantiate any of the summarizer classes the same way, let's extract a method for determining the summarizer class:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> summarizer
  summarizer_class.new(user: current_user)
<span class="kw">end</span>

<span class="kw">def</span> summarizer_class
  <span class="kw">case</span> params[<span class="st">:id</span>]
  <span class="kw">when</span> <span class="st">'breakdown'</span>
    <span class="dt">Breakdown</span>
  <span class="kw">when</span> <span class="st">'most_recent'</span>
    <span class="dt">MostRecent</span>
  <span class="kw">when</span> <span class="st">'user_answer'</span>
    <span class="dt">UserAnswer</span>
  <span class="kw">else</span>
    raise <span class="st">&quot;Unknown summary type: </span><span class="ot">#{</span>params[<span class="st">:id</span>]<span class="ot">}</span><span class="st">&quot;</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The extracted class performs exactly the same logic as <code>constantize</code>, so let's use it:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> summarizer
  summarizer_class.new(user: current_user)
<span class="kw">end</span>

<span class="kw">def</span> summarizer_class
  params[<span class="st">:id</span>].classify.constantize
<span class="kw">end</span></code></pre>
<p>Now we'll never need to change our controller when adding a new strategy; we just add a new class following the naming convention.</p>
</section>
<section id="scoping-constantize" class="level3">
<h3><a href="#scoping-constantize">Scoping <code>constantize</code></a></h3>
<p>Our controller currently takes a string directly from user input (<code>params</code>) and instantiates a class with that name.</p>
<p>There are two issues with this approach that should be fixed:</p>
<ul>
<li>There's no list of available strategies, so a developer would need to perform a complicated search to find the relevant classes.</li>
<li>Without a whitelist, users can make the application instantiate any class they want, by hacking parameters. This can result in security vulnerabilities.</li>
</ul>
<p>We can solve both easily by altering our convention slightly: Scope all the strategy classes within a module.</p>
<p>We change our strategy factory method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> summarizer
  summarizer_class.new(user: current_user)
<span class="kw">end</span>

<span class="kw">def</span> summarizer_class
  params[<span class="st">:id</span>].classify.constantize
<span class="kw">end</span></code></pre>
<p>To:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> summarizer_class
  <span class="st">&quot;Summarizer::</span><span class="ot">#{</span>params[<span class="st">:id</span>].classify<span class="ot">}</span><span class="st">&quot;</span>.constantize
<span class="kw">end</span></code></pre>
<p>With this convention in place, you can find all strategies by just looking in the <code>Summarizer</code> module. In a Rails application, this will be in a <code>summarizer</code> directory by convention.</p>
<p>Users also won't be able to instantiate anything they want by abusing our <code>constantize</code>, because only classes in the <code>Summarizer</code> module are available.</p>
</section>
<section id="drawbacks-7" class="level3">
<h3><a href="#drawbacks-7">Drawbacks</a></h3>
<section id="weak-conventions" class="level4">
<h4><a href="#weak-conventions">Weak Conventions</a></h4>
<p>Conventions are most valuable when they're completely consistent.</p>
<p>The convention is slightly forced in this case because <code>UserAnswer</code> needs different parameters than the other two strategies. This means that we now need to add no-op <code>initializer</code> methods to the other two classes:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/summarizer/breakdown.rb</span>
<span class="kw">class</span> <span class="dt">Summarizer</span>::<span class="dt">Breakdown</span>
  <span class="kw">def</span> initialize(options)
  <span class="kw">end</span>

  <span class="kw">def</span> summarize(question)
    question.breakdown
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This isn't a deal-breaker, but it makes the other classes a little noisier and adds the risk that a developer will waste time trying to remove the unused parameter.</p>
<p>Every compromise made weakens the convention, and having a weak convention is worse than having no convention. If you have to change the convention for every class you add that follows it, try something else.</p>
</section>
<section id="class-oriented-programming" class="level4">
<h4><a href="#class-oriented-programming">Class-Oriented Programming</a></h4>
<p>Another drawback to this solution is that it's entirely class-based, which means you can't assemble strategies at run-time. This means that reuse requires inheritance.</p>
<p>Also, while this class-based approach is convenient when developing an application, it's more likely to cause frustration when writing a library. Forcing developers to pass a class name instead of an object limits the amount of runtime information strategies can use. In our example, only a <code>user</code> was required. When you control both sides of the API, it's fine to assume that this is safe. When writing a library that will interface with other developers' applications, it's better not to rely on class names.</p>
<p></p>
</section>
</section>
</section>
<section id="dry" class="level1">
<h1><a href="#dry">DRY</a></h1>
<p>The DRY principle—short for &quot;don't repeat yourself&quot;—comes from <a href="http://pragprog.com/book/tpp/the-pragmatic-programmer">The Pragmatic Programmer</a>.</p>
<p>This principle states:</p>
<blockquote>
<p>Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.</p>
</blockquote>
<p>Following this principle is one of the best ways to prevent bugs and move faster. Every duplicated piece of knowledge is a bug waiting to happen. Many development techniques are really just ways to prevent and eliminate duplication, and many smells are just ways to detect existing duplication.</p>
<p>When knowledge is duplicated, changing it means making the same change in several places. Leaving duplication introduces a risk that the various duplicate implementations will slowly diverge, making them harder to merge and making it more likely that a bug remains in one or more incarnations after being fixed.</p>
<p>Duplication leads to frustration and paranoia. Rampant duplication is a common reason that developers reach for a grand rewrite.</p>
<section id="duplicated-knowledge-vs.-duplicated-text" class="level2">
<h2><a href="#duplicated-knowledge-vs.-duplicated-text">Duplicated Knowledge vs. Duplicated Text</a></h2>
<p>It's important to understand that this principle states that <em>knowledge</em> should not be repeated; it does not state that <em>text</em> should never be repeated.</p>
<p>For example, this sample does not violate the DRY principle, even though the word &quot;save&quot; is repeated several times:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> sign_up
  <span class="ot">@user</span>.save
  <span class="ot">@account</span>.save
  <span class="ot">@subscription</span>.save
<span class="kw">end</span></code></pre>
<p>However, this code contains duplicated knowledge that could be extracted:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">def</span> sign_up_free
  <span class="ot">@user</span>.save
  <span class="ot">@account</span>.save
  <span class="ot">@trial</span>.save
<span class="kw">end</span>

<span class="kw">def</span> sign_up_paid
  <span class="ot">@user</span>.save
  <span class="ot">@account</span>.save
  <span class="ot">@subscription</span>.save
<span class="kw">end</span></code></pre>
<section id="application" class="level3">
<h3><a href="#application">Application</a></h3>
<p>The following smells may point toward <a href="#duplicated-code">duplicated code</a> and can be avoided by following the DRY principle:</p>
<ul>
<li><a href="#shotgun-surgery">Shotgun surgery</a> caused by changing the same knowledge in several places.</li>
<li><a href="#long-parameter-list">Long parameter lists</a> caused by not encapsulating related properties.</li>
<li><a href="#feature-envy">Feature envy</a> caused by leaking internal knowledge of a class that can be encapsulated and reused.</li>
</ul>
<p>Making behavior easy to reuse is essential to avoiding duplication. Developers won't be tempted to copy and paste something that's easy to reuse through a small, easy to understand class or method. You can use these solutions to make knowledge easier to reuse:</p>
<ul>
<li><a href="#extract-class">Extract classes</a> to encapsulate knowledge, allowing it to be reused.</li>
<li><a href="#extract-method">Extract methods</a> to reuse behavior within a class.</li>
<li><a href="#extract-partial">Extract partials</a> to remove duplication in views.</li>
<li><a href="#extract-validator">Extract validators</a> to encapsulate validations.</li>
<li><a href="#replace-conditional-with-null-object">Replace conditionals with null objects</a> to encapsulate behavior related to nothingness.</li>
<li><a href="#replace-conditional-with-polymorphism">Replace conditionals with polymorphism</a> to make it easy to reuse behavioral branches.</li>
<li><a href="#replace-mixin-with-composition">Replace mixins with composition</a> to make it easy to combine components in new ways.</li>
<li><a href="#use-convention-over-configuration">Use convention over configuration</a> to infer knowledge, making it impossible to duplicate.</li>
</ul>
<p>Applying these techniques before duplication occurs will make it less likely that duplication will occur. To effectively prevent duplication, make knowledge easier to reuse by keeping classes small and focused.</p>
<p>Related principles include the <a href="#law-of-demeter">Law of Demeter</a> and the <a href="#single-responsibility-principle">single responsibility principle</a>.</p>
</section>
</section>
</section>
<section id="single-responsibility-principle" class="level1">
<h1><a href="#single-responsibility-principle">Single Responsibility Principle</a></h1>
<p>The Single Responsibility Principle, often abbreviated as &quot;SRP,&quot; was introduced by Uncle Bob Martin, and states:</p>
<blockquote>
<p>A class should have only one reason to change.</p>
</blockquote>
<p>Classes with fewer responsibilities are more likely to be reusable, easier to understand and faster to test. They are easy to change and require fewer changes after being written.</p>
<p>Although this appears to be a very simple principle, deciding whether or not any two pieces of behavior introduce two reasons to change is difficult, and obeying SRP rigidly can be frustrating.</p>
<section id="reasons-to-change" class="level3">
<h3><a href="#reasons-to-change">Reasons to Change</a></h3>
<p>One of the challenges in identifying reasons to change is deciding what granularity to be concerned with.</p>
<p>In our example application, users can invite their friends to take surveys. When an invitation is sent, we encapsulate that invitation in a basic ActiveRecord subclass:</p>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">class</span> <span class="dt">Invitation</span> &lt; <span class="dt">ActiveRecord</span>::<span class="dt">Base</span>
  <span class="dt">EMAIL_REGEX</span> = <span class="ot">/\A([^@\s]+)@((?:[-a-z0-9]+\.)+[a-z]{2,})\z/i</span>
  <span class="dt">STATUSES</span> =<span class="ot"> %w(</span><span class="st">pending accepted</span><span class="ot">)</span>

  belongs_to <span class="st">:sender</span>, class_name: <span class="st">'User'</span>
  belongs_to <span class="st">:survey</span>

  before_create <span class="st">:set_token</span>

  validates <span class="st">:recipient_email</span>, presence: <span class="dv">true</span>, format: <span class="dt">EMAIL_REGEX</span>
  validates <span class="st">:status</span>, inclusion: { <span class="kw">in</span>: <span class="dt">STATUSES</span> }

  <span class="kw">def</span> to_param
    token
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    body = <span class="dt">InvitationMessage</span>.new(<span class="dv">self</span>).body
    <span class="dt">Mailer</span>.invitation_notification(<span class="dv">self</span>, body).deliver
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> set_token
    <span class="dv">self</span>.token = <span class="dt">SecureRandom</span>.urlsafe_base64
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Everything in this class has something to do with invitations. We could make the blunt assessment that this class obeys SRP, because it will only change when invitation-related functionality changes. However, looking more carefully at how invitations are implemented, several other reasons to change can be identified:</p>
<ul>
<li>The format of invitation tokens changes.</li>
<li>A bug is identified in our validation of email addresses.</li>
<li>We need to deliver invitations using some mechanism other than email.</li>
<li>Invitations need to be persisted in another way, such as in a NoSQL database.</li>
<li>The API for ActiveRecord or ActiveSupport changes during an update.</li>
<li>The application switches from Rails to a new framework.</li>
</ul>
<p>That gives us half a dozen reasons this class might change, leading to the probable conclusion that this class does not follow SRP. So, should this class be refactored?</p>
</section>
<section id="stability" class="level3">
<h3><a href="#stability">Stability</a></h3>
<p>Not all reasons to change are created equal.</p>
<p>As a developer, you can anticipate likely changes based on your experience—or just common sense. For example, attributes and business rules for invitations are likely to change, so we know that this class will change as invitations evolve in the application.</p>
<p>Regular expressions are powerful but tricky beasts, so it's likely that we'll have to adjust our regular expression. It might be nice to encapsulate that somewhere else, such as in a <a href="#extract-validator">custom validator</a>.</p>
<p>It's not always helpful to speculate as to what delivery mechanisms may loom in the distant future, but it's not out of the realm of possibility that we'll need to send messages using an internal private messaging system, or another service like Facebook or Twitter. Therefore, it may be worthwhile to use <a href="#inject-dependencies">dependency injection</a> to remove the details of delivery from this model. This may also make testing easier and make the class easier to understand as a unit, because it will remove distracting details relating to email delivery.</p>
<p>NoSQL databases have their uses, but we have no reason to believe we'll ever need to move these records into another type of database. ActiveRecord has proven to be a safe and steady default choice, so it's probably not worth the effort to protect ourselves against that change.</p>
<p>Some of our business logic is expressed using APIs from libraries that could change, such as validations and relationships. We could write our own adapter to protect ourselves from those changes, but the maintenance burden is unlikely to be worth the benefit, and it will make the code harder to understand, since there will be unnecessary indirection between the model and the framework.</p>
<p>Lastly, we could protect our application against framework changes by preventing any business logic from leaking into the framework classes, such as controllers and ActiveRecord models. Again, this would add a thick layer of indirection to protect against an unlikely change.</p>
<p>However, if you're trying out a new database, object-relational mapper or framework, it may be worth adding some increased protection. The first time you use a new database, you may not be fully confident regarding that decision. Preventing any business logic from mixing with the persistence logic will make it easier to undo that decision and revert to a familiar solution like ActiveRecord in case the new database turns against you.</p>
<p>The less confident you are about a decision, the more you should isolate that decision from the rest of your application.</p>
</section>
<section id="cohesion" class="level2">
<h2><a href="#cohesion">Cohesion</a></h2>
<p>One of the primary goals of SRP is to promote cohesive classes. The more closely related the methods and properties are to each other, the more cohesive a class is.</p>
<p>Classes with high cohesion are easier to understand, because the pieces fit naturally together. They're also easier to change and reuse, because they won't be coupled to any unexpected dependencies.</p>
<p>Following this principle will lead to high cohesion, but it's important to focus on the output of each change made to follow the principle. If you notice an extra responsibility in a class, think about the benefits of extracting that responsibility. If you think noticeably higher cohesion will be the result, charge ahead. If you think it will simply be a way to spend an afternoon, make a note of it and move on.</p>
</section>
<section id="responsibility-magnets" class="level2">
<h2><a href="#responsibility-magnets">Responsibility Magnets</a></h2>
<p>Every application develops a few black holes that like to suck up as much responsibility as possible, slowly turning into <a href="#god-class">God classes</a>.</p>
<p><code>User</code> is a common responsibility magnet. Generally, each application has a focal point in its user interface that sucks up responsibility as well. Our example application's main feature allows users to answer questions on surveys, so <code>Survey</code> is a natural junk drawer for behavior.</p>
<p>It's easy to get sucked into a responsibility magnet by falling prey to &quot;Just-One-More Syndrome.&quot; Whenever you're about to add a new behavior to an existing class, first check the history of that class. If there are previous commits that show developers attempting to pull functionality out of this class, chances are good that it's a responsibility over-eater. Don't feed the problem; add a new class instead.</p>
</section>
<section id="tension-with-tell-dont-ask" class="level2">
<h2><a href="#tension-with-tell-dont-ask">Tension with Tell, Don't Ask</a></h2>
<p>Extracting reasons to change can make it harder to follow <a href="#tell-dont-ask">tell, don't ask</a>.</p>
<p>For example, consider a <code>Purchase</code> model that knows how to charge a user:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">Purchase</span>
  <span class="kw">def</span> charge
    purchaser.charge_credit_card(total_amount)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This method follows <a href="#tell-dont-ask">tell, don't ask</a>, because we can simply tell any <code>Purchase</code> to <code>charge</code>, without examining any state on the <code>Purchase</code>.</p>
<p>However, it violates the SRP, because <code>Purchase</code> has more than one reason to change. If the rules around charging credit cards change or the rules for calculating purchase totals change, this class will have to change.</p>
<p>You can more closely adhere to SRP by extracting a new class for the <code>charge</code> method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">PurchaseProcessor</span>
  <span class="kw">def</span> initialize(purchase, purchaser)
    <span class="ot">@purchase</span> = purchase
    <span class="ot">@purchaser</span> = purchaser
  <span class="kw">end</span>

  <span class="kw">def</span> charge
    <span class="ot">@purchaser</span>.charge_credit_card <span class="ot">@purchase</span>.total_amount
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This class can encapsulate rules around charging credit cards and remain immune to other changes, thus following SRP. However, it now violates <a href="#tell-dont-ask">tell, don't ask</a>, because it must ask the <code>@purchase</code> for its <code>total_amount</code> in order to place the charge.</p>
<p>These two principles are often at odds with each other and you must make a pragmatic decision about which direction works best for your own classes.</p>
<section id="drawbacks-8" class="level3">
<h3><a href="#drawbacks-8">Drawbacks</a></h3>
<p>There are a number of drawbacks to following this principle too rigidly:</p>
<ul>
<li>As outlined above, following this principle may lead to violations of <a href="#tell-dont-ask">tell, don't ask</a>.</li>
<li>This principle causes an increase in the number of classes, potentially leading to <a href="#shotgun-surgery">shotgun surgery</a> and vocabulary overload.</li>
<li>Classes that follow this principle may introduce additional indirection, making it harder to understand high-level behavior by looking at individual classes.</li>
</ul>
</section>
<section id="application-1" class="level3">
<h3><a href="#application-1">Application</a></h3>
<p>If you find yourself fighting any of these smells, you may want to refactor to follow the SRP:</p>
<ul>
<li><a href="#divergent-change">Divergent change</a> doesn't exist in classes that follow this principle.</li>
<li>Classes following this principle are easy to reuse, reducing the likelihood of <a href="#duplicated-code">Duplicated code</a>.</li>
<li><a href="#large-class">Large classes</a> almost certainly have more than one reason to change. Following this principle eliminates most large classes.</li>
</ul>
<p>Code containing these smells may need refactoring before it can follow this principle:</p>
<ul>
<li><a href="#case-statement">Case statements</a> make this principle difficult to follow, as every case statement introduces a new reason to change.</li>
<li><a href="#long-method">Long methods</a> make it harder to extract concerns, as behavior can only be moved once it's encapsulated in a small, cohesive method.</li>
<li><a href="#mixin">Mixins</a>, <a href="#single-table-inheritance-sti">Single-table inheritance</a>, and inheritance in general make it harder to follow this principle, as the boundary between parent and child class responsibilities is always fuzzy.</li>
</ul>
<p>These solutions may be useful on the path towards SRP:</p>
<ul>
<li><a href="#extract-class">Extract classes</a> to move responsibilities to their own class.</li>
<li><a href="#extract-decorator">Extract decorators</a> to layer responsibilities onto existing classes without burdening the class definition with that knowledge.</li>
<li><a href="#extract-validator">Extract validators</a> to prevent classes from changing when validation rules change.</li>
<li><a href="#extract-value-object">Extract value objects</a> to prevent rules about a type like currency or names from leaking into other business logic.</li>
<li><a href="#extract-method">Extract methods</a> to make responsibilities easier to move.</li>
<li><a href="#move-method">Move methods</a> to place methods in a more cohesive environment.</li>
<li><a href="#inject-dependencies">Inject dependencies</a> to relieve classes of the burden of changing with their dependencies.</li>
<li><a href="#replace-mixin-with-composition">Replace mixins with composition</a> to make it easier to isolate concerns.</li>
<li><a href="#replace-subclasses-with-strategies">Replace subclasses with strategies</a> to make variations usable without their base logic.</li>
</ul>
<p>Following <a href="#composition-over-inheritance">composition over inheritance</a> and the <a href="#dependency-inversion-principle">dependency inversion principle</a> may make SRP easier to follow, as those principles make it easier to extract responsibilities. Following this principle will make it easier to follow the <a href="#openclosed-principle">open-closed principle</a> but may introduce violations of <a href="#tell-dont-ask">tell, don't ask</a>.</p>
</section>
</section>
</section>
<section id="tell-dont-ask" class="level1">
<h1><a href="#tell-dont-ask">Tell, Don't Ask</a></h1>
<p>The Tell, Don't Ask principle advises developers to tell objects what they want done, rather than querying objects and making decisions for them.</p>
<p>Consider the following example:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">Order</span>
  <span class="kw">def</span> charge(user)
    <span class="kw">if</span> user.has_valid_credit_card?
      user.charge(total)
    <span class="kw">else</span>
      <span class="dv">false</span>
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This example doesn't follow <a href="#tell-dont-ask">tell, don't ask</a>. It first asks if the user has a valid credit card, and then makes a decision based on the user's state.</p>
<p>In order to follow <a href="#tell-dont-ask">tell, don't ask</a>, we can move this decision into <code>User#charge</code>:</p>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">User</span>
  <span class="kw">def</span> charge(total)
    <span class="kw">if</span> has_valid_credit_card?
      payment_gateway.charge(credit_card, total)
      <span class="dv">true</span>
    <span class="kw">else</span>
      <span class="dv">false</span>
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now <code>Order#charge</code> can simply delegate to <code>User#charge</code>, passing its own relevant state (<code>total</code>):</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">Order</span>
  <span class="kw">def</span> charge(user)
    user.charge(total)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Following this principle has a number of benefits, outlined below.</p>
<section id="encapsulation-of-logic" class="level3">
<h3><a href="#encapsulation-of-logic">Encapsulation of Logic</a></h3>
<p>Following <a href="#tell-dont-ask">tell, don't ask</a> encapsulates the conditions under which an operation can be performed in one place. In the above example, <code>User</code> should know when it makes sense to <code>charge</code>.</p>
</section>
<section id="encapsulation-of-state" class="level3">
<h3><a href="#encapsulation-of-state">Encapsulation of State</a></h3>
<p>Referencing another object's state directly couples two objects together based on what they <em>are</em>, rather than on what they <em>do</em>. By following <a href="#tell-dont-ask">tell, don't ask</a>, we encapsulate state within the object that uses it, exposing only the operations that can be performed based on that state and hiding the state itself within private methods and instance variables.</p>
</section>
<section id="minimal-public-interface" class="level3">
<h3><a href="#minimal-public-interface">Minimal Public Interface</a></h3>
<p>In many cases, following <a href="#tell-dont-ask">tell, don't ask</a> will result in the smallest possible public interface between classes. In the above example, <code>has_valid_credit_card?</code> can now be made private, because it becomes an internal concern encapsulated within <code>User</code>.</p>
<p>Public methods are a liability. Before they can be changed, moved, renamed or removed, you will need to find every consumer class and update each one accordingly.</p>
</section>
<section id="tension-with-modelviewcontroller" class="level2">
<h2><a href="#tension-with-modelviewcontroller">Tension with Model—View—Controller</a></h2>
<p>This principle can be difficult to follow while also following Model—View—Controller (MVC).</p>
<p>Consider a view that uses the above <code>Order</code> model:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"><span class="kw">&lt;%=</span> form_for <span class="ot">@order</span> <span class="kw">do</span> <span class="ch">|</span>form<span class="ch">|</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%</span> <span class="kw">unless</span> current_user.has_valid_credit_card? <span class="kw">%&gt;</span>
    <span class="kw">&lt;%=</span> render <span class="st">'credit_card/fields'</span>, form: form <span class="kw">%&gt;</span>
  <span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">%&gt;</span>
  <span class="co">&lt;!-- Order Fields --&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">%&gt;</span></code></pre>
<p>The view doesn't display the credit card fields if the user already has a valid credit card saved. The view needs to ask the user a question and then change its behavior based on that question, violating <a href="#tell-dont-ask">tell, don't ask</a>.</p>
<p>You could obey <a href="#tell-dont-ask">tell, don't ask</a> by making the user know how to render the credit card form:</p>
<pre class="sourceCode rhtml"><code class="sourceCode rhtml"><span class="kw">&lt;%=</span> form_for <span class="ot">@order</span> <span class="kw">do</span> <span class="ch">|</span>form<span class="ch">|</span> <span class="kw">%&gt;</span>
  <span class="kw">&lt;%=</span> current_user.render_credit_card_form <span class="kw">%&gt;</span>
  <span class="co">&lt;!-- Order Fields --&gt;</span>
<span class="kw">&lt;%</span> <span class="kw">end</span> <span class="kw">%&gt;</span></code></pre>
<p>However, this violates MVC by including view logic in the <code>User</code> model. In this case, it's better to keep the model, view and controller concerns separate and step across the <a href="#tell-dont-ask">tell, don't ask</a> line.</p>
<p>When writing interactions between other models and support classes, though, make sure to give commands whenever possible and avoid deviations in behavior based on another class's state.</p>
<section id="application-2" class="level3">
<h3><a href="#application-2">Application</a></h3>
<p>These smells may be a sign that you should be following <a href="#tell-dont-ask">tell, don't ask</a> more:</p>
<ul>
<li><a href="#feature-envy">Feature envy</a> is frequently a sign that a method or part of a method should be extracted and moved to another class, to reduce the number of questions that method must ask of another object.</li>
<li><a href="#shotgun-surgery">Shotgun surgery</a> may result from state and logic leaks. Consolidating conditionals using <a href="#tell-dont-ask">tell, don't ask</a> may reduce the number of changes required for new functionality.</li>
</ul>
<p>If you find classes with these smells, they may require refactoring before you can follow <a href="#tell-dont-ask">tell, don't ask</a>:</p>
<ul>
<li><a href="#case-statement">Case statements</a> that inflect on methods from another object generally get in the way.</li>
<li><a href="#mixin">Mixins</a> blur the lines between responsibilities, as mixed in methods operate on the state of the objects they're mixed into.</li>
</ul>
<p>If you're trying to refactor classes to follow <a href="#tell-dont-ask">tell, don't ask</a>, these solutions may be useful:</p>
<ul>
<li><a href="#extract-method">Extract method</a> to encapsulate multiple conditions into one.</li>
<li><a href="#move-method">Move method</a> to move methods closer to the state they operate on.</li>
<li><a href="#inline-class">Inline class</a> to remove unnecessary questions between two classes with highly cohesive behavior.</li>
<li><a href="#replace-conditional-with-polymorphism">Replace conditionals with polymorphism</a> to reduce the number of questions being asked around a particular operation.</li>
<li><a href="#replace-conditional-with-null-object">Replace conditionals with null object</a> to remove checks for <code>nil</code>.</li>
</ul>
<p>Many <a href="#law-of-demeter">Law of Demeter</a> violations point toward violations of <a href="#tell-dont-ask">tell, don't ask</a>. Following <a href="#tell-dont-ask">tell, don't ask</a> may lead to violations of the <a href="#single-responsibility-principle">single responsibility principle</a> and the <a href="#openclosed-principle">open/closed principle</a>, since moving operations onto the best class may require modifying an existing class and adding a new responsibility.</p>
</section>
</section>
</section>
<section id="law-of-demeter" class="level1">
<h1><a href="#law-of-demeter">Law of Demeter</a></h1>
<p>The Law of Demeter was developed at Northeastern University. It's named after the Demeter Project, which was named after Demeter, the Greek goddess of the harvest. There is widespread disagreement as to its pronunciation, but the correct pronunciation emphasizes the second syllable; you can trust us on that.</p>
<p>This principle states that:</p>
<blockquote>
<p>A method of an object should invoke only the methods of the following kinds of objects:</p>
<ol type="1">
<li>itself</li>
<li>its parameters</li>
<li>any objects it creates/instantiates</li>
<li>its direct component objects</li>
</ol>
</blockquote>
<p>Like many principles, the Law of Demeter is an attempt to help developers manage dependencies. The law restricts how deeply a method can reach into another object's dependency graph, preventing any one method from becoming tightly coupled to another object's structure.</p>
<section id="multiple-dots" class="level2">
<h2><a href="#multiple-dots">Multiple Dots</a></h2>
<p>The most obvious violation of the Law of Demeter is &quot;multiple dots,&quot; meaning a chain of methods being invoked on each others' return values.</p>
<p>Example:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">User</span>
  <span class="kw">def</span> discounted_plan_price(discount_code)
    coupon = <span class="dt">Coupon</span>.new(discount_code)
    coupon.discount(account.plan.price)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The call to <code>account.plan.price</code> above violates the Law of Demeter by invoking <code>price</code> on the return value of <code>plan</code>. The <code>price</code> method is not a method on <code>User</code>, its parameter <code>discount_code</code>, its instantiated object <code>coupon</code> or its direct component <code>account</code>.</p>
<p>The quickest way to avoid violations of this nature is to delegate the method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">User</span>
  <span class="kw">def</span> discounted_plan_price(discount_code)
    account.discounted_plan_price(discount_code)
  <span class="kw">end</span>
<span class="kw">end</span>

<span class="kw">class</span> <span class="dt">Account</span>
  <span class="kw">def</span> discounted_plan_price(discount_code)
    coupon = <span class="dt">Coupon</span>.new(discount_code)
    coupon.discount(plan.price)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>In a Rails application, you can quickly delegate methods using ActiveSupport's <code>delegate</code> class method:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">User</span>
  delegate <span class="st">:discounted_plan_price</span>, to: <span class="st">:account</span>
<span class="kw">end</span></code></pre>
<p>If you find yourself writing lots of delegators, consider changing the consumer class to take a different object. For example, if you need to delegate numerous <code>User</code> methods to <code>Account</code>, it's possible that the code referencing <code>User</code> should actually reference an instance of <code>Account</code> instead.</p>
</section>
<section id="multiple-assignments" class="level2">
<h2><a href="#multiple-assignments">Multiple Assignments</a></h2>
<p>Law of Demeter violations are often hidden behind multiple assignments.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">User</span>
  <span class="kw">def</span> discounted_plan_price(discount_code)
    coupon = <span class="dt">Coupon</span>.new(discount_code)
    plan = account.plan
    coupon.discount(plan.price)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The above <code>discounted_plan_price</code> method no longer has multiple dots on one line, but it still violates the Law of Demeter, because <code>plan</code> isn't a parameter, instantiated object or direct subcomponent.</p>
</section>
<section id="the-spirit-of-the-law" class="level2">
<h2><a href="#the-spirit-of-the-law">The Spirit of the Law</a></h2>
<p>Although the letter of the Law of Demeter is rigid, its message is broader. The fundamental goal is to avoid over-entangling a method with another object's dependencies.</p>
<p>This means that fixing a violation shouldn't be your objective; removing the problem that <em>caused</em> the violation is a better idea. Here are a few tips to avoid misguided fixes to Law of Demeter violations:</p>
<ul>
<li>Many delegate methods to the same object are an indicator that your object graph may not accurately reflect the real-world relationships they represent.</li>
<li>Delegate methods with prefixes (<code>Post#author_name</code>) are fine, but it's worth a check to see if you can remove the prefix. If not, make sure you didn't actually want a reference to the prefix object (<code>Post#author</code>).</li>
<li>Avoid multiple prefixes for delegate methods, such as <code>User#account_plan_price</code>.</li>
<li>Avoid assigning to instance variables to work around violations.</li>
</ul>
</section>
<section id="objects-vs.-types" class="level2">
<h2><a href="#objects-vs.-types">Objects vs. Types</a></h2>
<p>The version of the Law quoted at the beginning of this chapter is the &quot;object formulation,&quot; from the original paper. The first formulation was expressed in terms of types:</p>
<blockquote>
<p>For all classes C, and for all methods M attached to C, all objects to which M sends a message must be instances of classes associated with the following classes:</p>
<ol type="1">
<li>The argument classes of M (including C).</li>
<li>The instance variable classes of C.</li>
</ol>
<p>(Objects created by M, or by functions or methods which M calls, and objects in global variables are considered as arguments of M.)</p>
</blockquote>
<p>This formulation allows some more freedom when chaining using a fluent syntax. Essentially, it allows chaining as long as each step of the chain returns the same type.</p>
<p>Examples:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># Mocking APIs</span>
user.should_receive(<span class="st">:save</span>).once.and_return(<span class="dv">true</span>)

<span class="co"># Ruby's Enumerable</span>
users.select(&amp;<span class="st">:active?</span>).map(&amp;<span class="st">:name</span>)

<span class="co"># String manipulation</span>
collection_name.singularize.classify.constantize

<span class="co"># ActiveRecord chains</span>
users.active.without_posts.signed_up_this_week</code></pre>
</section>
<section id="duplication" class="level2">
<h2><a href="#duplication">Duplication</a></h2>
<p>The Law of Demeter is related to the <a href="#dry">DRY</a> principle, in that Law of Demeter violations frequently duplicate knowledge of dependencies.</p>
<p>Example:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="kw">class</span> <span class="dt">CreditCardsController</span> &lt; <span class="dt">ApplicationController</span>
  <span class="kw">def</span> charge_for_plan
    <span class="kw">if</span> current_user.account.credit_card.valid?
      price = current_user.account.plan.price
      current_user.account.credit_card.charge price
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>In this example, the knowledge that a user has a credit card through its account is duplicated. That knowledge is declared somewhere in the <code>User</code> and <code>Account</code> classes when the relationship is defined, and knowledge of it then spreads to two more locations in <code>charge_for_plan</code>.</p>
<p>Like most duplication, each instance isn't too harmful; but in aggregate, duplication will slowly make refactoring become impossible.</p>
<section id="application-3" class="level3">
<h3><a href="#application-3">Application</a></h3>
<p>The following smells may cause or result from Law of Demeter violations:</p>
<ul>
<li><a href="#feature-envy">Feature envy</a> from methods that reach through a dependency chain multiple times.</li>
<li><a href="#shotgun-surgery">Shotgun surgery</a> resulting from changes in the dependency chain.</li>
</ul>
<p>You can use these solutions to follow the Law of Demeter:</p>
<ul>
<li><a href="#move-method">Move methods</a> that reach through a dependency to the owner of that dependency.</li>
<li><a href="#inject-dependencies">Inject dependencies</a> so that methods have direct access to the dependencies that they need.</li>
<li><a href="#inline-class">Inline class</a> if it adds hops to the dependency chain without providing enough value.</li>
</ul>
</section>
</section>
</section>
<section id="composition-over-inheritance" class="level1">
<h1><a href="#composition-over-inheritance">Composition Over Inheritance</a></h1>
<p>In class-based object-oriented systems, composition and inheritance are the two primary methods of reusing and assembling components. Composition Over Inheritance suggests that, when there isn't a strong case for using inheritance, developers implement reuse and assembly using composition instead.</p>
<p>Let's look at a simple example implemented using both composition and inheritance. In our example application, users can invite their friends to take surveys. Users can be invited using either an email or an internal private message. Each delivery strategy is implemented using a separate class.</p>
<section id="inheritance" class="level3">
<h3><a href="#inheritance">Inheritance</a></h3>
<p>In the inheritance model, we use an abstract base class called <code>Inviter</code> to implement common invitation-sending logic. We then use <code>EmailInviter</code> and <code>MessageInviter</code> subclasses to implement the delivery details.</p>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/inviter.rb</span>
<span class="kw">class</span> <span class="dt">Inviter</span> &lt; <span class="dt">AbstractController</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">AbstractController</span>::<span class="dt">Rendering</span>
  <span class="kw">include</span> <span class="dt">Rails</span>.application.routes.url_helpers

  <span class="dv">self</span>.view_paths = <span class="st">'app/views'</span>
  <span class="dv">self</span>.default_url_options = <span class="dt">ActionMailer</span>::<span class="dt">Base</span>.default_url_options

  <span class="kw">private</span>

  <span class="kw">def</span> render_message_body
    render template: <span class="st">'invitations/message'</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/email_inviter.rb</span>
<span class="kw">class</span> <span class="dt">EmailInviter</span> &lt; <span class="dt">Inviter</span>
  <span class="kw">def</span> initialize(invitation)
    <span class="ot">@invitation</span> = invitation
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Mailer</span>.invitation_notification(<span class="ot">@invitation</span>, render_message_body).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/message_inviter.rb</span>
<span class="kw">class</span> <span class="dt">MessageInviter</span> &lt; <span class="dt">Inviter</span>
  <span class="kw">def</span> initialize(invitation, recipient)
    <span class="ot">@invitation</span> = invitation
    <span class="ot">@recipient</span> = recipient
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Message</span>.create!(
      recipient: <span class="ot">@recipient</span>,
      sender: <span class="ot">@invitation</span>.sender,
      body: render_message_body
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Note that there is no clear boundary between the base class and the subclasses. The subclasses access reusable behavior by invoking private methods inherited from the base class, like <code>render_message_body</code>.</p>
</section>
<section id="composition" class="level3">
<h3><a href="#composition">Composition</a></h3>
<p>In the composition model, we use a concrete <code>InvitationMessage</code> class to implement common invitation-sending logic. We then use that class from <code>EmailInviter</code> and <code>MessageInviter</code> to reuse the common behavior, and the inviter classes implement delivery details.</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation_message.rb</span>
<span class="kw">class</span> <span class="dt">InvitationMessage</span> &lt; <span class="dt">AbstractController</span>::<span class="dt">Base</span>
  <span class="kw">include</span> <span class="dt">AbstractController</span>::<span class="dt">Rendering</span>
  <span class="kw">include</span> <span class="dt">Rails</span>.application.routes.url_helpers

  <span class="dv">self</span>.view_paths = <span class="st">'app/views'</span>
  <span class="dv">self</span>.default_url_options = <span class="dt">ActionMailer</span>::<span class="dt">Base</span>.default_url_options

  <span class="kw">def</span> initialize(invitation)
    <span class="ot">@invitation</span> = invitation
  <span class="kw">end</span>

  <span class="kw">def</span> body
    render template: <span class="st">'invitations/message'</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/email_inviter.rb</span>
<span class="kw">class</span> <span class="dt">EmailInviter</span>
  <span class="kw">def</span> initialize(invitation)
    <span class="ot">@invitation</span> = invitation
    <span class="ot">@body</span> = <span class="dt">InvitationMessage</span>.new(<span class="ot">@invitation</span>).body
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Mailer</span>.invitation_notification(<span class="ot">@invitation</span>, <span class="ot">@body</span>).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/message_inviter.rb</span>
<span class="kw">class</span> <span class="dt">MessageInviter</span>
  <span class="kw">def</span> initialize(invitation, recipient)
    <span class="ot">@invitation</span> = invitation
    <span class="ot">@recipient</span> = recipient
    <span class="ot">@body</span> = <span class="dt">InvitationMessage</span>.new(<span class="ot">@invitation</span>).body
  <span class="kw">end</span>

  <span class="kw">def</span> deliver
    <span class="dt">Message</span>.create!(
      recipient: <span class="ot">@recipient</span>,
      sender: <span class="ot">@invitation</span>.sender,
      body: <span class="ot">@body</span>
    )
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Note that there is now a clear boundary between the common behavior in <code>InvitationMessage</code> and the variant behavior in <code>EmailInviter</code> and <code>MessageInviter</code>. The inviter classes access reusable behavior by invoking public methods like <code>body</code> on the shared class.</p>
</section>
<section id="dynamic-vs.-static" class="level2">
<h2><a href="#dynamic-vs.-static">Dynamic vs. Static</a></h2>
<p>Although the two implementations are fairly similar, one difference between them is that, in the inheritance model, the components are assembled statically. The composition model, on the other hand, assembles the components dynamically.</p>
<p>Ruby is not a compiled language and everything is evaluated at run-time, so claiming that anything is assembled statically may sound like nonsense. However, there are several ways in which inheritance hierarchies are essentially written in stone, or static:</p>
<ul>
<li>You can't swap out a superclass once it's assigned.</li>
<li>You can't easily add and remove behaviors after an object is instantiated.</li>
<li>You can't inject a superclass as a dependency.</li>
<li>You can't easily access an abstract class's methods directly.</li>
</ul>
<p>On the other hand, everything in a composition model is dynamic:</p>
<ul>
<li>You can easily change out a composed instance after instantiation.</li>
<li>You can add and remove behaviors at any time using decorators, strategies, observers and other patterns.</li>
<li>You can easily inject composed dependencies.</li>
<li>Composed objects aren't abstract, so you can use their methods anywhere.</li>
</ul>
</section>
<section id="dynamic-inheritance" class="level2">
<h2><a href="#dynamic-inheritance">Dynamic Inheritance</a></h2>
<p>There are very few rules in Ruby, so many of the restrictions that apply to inheritance in other languages can be worked around in Ruby. For example:</p>
<ul>
<li>You can reopen and modify classes after they're defined, even while an application is running.</li>
<li>You can extend objects with modules after they're instantiated to add behaviors.</li>
<li>You can call private methods by using <code>send</code>.</li>
<li>You can create new classes at run-time by calling <code>Class.new</code>.</li>
</ul>
<p>These features make it possible to overcome some of the rigidity of inheritance models. However, performing all of these operations is simpler with objects than it is with classes, and doing too much dynamic type definition will make the application harder to understand, by diluting the type system. After all, if none of the classes are ever fully formed, what does a class represent?</p>
</section>
<section id="the-trouble-with-hierarchies" class="level2">
<h2><a href="#the-trouble-with-hierarchies">The Trouble with Hierarchies</a></h2>
<p>Using subclasses introduces a subtle problem into your domain model: It assumes that your models follow a hierarchy; that is, it assumes that your types fall into a tree-like structure.</p>
<p>Continuing with the above example, we have a root type, <code>Inviter</code>, and two subtypes, <code>EmailInviter</code> and <code>MessageInviter</code>. What if we want invitations sent by admins to behave differently than invitations sent by normal users? We can create an <code>AdminInviter</code> class, but what will its superclass be? How will we combine it with <code>EmailInviter</code> and <code>MessageInviter</code>? There's no easy way to combine email, message and admin functionality using inheritance, so you'll end up with a proliferation of conditionals.</p>
<p>Composition, on the other hand, provides several ways out of this mess, such as using a decorator to add admin functionality to the inviter. Once you build objects with a reasonable interface, you can combine them endlessly with minimal modification to the existing class structure.</p>
</section>
<section id="mixins" class="level2">
<h2><a href="#mixins">Mixins</a></h2>
<p>Mixins are Ruby's answer to multiple inheritance.</p>
<p>However, mixins need to be mixed into a class before they can be used. Unless you plan on building dynamic classes at runtime, you'll need to create a class for each possible combination of modules. This will result in a ton of little classes, such as <code>AdminEmailInviter</code>.</p>
<p>Again, composition provides a clean answer to this problem, because you can create as many anonymous combinations of objects as your little heart desires.</p>
<p>Ruby does allow dynamic use of mixins using the <code>extend</code> method. This technique does work, but it has its own complications. Extending an object's type dynamically in this way dilutes the meaning of the word &quot;type,&quot; making it harder to understand what an object is. Additionally, using runtime <code>extend</code> can lead to performance issues in some Ruby implementations.</p>
</section>
<section id="single-table-inheritance" class="level2">
<h2><a href="#single-table-inheritance">Single Table Inheritance</a></h2>
<p>Rails provides a way to persist an inheritance hierarchy, known as <a href="#single-table-inheritance-sti">Single Table Inheritance</a>, often abbreviated as STI. Using STI, a cluster of subclasses is persisted to the same table as the base class. The name of the subclass is also saved on the row, allowing Rails to instantiate the correct subclass when pulling records back out of the database.</p>
<p>Rails also provides a clean way to persist composed structures using polymorphic associations. Using a polymorphic association, Rails will store both the primary key and the class name of the associated object.</p>
<p>Because Rails provides a clean implementation for persisting both inheritance and composition, the fact that you're using ActiveRecord should have little influence on your decision to design using inheritance versus composition.</p>
<section id="drawbacks-9" class="level3">
<h3><a href="#drawbacks-9">Drawbacks</a></h3>
<p>Although composed objects are largely easy to write and assemble, there are situations in which they hurt more than inheritance trees.</p>
<ul>
<li>Inheritance cleanly represents hierarchies. If you really do have a hierarchy of object types, use inheritance.</li>
<li>Subclasses always know what their superclass is, so they're easy to instantiate. If you use composition, you'll need to instantiate at least two objects to get a usable instance: the composing object and the composed object.</li>
<li>Using composition is more abstract, which means that you need a name for the composed object. In our earlier example, all three classes were &quot;inviters&quot; in the inheritance model, but the composition model introduced the &quot;invitation message&quot; concept. Excessive composition can lead to vocabulary overload.</li>
</ul>
</section>
<section id="application-4" class="level3">
<h3><a href="#application-4">Application</a></h3>
<p>If you see these smells in your application, they may be a sign that you should switch some classes from inheritance to composition:</p>
<ul>
<li><a href="#divergent-change">Divergent change</a> caused by frequent leaks into abstract base classes.</li>
<li><a href="#large-class">Large classes</a> acting as abstract base classes.</li>
<li><a href="#mixin">Mixins</a> serving to allow reuse while preserving the appearance of a hierarchy.</li>
</ul>
<p>Classes with these smells may be difficult to transition to a composition model:</p>
<ul>
<li><a href="#duplicated-code">Duplicated code</a> will need to be pulled up into the base class before subclasses can be switched to strategies.</li>
<li><a href="#shotgun-surgery">Shotgun surgery</a> may represent tight coupling between base classes and subclasses, making it more difficult to switch to composition.</li>
</ul>
<p>These solutions will help move from inheritance to composition:</p>
<ul>
<li><a href="#extract-class">Extract classes</a> to liberate private functionality from abstract base classes.</li>
<li><a href="#extract-method">Extract method</a> to make methods smaller and easier to move.</li>
<li><a href="#move-method">Move method</a> to slim down bloated base classes.</li>
<li><a href="#replace-mixin-with-composition">Replace mixins with composition</a> to make it easier to dissolve hierarchies.</li>
<li><a href="#replace-subclasses-with-strategies">Replace subclasses with strategies</a> to implement variations dynamically.</li>
</ul>
<p>After replacing inheritance models with composition, you'll be free to use these solutions to take your code further:</p>
<ul>
<li><a href="#extract-decorator">Extract decorators</a> to make it easy to add behaviors dynamically.</li>
<li><a href="#inject-dependencies">Inject dependencies</a> to make it possible to compose objects in new ways.</li>
</ul>
<p>Following this principle will make it much easier to follow the <a href="#dependency-inversion-principle">dependency inversion principle</a> and the <a href="#openclosed-principle">open/closed principle</a>.</p>
</section>
</section>
</section>
<section id="openclosed-principle" class="level1">
<h1><a href="#openclosed-principle">Open/Closed Principle</a></h1>
<p>The Open/Closed Principle states that:</p>
<p></p>
<blockquote>
<p>Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.</p>
</blockquote>
<p>The purpose of this principle is to make it possible to change or extend the behavior of an existing class without actually modifying the source code to that class.</p>
<p>Making classes extensible in this way has a number of benefits:</p>
<ul>
<li>Every time you modify a class, you risk breaking it, along with all classes that depend on that class. Reducing churn in a class reduces bugs in that class.</li>
<li>Changing the behavior or interface to a class means that you need to update any classes that depend on the old behavior or interface. Allowing per-use extensions to a class eliminates this domino effect.</li>
</ul>
<section id="strategies" class="level2">
<h2><a href="#strategies">Strategies</a></h2>
<p>It may sound appealing to never need to change existing classes again, but achieving this is difficult in practice. Once you've identified an area that keeps changing, there are a few strategies you can use to make it possible to extend without modifications. Let's go through an example with a few of those strategies.</p>
<p>In our example application, we have an <code>Invitation</code> class that can deliver itself to an invited user:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">def</span> deliver
  body = <span class="dt">InvitationMessage</span>.new(<span class="dv">self</span>).body
  <span class="dt">Mailer</span>.invitation_notification(<span class="dv">self</span>, body).deliver
<span class="kw">end</span></code></pre>
<p>However, we need a way to allow users to unsubscribe from these notifications. We have an <code>Unsubscribe</code> model that holds the email addresses of users that don't want to be notified.</p>
<p>The most direct way to add this check is to modify <code>Invitation</code> directly:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">def</span> deliver
  <span class="kw">unless</span> unsubscribed?
    body = <span class="dt">InvitationMessage</span>.new(<span class="dv">self</span>).body
    <span class="dt">Mailer</span>.invitation_notification(<span class="dv">self</span>, body).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>However, that would violate the <a href="#openclosed-principle">open/closed principle</a>. Let's see how we can introduce this change without violating the principle.</p>
<p></p>
<section id="inheritance-1" class="level3">
<h3><a href="#inheritance-1">Inheritance</a></h3>
<p>One of the most common ways to extend an existing class without modifying it is to create a new subclass.</p>
<p>We can use a new subclass to handle unsubscriptions:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unsubscribeable_invitation.rb</span>
<span class="kw">class</span> <span class="dt">UnsubscribeableInvitation</span> &lt; <span class="dt">Invitation</span>
  <span class="kw">def</span> deliver
    <span class="kw">unless</span> unsubscribed?
      <span class="dv">super</span>
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> unsubscribed?
    <span class="dt">Unsubscribe</span>.where(email: recipient_email).exists?
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<p>This can be a little awkward when trying to use the new behavior, though. For example, we need to create an instance of this class, even though we want to save it to the same table as <code>Invitation</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> create_invitations
  <span class="dt">Invitation</span>.transaction <span class="kw">do</span>
    recipients.map <span class="kw">do</span> |recipient_email|
      <span class="dt">UnsubscribeableInvitation</span>.create!(
        survey: survey,
        sender: sender,
        recipient_email: recipient_email,
        status: <span class="st">'pending'</span>,
        message: <span class="ot">@message</span>
      )
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This works adequately for creation, but using the ActiveRecord pattern, we'll end up with an instance of <code>Invitation</code> instead, if we ever reload from the database. That means that inheritance is easiest to use when the class we're extending doesn't require persistence.</p>
<p>Inheritance also requires some <a href="https://github.com/thoughtbot/ruby-science/commit/bf1ba7d2">creativity in unit tests</a> to avoid duplication.</p>
<p></p>
</section>
<section id="decorators" class="level3">
<h3><a href="#decorators">Decorators</a></h3>
<p>Another way to extend an existing class is to write a decorator.</p>
<p>Using Ruby's <code>DelegateClass</code> method, we can quickly create decorators:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unsubscribeable_invitation.rb</span>
<span class="kw">class</span> <span class="dt">UnsubscribeableInvitation</span> &lt; <span class="dt">DelegateClass</span>(<span class="dt">Invitation</span>)
  <span class="kw">def</span> deliver
    <span class="kw">unless</span> unsubscribed?
      <span class="dv">super</span>
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> unsubscribed?
    <span class="dt">Unsubscribe</span>.where(email: recipient_email).exists?
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The implementation is extremely similar to the subclass but it can now be applied at run-time to instances of <code>Invitation</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> deliver_invitations
  create_invitations.each <span class="kw">do</span> |invitation|
    <span class="dt">UnsubscribeableInvitation</span>.new(invitation).deliver
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The unit tests can also be greatly simplified <a href="https://github.com/thoughtbot/ruby-science/blob/9084ee0c/example_app/spec/models/unsubscribeable_invitation_spec.rb">using stubs</a>.</p>
<p>This makes it easier to combine with persistence. However, Ruby's <code>DelegateClass</code> doesn't combine well with ActionPack's polymorphic URLs.</p>
</section>
<section id="dependency-injection" class="level3">
<h3><a href="#dependency-injection">Dependency Injection</a></h3>
<p>This method requires more forethought in the class you want to extend, but classes that follow <a href="#inversion-of-control">inversion of control</a> can inject dependencies to extend classes without modifying them.</p>
<p>We can modify our <code>Invitation</code> class slightly to allow client classes to inject a mailer:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/invitation.rb</span>
<span class="kw">def</span> deliver(mailer)
  body = <span class="dt">InvitationMessage</span>.new(<span class="dv">self</span>).body
  mailer.invitation_notification(<span class="dv">self</span>, body).deliver
<span class="kw">end</span></code></pre>
<p></p>
<p>Now we can write a mailer implementation that checks to see if users are unsubscribed before sending them messages:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/mailers/unsubscribeable_mailer.rb</span>
<span class="kw">class</span> <span class="dt">UnsubscribeableMailer</span>
  <span class="kw">def</span> <span class="dv">self</span>.invitation_notification(invitation, body)
    <span class="kw">if</span> unsubscribed?(invitation)
      <span class="dt">NullMessage</span>.new
    <span class="kw">else</span>
      <span class="dt">Mailer</span>.invitation_notification(invitation, body)
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> <span class="dv">self</span>.unsubscribed?(invitation)
    <span class="dt">Unsubscribe</span>.where(email: invitation.recipient_email).exists?
  <span class="kw">end</span>

  <span class="kw">class</span> <span class="dt">NullMessage</span>
    <span class="kw">def</span> deliver
    <span class="kw">end</span>
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>And we can use dependency injection to substitute it:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey_inviter.rb</span>
<span class="kw">def</span> deliver_invitations
  create_invitations.each <span class="kw">do</span> |invitation|
    invitation.deliver(<span class="dt">UnsubscribeableMailer</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
</section>
</section>
<section id="everything-is-open" class="level2">
<h2><a href="#everything-is-open">Everything is Open</a></h2>
<p>As you've followed along with these strategies, you've probably noticed that although we've found creative ways to avoid modifying <code>Invitation</code>, we've had to modify other classes. When you change or add behavior, you need to change or add it somewhere. You can design your code so that most new or changed behavior takes place by writing a new class, but something, somewhere in the existing code will need to reference that new class.</p>
<p>It's difficult to determine what you should attempt to leave open when writing a class. It's hard to know where to leave extension hooks without anticipating every feature you might ever want to write.</p>
<p>Rather than attempting to guess what will require extension in the future, pay attention as you modify existing code. After each modification, check to see if there's a way you can refactor to make similar extensions possible without modifying the underlying class.</p>
<p>Code tends to change in the same ways over and over, so by making each change easy to apply as you need to make it, you're making the next change easier.</p>
<p></p>
</section>
<section id="monkey-patching" class="level2">
<h2><a href="#monkey-patching">Monkey Patching</a></h2>
<p>As a Ruby developer, you probably know that one quick way to extend a class without changing its source code is to use a monkey patch:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/monkey_patches/invitation_with_unsubscribing.rb</span>
<span class="dt">Invitation</span>.class_eval <span class="kw">do</span>
  alias_method <span class="st">:deliver_unconditionally</span>, <span class="st">:deliver</span>

  <span class="kw">def</span> deliver
    <span class="kw">unless</span> unsubscribed?
      deliver_unconditionally
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> unsubscribed?
    <span class="dt">Unsubscribe</span>.where(email: recipient_email).exists?
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Although monkey patching doesn't literally modify the class's source code, it does modify the existing class. That means that you risk breaking it, and, potentially, all classes that depend on it. Since you're changing the original behavior, you'll also need to update any client classes that depend on the old behavior.</p>
<p>In addition to all the drawbacks of directly modifying the original class, monkey patches also introduce confusion, as developers will need to look in multiple locations to understand the full definition of a class.</p>
<p>In short, monkey patching has most of the drawbacks of modifying the original class without any of the benefits of following the <a href="#openclosed-principle">open/closed principle</a>.</p>
<section id="drawbacks-10" class="level3">
<h3><a href="#drawbacks-10">Drawbacks</a></h3>
<p>Although following the <a href="#openclosed-principle">open/closed principle</a> will make code easier to change, it may make it more difficult to understand. This is because the gained flexibility requires introducing indirection and abstraction. Although all of the three strategies outlined in this chapter are more flexible than the original change, directly modifying the class is the easiest to understand.</p>
<p>This principle is most useful when applied to classes with high reuse and potentially high churn. Applying it everywhere will result in extra work and more obscure code.</p>
</section>
<section id="application-5" class="level3">
<h3><a href="#application-5">Application</a></h3>
<p>If you encounter the following smells in a class, you may want to begin following this principle:</p>
<ul>
<li><a href="#divergent-change">Divergent change</a> caused by a lack of extensibility.</li>
<li><a href="#large-class">Large classes</a> and <a href="#long-method">long methods</a> which can be eliminated by extracting and injecting dependent behavior.</li>
</ul>
<p>You may want to eliminate the following smells if you're having trouble following this principle:</p>
<ul>
<li><a href="#case-statement">Case statements</a> make it hard to obey this principle, as you can't add to the case statement without modifying it.</li>
</ul>
<p>You can use the following solutions to make code more compliant with this principle:</p>
<ul>
<li><a href="#extract-decorator">Extract decorator</a> to extend existing classes without modification.</li>
<li><a href="#inject-dependencies">Inject dependencies</a> to allow future extensions without modification.</li>
</ul>
</section>
</section>
</section>
<section id="dependency-inversion-principle" class="level1">
<h1><a href="#dependency-inversion-principle">Dependency Inversion Principle</a></h1>
<p>The Dependency Inversion Principle, sometimes abbreviated as &quot;DIP,&quot; was created by Uncle Bob Martin.</p>
<p>The principle states:</p>
<blockquote>
<p>A. High-level modules should not depend on low-level modules. Both should depend on abstractions.</p>
<p>B. Abstractions should not depend upon details. Details should depend upon abstractions.</p>
</blockquote>
<p>This is a very technical way of proposing that developers invert control.</p>
<section id="inversion-of-control" class="level2">
<h2><a href="#inversion-of-control">Inversion of Control</a></h2>
<p>Inversion of control is a technique for keeping software flexible. It combines best with small classes with <a href="#single-responsibility-principle">single responsibilities</a>. Inverting control means assigning dependencies at run-time, rather than statically referencing dependencies at each level.</p>
<p>This can be hard to understand as an abstract concept, but it's fairly simple in practice. Let's jump into an example:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer, options = {})
  questions.map <span class="kw">do</span> |question|
    hider = <span class="dt">UnansweredQuestionHider</span>.new(summarizer, options[<span class="st">:answered_by</span>])
    question.summary_using(hider)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> show
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="ot">@summaries</span> = <span class="ot">@survey</span>.summaries_using(summarizer, constraints)
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> constraints
  <span class="kw">if</span> include_unanswered?
    {}
  <span class="kw">else</span>
    { answered_by: current_user }
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>The <code>summaries_using</code> method builds a summary of the answers to each of the survey's questions.</p>
<p>However, we also want to hide the answers to questions that the user has not personally answered, so we <a href="#extract-decorator">decorate</a> the <code>summarizer</code> with an <code>UnansweredQuestionHider</code>. Note that we're statically referencing the concrete, lower-level detail <code>UnansweredQuestionHider</code> from <code>Survey</code> rather than depending on an abstraction.</p>
<p>In the current implementation, the <code>Survey#summaries_using</code> method will need to change whenever something changes about the summaries. For example, hiding the unanswered questions <a href="https://github.com/thoughtbot/ruby-science/commit/d60656aa">requires changes to this method</a>.</p>
<p>Also, note that the conditional logic is spread across several layers. <code>SummariesController</code> decides whether or not to hide unanswered questions. That knowledge is passed into <code>Survey#summaries_using</code>. <code>SummariesController</code> also passes the current user down into <code>Survey#summaries_using</code>, and from there it's passed into <code>UnansweredQuestionHider</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">class</span> <span class="dt">UnansweredQuestionHider</span>
  <span class="dt">NO_ANSWER</span> = <span class="st">&quot;You haven't answered this question&quot;</span>.freeze

  <span class="kw">def</span> initialize(summarizer, user)
    <span class="ot">@summarizer</span> = summarizer
    <span class="ot">@user</span> = user
  <span class="kw">end</span>

  <span class="kw">def</span> summarize(question)
    <span class="kw">if</span> hide_unanswered_question?(question)
      <span class="dt">NO_ANSWER</span>
    <span class="kw">else</span>
      <span class="ot">@summarizer</span>.summarize(question)
    <span class="kw">end</span>
  <span class="kw">end</span>

  <span class="kw">private</span>

  <span class="kw">def</span> hide_unanswered_question?(question)
    <span class="ot">@user</span> &amp;&amp; !question.answered_by?(<span class="ot">@user</span>)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p></p>
<p>We can make future changes like this easier by inverting control:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer)
  questions.map <span class="kw">do</span> |question|
    question.summary_using(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/controllers/summaries_controller.rb</span>
<span class="kw">def</span> show
  <span class="ot">@survey</span> = <span class="dt">Survey</span>.find(params[<span class="st">:survey_id</span>])
  <span class="ot">@summaries</span> = <span class="ot">@survey</span>.summaries_using(decorated_summarizer)
<span class="kw">end</span>

<span class="kw">private</span>

<span class="kw">def</span> decorated_summarizer
  <span class="kw">if</span> include_unanswered?
    summarizer
  <span class="kw">else</span>
    <span class="dt">UnansweredQuestionHider</span>.new(summarizer, current_user)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>Now the <code>Survey#summaries_using</code> method is completely ignorant of answer hiding; it simply accepts a <code>summarizer</code> and the client (<code>SummariesController</code>) injects a decorated dependency. This means that adding similar changes won't require changing the <code>Summary</code> class at all.</p>
<p>This also allows us to simplify <code>UnansweredQuestionHider</code> by removing a condition:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/unanswered_question_hider.rb</span>
<span class="kw">def</span> hide_unanswered_question?(question)
  !question.answered_by?(<span class="ot">@user</span>)
<span class="kw">end</span></code></pre>
<p>We no longer build <code>UnansweredQuestionHider</code> when a user isn't signed in, so we don't need to check for a user.</p>
</section>
<section id="where-to-decide-dependencies" class="level2">
<h2><a href="#where-to-decide-dependencies">Where To Decide Dependencies</a></h2>
<p>While following the previous example, you probably noticed that we didn't eliminate the <code>UnansweredQuestionHider</code> dependency; we just moved it around. This means that, while adding new summarizers or decorators won't affect <code>Summary</code>, they will affect <code>SummariesController</code> in the current implementation. So, did we actually make anything better?</p>
<p>In this case, the code was improved because the information that affects the dependency decision—<code>params[:unanswered]</code>—is now closer to where we make the decision. Before, we needed to pass a Boolean down into <code>summaries_using</code>, causing that decision to leak across layers.</p>
<p>If you push your dependency decisions up until they reach the layer that contains the information needed to make those decisions, you will prevent changes from affecting several layers.</p>
<section id="drawbacks-11" class="level3">
<h3><a href="#drawbacks-11">Drawbacks</a></h3>
<p>Following this principle results in more abstraction and indirection, as it's often difficult to tell which class is being used for a dependency.</p>
<p>Looking at the example above, it's now impossible to know in <code>summaries_using</code> which class will be used for the <code>summarizer</code>:</p>
<pre class="sourceCode ruby"><code class="sourceCode ruby"><span class="co"># app/models/survey.rb</span>
<span class="kw">def</span> summaries_using(summarizer)
  questions.map <span class="kw">do</span> |question|
    question.summary_using(summarizer)
  <span class="kw">end</span>
<span class="kw">end</span></code></pre>
<p>This makes it difficult to know exactly what's going to happen. You can mitigate this issue by using naming conventions and well-named classes. However, each abstraction introduces more vocabulary into the application, making it more difficult for new developers to learn the domain.</p>
</section>
<section id="application-6" class="level3">
<h3><a href="#application-6">Application</a></h3>
<p>If you identify these smells in an application, you may want to adhere more closely to the <a href="#dependency-inversion-principle">dependency inversion principle</a> (DIP):</p>
<ul>
<li>Following DIP can eliminate <a href="#shotgun-surgery">shotgun surgery</a> by consolidating dependency decisions.</li>
<li>Code suffering from <a href="#divergent-change">divergent change</a> may improve after having some of its dependencies injected.</li>
<li><a href="#large-class">Large classes</a> and <a href="#long-method">long methods</a> can be reduced by injecting dependencies, as this will outsource dependency resolution.</li>
</ul>
<p>You may need to eliminate these smells in order to properly invert control:</p>
<ul>
<li>Excessive use of <a href="#callback">callbacks</a> will make it harder to follow the DIP, because it's harder to inject dependencies into a callback.</li>
<li>Using <a href="#mixin">mixins</a> and <a href="#single-table-inheritance-sti">STI</a> for reuse will make following the DIP more difficult, because inheritance is always decided statically. Because a class can't decide its parent class at run-time, inheritance can't follow inversion of control.</li>
</ul>
<p>You can use these solutions to refactor towards DIP-compliance:</p>
<ul>
<li><a href="#inject-dependencies">Inject dependencies</a> to invert control.</li>
<li>Use <a href="#extract-class">extract class</a> to make smaller classes that are easier to compose and inject.</li>
<li>Use <a href="#extract-decorator">extract decorator</a> to make it possible to package a decision that involves multiple classes and inject it as a single dependency.</li>
<li><a href="#replace-callback-with-method">Replace callbacks with methods</a> to make dependency injection easier.</li>
<li><a href="#replace-conditional-with-polymorphism">Replace conditional with polymorphism</a> to make dependency injection easier.</li>
<li><a href="#replace-mixin-with-composition">Replace mixin with composition</a> and <a href="#replace-subclasses-with-strategies">replace subclasses with strategies</a> to make it possible to decide dependencies abstractly at run-time.</li>
<li><a href="#use-class-as-factory">Use class as factory</a> to make it possible to abstractly instantiate dependencies without knowing which class is being used and without writing abstract factory classes.</li>
</ul>
<p>Following the <a href="#single-responsibility-principle">single responsibility principle</a> and <a href="#composition-over-inheritance">composition over inheritance</a> will make it easier to follow the <a href="#dependency-inversion-principle">dependency inversion principle</a>. Following this principle will make it easier to obey the <a href="#openclosed-principle">open/closed principle</a>.</p>
</section>
</section>
</section>
</body>
</html>