thOOughtz #1

gistfile1.rb

# "O que é mais interessante? Adicionar callbacks(ActiveRecord like) ou criar uma classe encapsulando o comportamento 'extra' desejado."
# "What is more interesting? Add callbacks(ActiveRecord like) or create a class that encapsulate the desired 'extra' behavior."
class B
  before :method, :before_method
          ...
  before :method, :before_methodN

  after :method, :after_method
          ...
  after :method, :after_methodN

  def before_method
  end
  def method
    puts "i'm beeing called"
  end
  def after_method
  end
end

or

class B
  def method
    puts "i'm beeing called"
  end
end

class BWrapper

  attr_reader :b

  def initialize(b)
    @b = b
  end
  
  def after_method
  end
  def before_method
  end

  def method
    before_method
    b.method
    after_method
  end
end


# Meus pensamentos:

## primeira
# Sabe-se sobre a ordem de execução, sempre será uma fila: [before callbacks, method, after callbacks].
# A primeira solução é boa nos seguintes pontos:
# - é simples de adicionar mais comportamento ao mesmo objeto.
# e ruim nos seguintes pontos:
# - é dificil de ter uma garantia da ordem de execução das ações
# - o objetos da classe B sempre terão que ter este comportamento atrelado a eles. (possível dificuldade no re-uso).
#
## segunda
# A segunda solução é boa no seguintes pontos:
# - todos os metodos estão isolados, então é fácil de testar todos os metodos em isolamento. Por fim pra testar o 'method' (da classe BWrapper) basta fazer vários mocks de chamadas dos métodos.
# - o objeto da classe B pode existir sem que comportamentos 'extras' sejam adicionados a ele.
#
# e ruim nos seugintes pontos:
# - uma classe a mais.
# - mais "dificil" de adicionar comportamento ao 'method' do BWrapper.

# My thoughts:

## First 
# It's known the execution order, it always be a queue: [before callbacks, method, after callbacks].
# The first solution is good on the following points:
# - its simple to add more behavior to the B's objects. 
#
# and bad on the following points:
# - its hard to have a guarantee of execution order of the callbacks.
# - the B's objects always will have this behavior coupled to the method 'B'. (Possible hard to re-use) 
#
## Second
# The second solution is good on the following points:
#   - all methods are isolated, so its easier to test all methods in isolation. By the end to test the BWrapper's 'method' its only needed to mock the calls of objects of Wrapper.
#   - the B class object's can exist without the tied behavior of the wrapper.
# 
# it's bad on the following points:
#   - one more class.
#   - it's more hard to add behavior to the BWrapper.