I've seen this exact scenario play out in a dozen different code reviews. You're building a notification system, and it starts simple—just emails. Then the product manager asks for SMS, then Slack, then maybe Push notifications. You start adding classes, and suddenly you're hitting a wall like this.

class EmailNotification
  def send_email(message)
    puts "Sending Email: #{message}"
  end
end

class SMSNotification
  def send_sms(message)
    puts "Sending SMS: #{message}"
  end
end

# The "Dispatcher" logic
notifications = [EmailNotification.new, SMSNotification.new]
message = "Your order has shipped!"

notifications.each do |notification|
  # This is where the crash happens
  notification.deliver(message) 
end

# Result: NoMethodError (undefined method `deliver' for #<EmailNotification:0x000...>)

The NoMethodError Trap

The mistake here is a classic: the developer created a collection of objects they thought were interchangeable, but they didn't actually share a common interface. In Ruby, we talk a lot about "Duck Typing"—if it walks like a duck and quacks like a duck, it's a duck. But in the code above, one object "quacks" via send_email and the other via send_sms. When the dispatcher tries to call deliver, Ruby looks at the object and says, "I have no idea what that is," and throws a NoMethodError.

You might be tempted to fix this with a big case statement inside the loop, checking the class of each notification. Please, don't do that. That's a maintenance nightmare. Every time you add a new notification channel, you'd have to hunt down every case statement in your codebase and add a new branch.

Standardizing the Interface

The fix is to stop caring about how the notification is sent and instead define a single, consistent method that every notification class must implement. I usually call this the "Contract."

class EmailNotification
  def deliver(message)
    # Logic for email API goes here
    puts "Sending Email: #{message}"
  end
end

class SMSNotification
  def deliver(message)
    # Logic for SMS API goes here
    puts "Sending SMS: #{message}"
  end
end

class SlackNotification
  def deliver(message)
    # Logic for Slack Webhook goes here
    puts "Posting to Slack: #{message}"
  end
end

# Now the dispatcher is blissfully unaware of the specific classes
notifications = [EmailNotification.new, SMSNotification.new, SlackNotification.new]
notifications.each { |n| n.deliver("System Update: Maintenance at Midnight") }

Now, the dispatcher doesn't need to know if it's dealing with an email or a Slack message. It just knows that everything in the notifications array responds to deliver. This is the essence of the Strategy Pattern. It keeps your dispatcher lean and your notification logic isolated.

Handling Failure Gracefully

In a real-world system, external APIs fail. Constantly. If your SMS provider goes down and you're looping through notifications, you don't want a single timeout to crash the entire process and prevent the email from going out. I always recommend wrapping the delivery call in a basic error handler within the loop or the strategy class.

notifications.each do |n|
  begin
    n.deliver(message)
  rescue StandardError => e
    # Log the error, but let the loop continue to the next notification
    puts "Failed to send #{n.class}: #{e.message}"
  end
end

By shifting the responsibility of "how to send" to the individual classes and the responsibility of "what to send" to the dispatcher, you've built a system that is actually extensible. If you need to add WhatsApp notifications tomorrow, you just create a WhatsAppNotification class with a deliver method. You don't have to touch a single line of your existing dispatcher logic.

📋 Practical Task

Build a Multi-Channel Alert Dispatcher for a Stock Tracker

You are building a system that alerts users when a stock hits a certain price. You need to implement a notification system that supports three different channels: Email, SMS, and In-App Notification.

Requirements:

• Create three classes: EmailAlert, SMSAlert, and InAppAlert.
• Each class must implement a deliver(user, message) method that prints a string indicating the channel used, the user's name, and the alert message.
• Create a NotificationDispatcher class with a method send_all(user, message, channels). This method should take a user object, a message string, and an array of notification channel objects, then trigger the delivery for each.
• Ensure that if one channel fails (you can simulate this by making one of your deliver methods raise a RuntimeError), the other notifications are still sent.

Test your code by: Creating a User object (a simple OpenStruct or a class with a name attribute) and passing it through your dispatcher with all three notification channels.