Ben - I watched your talk, "Refactoring from Good to Great", and really enjoyed it.
I'm curious about how you apply the Law of Demeter in your programs.
Suppose you have a time-tracking app for your consulting business. The billing calculation
for a task might include looking up `task.project.contract.client.state.tax_rate`.
Clearly this is bad, and will make testing difficult; that's a lot of objects to set up
before making an assertion about a task! But I don't like the idea of littering the
task with methods that exist solely to reach across the system, like
`def project_contract_client_state_tax_rate`, and doing the same to all the objects
down the chain.
It seems like the answer might involve architecture changes so that there are fewer
objects to reach through, but that could result in objects with too many responsibilities.
Do you have any thoughts on this kind of situation?