Just a thought in my mind. what is the difference the following
before_filter
class ApplicationController < ActionController::Base
  before_filter :foo
  def foo
    @mode = Model.new
  end
end
ruby initialize
class ApplicationController < ActionController::Base
  def initialize
    foo
  end
  def foo
    @mode = Model.new
  end
end
For each request, you do get a fresh instance of ApplicationController, but the big no-no here is that you're attempting to override core behavior of ActionController::Base#initialize without calling the parent behavior.
ApplicationController < ActionController::Base
  def initialize
    super # this calls ActionController::Base initialize
    init_foo
  end
  private
  def init_foo
    @foo = Foo.new
  end
end
This is not idiomatic Rails behavior though. They give you before_filter for a reason; so use it.
I believe this was covered in Practical Object-Oriented Design in Ruby by Sandi Metz.
Suppose you are designing a base class for other developers/users, and want to allow them to hook into various steps in a procedure (e.g. initialization.) In general, there are two ways:
super whenever they override a method.(I believe that these are variations of the Template Method pattern.)
The second way requires more effort on your part and less effort for your users.
In this specific case, before_filter provides a cleaner way to attach multiple hooks and encourages you to break up hooks into single-responsibility methods with meaningful names. This becomes more important in applications that use more controller inheritance.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With