Skip to content
This repository

Use the observer pattern to better divide your objects' responsibilities.

branch: master
README.rdoc

Observational

How many times have you seen this in a rails app?

class User
  after_create :deliver_welcome_message

  protected
  def deliver_welcome_message
    Notifier.deliver_welcome_message(self)
  end
end

Why is the user concerned with the delivery of his own welcome message? It seems like the Notifier should be responsible for that.

Observational makes it possible to make it the Notifier's responsibility, using the observer pattern.

The equivalent of the above example is:

class Notifier < ActionMailer::Base
  observes :user, :invokes => :deliver_welcome_message, :after => :create

  def welcome_message(user)
    # do mailer stuff here
  end
end

After a user is created, Notifier.deliver_welcome_message(that_user) will be invoked.

It's also possible to specify that the observer method gets called with a specific attribute from the observed object.

class Creditor
  observes :message, :invokes => :use_credit, :with => :creator, :after => :create

  def use_credit(user)
    # do something
  end
end

After a message is created, Creditor.use_credit(message.creator) will be called.

Observational supports all of ActiveRecord's callbacks.

YARDOC

Observational uses YARD, because it's a million times better than RDoc. You can find the docs at docs.github.com/giraffesoft/observational

General Purpose Observers

Observational can also be used to add observers to ruby classes that aren't related to active_record. But, that's not documented yet :-).

Copyright

Copyright © 2009 James Golick. See LICENSE for details.

Something went wrong with that request. Please try again.