The problem

Consider the following Ruby code.

class Beverage attr_reader :kind def initialize(kind) @kind = kind end def typical_ounces if :coffee 6 else 8 end end def calories_per_ounce if :coffee 0 else :unknown end end end 

So we’re modeling beverages. Great! Our class can accept a kind of beverage and then respond to some messages about it.

coffee = Beverage.new(:coffee) coffee.container # => "mug" coffee.typical_ounces # => 6 coffee.calories_per_ounce # => 0 oj = Beverage.new(:orange_juice) oj.container # => "glass" oj.typical_ounces # => 8 oj.calories_per_ounce # => :unknown 

Wonderful. But those if blocks aren’t great right? If we drop more kinds of beverage in that model then they’re going to get annoying pretty quickly. But no problem we can use some case statements to make a nice pattern!

class Beverage attr_reader :kind def initialize(kind) @kind = kind end def typical_ounces case kind when :coffee 4 when :orange_juice 8 else 8 end end def calories_per_ounce case kind when :coffee 0 when :orange_juice 14 else :unknown end end end 

Lovely. But there’s a problem here. As we add beverage after beverage the repetition of the conditionals becomes arduous.

class Beverage attr_reader :kind def initialize(kind) @kind = kind end def typical_ounces case kind when :coffee 4 when :orange_juice 8 when :rum 1.5 when :whole_milk 8 when :skim_milk 8 else 8 end end def calories_per_ounce case kind when :coffee 0 when :orange_juice 14 when :rum 64 when :whole_milk 19 when :skim_milk 12 else :unknown end end end 

Sure we could allow a lot of the typical_ounces fall through to the default case but then our data structures don’t line up with the calories_per_ounce and future devs won’t know if they really are the default or if we forgot to declare the correct data.

The tests are similarly convoluted and each new beverage is a data slog to sort through and easy to get wrong.

This isn’t fun! Let’s make it fun!

What we have here is a failure to utilize the full power of object oriented design.

“As an OO practitioner, when you see a conditional, the hairs on your neck should stand up. Its very presence ought to offend your sensibilities. You should feel entitled to send messages to objects, and look for a way to write code that allows you to do so.”

Excerpt From: Sandi Metz, Katrina Owen. “99 Bottles of OOP.” Apple Books.

Sandi and Katrina go on to explain that of course not every conditional is bad. The problem is having conditionals controlling the individual pieces of behavior in our class. A better object oriented design would pull together all the like behaviors into their own classes. Then have singular top level conditional that decides which behavior to use.

It’s like having a car repair manual peppered with conditionals. “If you have an Outback then do X, but if you have a Forester then do Y.” Not a great experience! A much nicer alternative is only making a decision about which car model you have once and then using its dedicated manual.

Replacing low level conditionals with objects

We can make our beverage class nicer to work with by not requiring it to be the only class we have. We can make a class for each individual beverage that all answer the same messages that we want to send them.

class Coffee def typical_ounces 6 end def calories_per_ounce 0 end end class OrangeJuice def typical_ounces 8 end def calories_per_ounce 14 end end class Rum def typical_ounces 1.5 end def calories_per_ounce 64 end end class WholeMilk def typical_ounces 8 end def calories_per_ounce 19 end end class SkimMilk def typical_ounces 8 end def calories_per_ounce 12 end end 

Check that out! Those classes are completely focused and minimal. Testing them becomes a simple exercise that they respond to the right messages.

But what happened to Beverage and where are the default values? Let’s take those in reverse order.

The default case

Before the default values fell out of our huge case statements in the final else path where we give up and say “8” for typical ounces and :unknown for calories per ounce. Unknown is not an actual beverage that we directly modeled before, but it’s absolutely behavior that we can extract into a name.

class UnknownBeverage def typical_ounces 8 end def calories_per_ounce :unknown end end 

Choosing the right behavior

The Beverage concept is still useful. Before we’d initialize it with a kind and then expect the resulting instance to have the correct behavior.

oj = Beverage.new(:orange_juice) oj.calories_per_ounce # => 14 

Here we can either adjust our API or add a little complexity to the Beverage class.

Adjusting the Beverage API

First, let’s see how adjusting our API would look.

In Ruby it’s idiomatic to add a class method called for to choose between different object behaviors e.g. Beverage.for(:coffee). We can call the decision method anything we like. Its job will be to pick the right beverage class so we can use whatever makes sense.

oj = Beverage.for(:orange_juice) oj = Beverage.given(:orange_juice) oj = Beverage.from(:orange_juice) oj = Beverage.build(:orange_juice) 

In our example let’s stick with for. Here’s what that top level decision behavior could look like.

class Beverage def self.for(kind) case kind when :coffee Coffee.new when :orange_juice OrangeJuice.new when :rum Rum.new when :whole_milk WholeMilk.new when :skim_milk SkimMilk.new else UnknownBeverage.new end end end 

Keeping the original Beverage behavior

Second, let’s see how we could keep the original Beverage.new behavior by making Beverage a little more complex. It can hold the specific beverage class chosen from kind and delegate the calls to the appropriate data class.

class Beverage def initialize(kind) @dataObject = case kind when :coffee Coffee.new when :orange_juice OrangeJuice.new when :rum Rum.new when :whole_milk WholeMilk.new when :skim_milk SkimMilk.new else UnknownBeverage.new end end def typical_ounces @dataObject.typical_ounces end def calories_per_ounce @dataObject.calories_per_ounce end end 

Even better! Ruby has a stdlib for that: SimpleDelegator! With SimpleDelegator we give it the class we want our object to delegate methods calls to. Nice!

require "delegate" class Beverage < SimpleDelegator def initialize(kind) dataObject = case kind when :coffee Coffee.new when :orange_juice OrangeJuice.new when :rum Rum.new when :whole_milk WholeMilk.new when :skim_milk SkimMilk.new else UnknownBeverage.new end super(dataObject) end end 

Conditionals? Managed

Yes in all of these cases there’s still a conditional. But the key difference is that now we have a single top level conditional choosing a behavior rather than multiple low level conditionals choosing raw data. We have little to no chance of introducing a bug in the data due to a mismatch of logic. Before we could have easily introduced bug while trying to keep those large, parallel case statements consistent.