wisper

gistfile1.rb

# Service approach

class EmployeeService

  def delete(employee_id)
    employee = Employee.find(employee_id)

    delete_reviews(employee)
    disable_feedback_access(employee)

    employee.destroy
  end

  protected

  def delete_reviews(employee)
    # relevant code here...
  end

  def disable_feedback_access
  end
end

# When I make this method call, I can jump immediately into this method and see what are the repercussions.
EmployeeService.new.delete(some_employee_id)


# Let's compare it to the observer pattern directly within the modelbelow:


class Employee < ActiveRecord::Base
  include Wisper::Publisher

  before_destroy :disable_employee

  has_many :reviews

  def disable_employee
    reviews.destroy_all
    disable_feedback_access!
  end

  protected

  def disable_feedback_access!
    # now this model has to know about how other models work, thus coupling Employee tightly with whatever
    # the feedback access logic is.
  end
end

# somewhere deep in your code...
# a Rails dev would just assume this is doing a destroy, 
# doesn't realize it's doing a lot of logic behind the scenes
employee.destroy

Do you make services classes so that you can extend them to overwrite functionality? (vs have the methods be static)