From: Brian Candler <b.candler@...>
Date: 2010-02-11T18:41:55+09:00
Subject: Re: "Code must be Chunkable"

Thomas Sawyer wrote:
>     def execute
>       source_account.extend TransferSource
>       destination_account.extend TransferDestination
> 
>       source_account.withdraw(amount)
>       destination_account.deposit(amount)
> 
>       #source_account.unextend TransferSource
>       #destination_account.unextend TransferDestination
>     end
>   end

Thank you. That was pretty much what I was thinking. After all, in a 
real bank transfer, the "source account" isn't responsible for carrying 
out the transfer, the bank clerk is.

In a play, there's a single script. And if either Romeo or Juliet 
forgets their lines, it's the prompter at the front of the stage who 
tells them what to say next. (OK, perhaps that's taking the analogy too 
far :-)

I can see a specific case where this context/role split would work well. 
In Rails-type apps, I've wondered before how best to implement logic 
which clearly belongs in the model, but which is affected by properties 
of the controller. Behaviour dependent on the user's timezone preference 
is one example; adding updated_by and updated_ip stamps is another.

Rails solves the timezone problem by just stuffing it into a 
thread-local variable, which is horrible.

Having a 'context' object available to the model at execution time makes 
total sense. And as long as you inject the context at the same time as 
you inject the methods which make use of that context, then you know the 
two are aligned; it's safe because you know that code can't be used 
elsewhere.

In practice this might mean you eschew the model's own 'save' method in 
favour of a ModelUpdater context and a UpdatableModel role.
-- 
Posted via http://www.ruby-forum.com/.