Skip to content

Instantly share code, notes, and snippets.

@cpytel

cpytel/gist:4176695

Created November 30, 2012 16:09
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save cpytel/4176695 to your computer and use it in GitHub Desktop.
Save cpytel/4176695 to your computer and use it in GitHub Desktop.
Download ZIP
Ask Giant Robots question from Nathan Long
Raw
gistfile1.txt
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?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment