When diving deep into Ruby, understanding how to manage object access and behavior is crucial. There are two standout design patterns that come to the rescue: the Proxy pattern and Delegation. These patterns let you control object interactions by adding layers of functionality without tweaking the original objects.

The Proxy Pattern Unraveled

The Proxy pattern is a key player in structural design. Think of it as a stand-in (or substitute) for a real service object. When a client makes a request, the proxy steps in, does some pre or post-processing (like logging, caching, or access control), and then forwards the request to the actual service object. The clever part? The proxy matches the interface of the service, making it completely interchangeable.

Why Bother with Proxies?

Proxies become a game-changer when you need to add behaviors to an object without touching the client code. Imagine needing access control where only authorized users can call specific methods. Or perhaps you want to cache results from resource-heavy method calls and boost performance.

Different Flavors of Proxies

• Protection Proxy: Shields the object from unauthorized access by verifying user permissions before passing requests.
• Remote Proxy: Facilitates access to objects on remote machines, handling all the networking complexities behind the scenes.
• Virtual Proxy: Delays object creation until absolutely necessary, which is handy when the creation is resource-intensive.

Crafting a Proxy in Ruby

Picture a scenario where you want to keep a log of all interactions with a BankAccount object. Instead of altering BankAccount, create a BankAccountLogger class to act as its proxy.

class BankAccount
  def initialize(amount)
    @amount = amount
  end

  def deposit(amount)
    @amount += amount
  end

  def withdraw(amount)
    @amount -= amount if @amount >= amount
  end

  def balance
    @amount
  end
end

class BankAccountLogger
  def initialize(account)
    @account = account
  end

  def method_missing(name, *args, &block)
    puts "Calling method #{name} with arguments #{args}"
    result = @account.send(name, *args, &block)
    puts "Method #{name} returned #{result}"
    result
  end
end

# Usage
account = BankAccount.new(100)
logged_account = BankAccountLogger.new(account)

logged_account.deposit(50)
logged_account.withdraw(20)
puts logged_account.balance

Here, BankAccountLogger logs method calls and then forwards them to the BankAccount object. Simple and effective!

The Charm of Delegation

Delegation is all about an object passing off some of its responsibilities to another object, quite different from inheritance where a class derives behavior from a parent class. This method bolsters flexibility and modularity.

Why Lean on Delegation?

Delegation helps when you want to keep objects loosely coupled. Changing an object’s behavior becomes effortless without disturbing other parts of the system. A classic example? Offloading logging duties to a separate logger object, allowing easy swapping of logging mechanisms.

Delegation in Ruby: The How-to

Ruby offers a couple of slick ways to pull off delegation: using the method_missing method or the forwardable module.

Employing method_missing

The method_missing gem in Ruby catches and handles unimplemented method calls. Here’s a demonstration:

class Logger
  def log(message)
    puts message
  end
end

class BankAccount
  def initialize(amount, logger)
    @amount = amount
    @logger = logger
  end

  def method_missing(name, *args, &block)
    if @logger.respond_to?(name)
      @logger.send(name, *args, &block)
    else
      super
    end
  end

  def deposit(amount)
    @amount += amount
  end

  def withdraw(amount)
    @amount -= amount if @amount >= amount
  end

  def balance
    @amount
  end
end

# Usage
logger = Logger.new
account = BankAccount.new(100, logger)

account.log("Transaction started")
account.deposit(50)
account.log("Transaction completed")

Here, BankAccount uses method_missing to delegate logging to the Logger object.

Leveraging forwardable

Ruby’s forwardable module simplifies delegation. Here’s how:

require 'forwardable'

class Logger
  def log(message)
    puts message
  end
end

class BankAccount
  extend Forwardable

  def initialize(amount, logger)
    @amount = amount
    @logger = logger
  end

  def_delegators :@logger, :log

  def deposit(amount)
    @amount += amount
  end

  def withdraw(amount)
    @amount -= amount if @amount >= amount
  end

  def balance
    @amount
  end
end

# Usage
logger = Logger.new
account = BankAccount.new(100, logger)

account.log("Transaction started")
account.deposit(50)
account.log("Transaction completed")

Here, def_delegators in BankAccount delegates logging to the Logger object.

Going Beyond: Advanced Cases

Dynamic Delegation at Play

Ruby’s dynamic capabilities allow adding or removing delegations on the fly, useful for changing an object’s behavior based on conditions.

class DynamicBankAccount
  def initialize(amount)
    @amount = amount
  end

  def method_missing(name, *args, &block)
    if @delegate && @delegate.respond_to?(name)
      @delegate.send(name, *args, &block)
    else
      super
    end
  end

  def set_delegate(delegate)
    @delegate = delegate
  end

  def deposit(amount)
    @amount += amount
  end

  def withdraw(amount)
    @amount -= amount if @amount >= amount
  end

  def balance
    @amount
  end
end

# Usage
account = DynamicBankAccount.new(100)
logger = Logger.new

account.set_delegate(logger)
account.log("Transaction started")
account.deposit(50)
account.log("Transaction completed")

Here, DynamicBankAccount can dynamically assign a delegate, demonstrating the power of flexibility.

Using BasicObject for Proxies

Ruby’s BasicObject, introduced from version 1.9, aids in crafting proxies efficiently. It’s a stripped-down version of Object with minimal methods, reducing conflicts.

class AccountLogger < BasicObject
  def initialize(account)
    @account = account
  end

  def method_missing(name, *args, &block)
    puts "Calling method #{name} on #{@account.class}"
    result = @account.send(name, *args, &block)
    puts "Method #{name} returned #{result}"
    result
  end
end

# Usage
account = BankAccount.new(100)
logged_account = AccountLogger.new(account)

logged_account.deposit(50)
logged_account.withdraw(20)
puts logged_account.balance

In this snippet, AccountLogger uses BasicObject to keep method conflicts at bay.

Wrapping Up

Understanding and implementing the Proxy and Delegation patterns in Ruby brings tremendous power to your design toolkit. These patterns enable adding functionality layers without tweaking original objects. Whether it’s managing cache, logging, or controlling access, utilizing these patterns makes your code more modular, maintainable, and efficient. Embrace these flexible solutions to tackle common software design challenges seamlessly.