Factory & Factory Method Design Patterns - Deep dive

The Factory Method and Factory Pattern are often used interchangeably, so I'll provide an example demonstrating the Factory Pattern in the context of a Ruby on Rails application. The Factory Pattern involves creating an interface for creating objects, but leaving the choice of their type to the subclasses, creating an instance of several derived classes.

Let's consider a scenario where you have different types of notifications in a Rails application, such as email notifications and SMS notifications. You can use the Factory Pattern to abstract the creation of these notifications:

# Abstract class defining the Notification interface
class Notification
  def send_message
    raise NotImplementedError, 'Subclasses must implement the send_message method'
  end
end

Now, create subclasses for each type of notification:

class EmailNotification < Notification
  def send_message
    # Logic for sending an email notification
    puts 'Sending email notification.'
  end
end

class SmsNotification < Notification
  def send_message
    # Logic for sending an SMS notification
    puts 'Sending SMS notification.'
  end
end

Next, create a NotificationFactory interface:

# Abstract class defining the NotificationFactory interface
class NotificationFactory
  def create_notification
    raise NotImplementedError, 'Subclasses must implement the create_notification method'
  end
end

Now, implement concrete factories for each type of notification:

class EmailNotificationFactory < NotificationFactory
  def create_notification
    EmailNotification.new
  end
end

class SmsNotificationFactory < NotificationFactory
  def create_notification
    SmsNotification.new
  end
end

Now you can use the factories to create notifications without knowing their concrete classes:

# Client code using the factory pattern
email_factory = EmailNotificationFactory.new
email_notification = email_factory.create_notification
email_notification.send_message

sms_factory = SmsNotificationFactory.new
sms_notification = sms_factory.create_notification
sms_notification.send_message

In this example, the NotificationFactory acts as an interface for creating instances of the Notification class. The concrete factories (EmailNotificationFactory and SmsNotificationFactory) implement this interface, providing specific implementations for creating email and SMS notifications.

This pattern allows you to introduce new types of notifications by creating additional factories without modifying the existing code. It promotes flexibility and encapsulation, making it easier to extend and maintain your application.

In summary, the Factory Pattern is useful when you have a family of related classes and want to delegate the responsibility of object instantiation to subclasses. It provides a way to create instances of a class without specifying the exact class until runtime, promoting flexibility and code maintainability.

The Factory Method Design Pattern is used when you want to delegate the responsibility of instantiating objects to subclasses, allowing a class to delegate the instantiation to its subclasses. This pattern is particularly useful when you have a class that cannot anticipate the class of objects it must create.

Let's explore a practical example in the context of a Ruby on Rails application:

Example: User Authentication Strategies

Consider a scenario where your Rails application supports multiple user authentication strategies, such as email/password, OAuth, and API token. Instead of hardcoding the authentication logic within a single class, you can use the Factory Method Pattern to delegate the responsibility of creating authentication strategies to subclasses.

# Base class defining the factory method
class AuthenticationStrategy
  def authenticate
    raise NotImplementedError, 'Subclasses must implement the authenticate method'
  end

  # The factory method
  def self.create_strategy
    raise NotImplementedError, 'Subclasses must implement the create_strategy method'
  end
end

Now, create subclasses for each authentication strategy:

class EmailPasswordAuthentication < AuthenticationStrategy
  def authenticate
    # Logic for email/password authentication
    puts 'Authenticating using email/password strategy.'
  end

  def self.create_strategy
    new
  end
end

class OAuthAuthentication < AuthenticationStrategy
  def authenticate
    # Logic for OAuth authentication
    puts 'Authenticating using OAuth strategy.'
  end

  def self.create_strategy
    new
  end
end

class ApiTokenAuthentication < AuthenticationStrategy
  def authenticate
    # Logic for API token authentication
    puts 'Authenticating using API token strategy.'
  end

  def self.create_strategy
    new
  end
end

Now, you can use the Factory Method to create and use authentication strategies without knowing their concrete classes:

# Client code using the factory method
strategy = EmailPasswordAuthentication.create_strategy
strategy.authenticate

# Another client code using a different strategy
another_strategy = OAuthAuthentication.create_strategy
another_strategy.authenticate

In this example, the Factory Method (create_strategy) is responsible for creating instances of the authentication strategies. Clients can use the factory method without being aware of the concrete classes, allowing for flexibility and extensibility. If you need to add a new authentication strategy in the future, you can simply create a new subclass without modifying the existing code.

In summary, the Factory Method Design Pattern is useful in scenarios where you want to delegate the responsibility of object instantiation to subclasses, providing a way to create instances of a class without specifying the exact class until runtime. In a Rails application, this can be beneficial when dealing with multiple related but varying strategies or components.