POODR class notes

gistfile1.md

Notes and observations

• The next one to prove the first is wrong
• Choose a name inline with the concept in the domain.
  • Good OO code names concepts, not worried about implementation
• Terseness is cleverness (not goodness), stop picking on each other for being simple.
• Smallest change you can make to prove the last test insuficient.
• Solve the easy problems first, then maybe the hard ones become easy.
• DRY is good, but sometimes duplication makes sense, if it passes the inebriation test, check it in and walk away
• Open/Close Add new features without adding new code
• lean on the green
• first implement the Null object
• Write code such that you can refactor it when you're drunk
• "Inline method refactoring", take your conditionals and put them back inline, in place of the callers.
• sunk cost falacy: staying in a bad movie because you paid for it
• There are hidden concepts in the domain. Leave them hidden if they don't matter. To implement new features it may be important to refactor them out.

Refactoring

Rules to dry out duplication

• Pick two strigs that are most alike
• Find the smallest difference
• Make the smallest change that will removes the difference.
• Parse: run code, check for errors
• execute without using result
• execute using the result
• delete unused code

Restrictions

• If you go red, undo.
• Only change one line at a time.
• The only exception is when defining a method.

When making changes (ask yourself)

• Is this open to the requirement?
• Do I know how to make it open to the new requirement?
• Make the smallest change to improve OO design.

Shameless Green

expose the max info about the domain, without regard for duplication There are abstractions I don't understand with the most intention revealing way

Read

1. Martin Fowler, code smells