I'll Be Backend
Principles · Ruby

Inheritance: pull up duplicated behavior

Write shared behavior once in a superclass, so every subclass gets each change.

10 steps4 chapters~4 min at 1.25×#oop#inheritance#duplicated code#superclass
The lesson plays right here. Pause anywhere, step back, or jump to a step below. Watch the Ruby video on YouTube Code on GitHub

Watch the narrated video

Every step

Problem

Steps 1–3

Refactor

Steps 4–6

Payoff

Steps 7–8

Recap

Steps 9–10

The code: before and after

Before

class Shipment
  def price
    raise NotImplementedError
  end
end

class DomesticShipment < Shipment
  def initialize(tracking, weight_kg)
    @tracking = tracking
    @weight_kg = weight_kg
  end

  def price
    5 + @weight_kg
  end

  def label
    parts = [@tracking, "#{@weight_kg} kg", "$#{price}"]
    parts.join(" | ")
  end
end

class InternationalShipment < Shipment
  def initialize(tracking, weight_kg)
    @tracking = tracking
    @weight_kg = weight_kg
  end

  def price
    20 + @weight_kg * 4
  end

  def label
    parts = [@tracking, "#{@weight_kg} kg", "$#{price}"]
    parts.join(" | ")
  end
end

home = DomesticShipment.new("DM-1", 2)
abroad = InternationalShipment.new("IN-7", 2)
puts home.label   # DM-1 | 2 kg | $7
puts abroad.label # IN-7 | 2 kg | $28

After

class Shipment
  def initialize(tracking, weight_kg)
    @tracking = tracking
    @weight_kg = weight_kg
    @fragile = false
  end

  def price
    raise NotImplementedError
  end

  def mark_fragile
    @fragile = true
  end

  def label
    parts = [@tracking, "#{@weight_kg} kg", "$#{price}"]
    parts << "FRAGILE" if @fragile
    parts.join(" | ")
  end
end

class DomesticShipment < Shipment
  def price
    5 + @weight_kg
  end
end

class InternationalShipment < Shipment
  def price
    20 + @weight_kg * 4
  end
end

home = DomesticShipment.new("DM-1", 2)
abroad = InternationalShipment.new("IN-7", 2)
abroad.mark_fragile
puts home.label   # DM-1 | 2 kg | $7
puts abroad.label # IN-7 | 2 kg | $28 | FRAGILE

Transcript, step by step

Problem

Step 1: A courier's two shipments Before

A parcel courier's dispatch desk works with two kinds of shipment. Shipment is the superclass, the class the others extend, and each subclass, a class that extends it, says what its parcel costs. Shipment's own price raises an error, so a subclass that forgets to define one fails when the label asks for it. Both subclasses also set a tracking code and a weight in their own initialize, and both build a label from them. The script at the bottom prints one label for a domestic parcel and one for an international one.

Step 2: Fragile parcels Code smell

The courier now needs the word fragile on the label of fragile parcels. The quick way adds a fragile variable, a mark fragile method and a label check to Domestic Shipment, and then the same three again to International Shipment. The script marks the parcel going abroad, so only the second label ends in fragile.

Step 3: Two copies of everything Code smell

Duplicated code across subclasses is when two classes that share a superclass each write the same fields and methods on their own. You can see the fields here and here, and the label here and here. So every change to the label is made twice, and the day someone edits only one copy, a fragile parcel ships without the word on it. A third shipment type would copy all of it a third time.

Refactor

Step 4: Refactor first Back it out

Let's take the fragile flag out again. We'll refactor first, so that the shared parts move up into Shipment, and then we'll add the flag in one place.

Step 5: One initialize Pull Up Constructor Body

Ruby has no field declarations, and an instance variable comes into being when initialize assigns it, so the fields and the constructor body move up together. Shipment's initialize now sets the tracking code and the weight, once. The two subclass constructors only repeated those lines, so both are deleted, and each subclass inherits initialize from Shipment. Instance variables belong to the object, so each subclass label still reads the tracking code and weight that Shipment set. The script still builds both parcels with a tracking code and a weight, and prints the same two labels.

Step 6: One label Pull Up Method

Now the two label bodies are identical, so one copy moves up into Shipment, and both subclass copies are deleted. Label still works because it calls price, and each subclass still answers price its own way. This is inheritance, where a subclass gets the fields and methods of its superclass, so the shared parts are written once, in Shipment. What's left in each subclass is its price. A superclass method that calls a step each subclass fills in, like label calling price, is the Template Method pattern.

Payoff

Step 7: Fragile, once Add the flag

Now the fragile flag comes back, and this time it goes into Shipment only. Shipment gains one fragile variable and one mark fragile method, and label adds the word once. Domestic and International Shipment didn't change, and the script only gains one call that marks the parcel going abroad.

Step 8: Shared code lives once Payoff

The fields now exist once, here, and the label exists once, here. The fragile rule is written once too, so the two labels can't drift apart, and the run prints the word only on the parcel going abroad. It fits because both classes are shipments, each with a tracking code, a weight and a label, and only the price differs. Abstraction hid how a class stores its data, and inheritance shares what two classes both do.

Recap

Step 9: Where we started, where we ended Before / after

On the left, each subclass keeps its own initialize and its own label. On the right, Shipment holds the initialize, the fragile flag and the label, each written once. A subclass like Domestic Shipment keeps only its own price.

Step 10: When to reach for it Takeaways

Reach for it when two or more subclasses of one superclass repeat the same fields or the same method body. Skip it when two classes look alike today but will change for different reasons, because a superclass ties them together, so use Extract Class and delegate to it. You'll spot the need by the same method copied into sibling subclasses, and the same initialize lines in each. Ruby's own errors work this way, because a custom error that subclasses Standard Error writes nothing and still inherits its message and backtrace.