The DRY Principle

Direct Answer

DRY means every important piece of knowledge should have one authoritative representation. In Ruby, repeated business rules, mappings, or calculations should be given one clear method, object, or data source so a change cannot leave copies inconsistent. DRY is not a command to eliminate every similar line: two pieces of code that only look alike but change for different reasons may be safer left separate until their shared concept is proven.

Deep Dive & Architecture

The risk in duplication is divergent change. If tax eligibility is written in three request handlers, one bug fix may update only two. The repeated lines are a symptom; the duplicated definition of eligibility is the actual problem.

A useful extraction starts by naming the rule and locating the object responsible for it. A calculation about an order may belong to an Order or policy object; repeated display markup may belong to a partial; repeated test setup may belong to a factory or helper. One universal helper file is rarely the right owner.

Timing matters. The first two examples provide evidence but may still differ in hidden ways. Waiting until the reasons for change are known can reveal the correct parameters—or reveal that no shared abstraction exists.

An abstraction has a maintenance cost: name, API, dependencies, and tests. It has earned that cost when callers share one meaning and future rule changes should reach all of them together.

Code Example

class DiscountPolicy
  THRESHOLD = 100
  RATE = 0.10

  def discount_for(total)
    total >= THRESHOLD ? total * RATE : 0
  end
end

policy = DiscountPolicy.new
policy.discount_for(80)   # => 0
policy.discount_for(120)  # => 12.0

# Controllers, invoices, and jobs call the same rule
# instead of copying the threshold and calculation.

Common Mistakes & Pitfalls

Over-extracting (DRYing unrelated things that just look similar) or blind copy-paste (the WET opposite).