DRY and SOLID: Different Design Problems
Fast recall
Quick revision
Core answer
Whether you can map DRY/SOLID onto Ruby idioms (modules over inheritance, duck typing for LSP/ISP, DI by passing objects), pragmatically.
Forcing Java-style interfaces in Ruby (use modules/duck typing), or over-engineering simple code with patterns.
DRY = one source of truth; SOLID in Ruby = small classes (SRP), modules over inheritance, duck typing for LSP/ISP, DI by injection. Pragmatic, not rigid.
Interview-ready guide
Interview answer
DRY and SOLID both reduce change risk, but they diagnose different problems. DRY looks for the same knowledge maintained in multiple places. SOLID looks at how responsibilities, contracts, and dependencies are divided between objects.
For example, three classes copying the same tax formula violate DRY because one rule can drift. Giving the rule to TaxPolicy creates one source. Having Checkout construct a concrete tax API inside itself is a dependency problem; injecting a small calculator role applies Dependency Inversion.
DRY alone can produce a large shared helper that owns unrelated rules. That removes repeated lines while worsening Single Responsibility and Interface Segregation. SOLID alone can create many tiny abstractions before there is evidence of variation, which makes simple behaviour harder to follow.
The principles can also point in different directions. Two similar-looking calculations may belong to different domains and change independently; keeping them separate respects responsibility even though some syntax is repeated.
A balanced design identifies the actual decision, gives it one responsible owner, and exposes only the contract its callers need. The useful result is a smaller change surface, not a particular number of classes or perfectly unique lines.
DRY and SOLID: Different Design Problems
Direct Answer
DRY prevents one piece of knowledge from being maintained in several places; SOLID shapes responsibilities and dependencies so software can change without widespread edits. DRY asks whether copies must stay consistent, while SOLID asks who owns a decision and how collaborators can vary safely. They work together when a shared rule gains one clear owner and callers depend on its small contract, but either can be over-applied through premature abstractions.
Deep Dive & Architecture
A DRY review traces a fact through the system: where is the discount threshold defined, and which copies must always agree? A SOLID review traces causes of change: which class changes when pricing, storage, delivery, or a vendor API changes? The two maps overlap but are not identical.
Centralising a rule solves consistency only when the new owner is meaningful. A global Utils module can become a bucket of unrelated knowledge. A policy object, value object, or domain method gives the shared rule a name and responsibility that explain why the callers converge there.
Dependencies determine how far a change travels. If the rule's public protocol is small, callers remain stable while its algorithm changes. If the abstraction leaks provider fields or requires unused methods, the centralisation has simply moved coupling to a new place.
The safest sequence is evidence, ownership, contract, then extraction. This avoids abstracting coincidental similarity and keeps each added object tied to a concrete maintenance benefit.
Code Example
class TaxPolicy
def tax_for(subtotal)
subtotal * 0.18
end
end
class Checkout
def initialize(tax_policy)
@tax_policy = tax_policy
end
def total(subtotal)
subtotal + @tax_policy.tax_for(subtotal)
end
end
Checkout.new(TaxPolicy.new).total(100) # => 118.0
# TaxPolicy is the one rule; Checkout depends on its small behaviour.
Common Mistakes & Pitfalls
Forcing Java-style interfaces in Ruby (use modules/duck typing), or over-engineering simple code with patterns.
Check your understanding
Answer these without looking back at the article.
- Can a refactor be DRY but violate Single Responsibility?
- When should two similar pieces of code remain separate?
- How do knowledge ownership and dependency direction affect change cost?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.