Applications can be:
- rigid: changes cascade through the system
- fragile: changes cause unpredictable side effects
- immobile: code reuse is hard/impossible
- viscous: behaving badly is the most attractive option
suggested resource: "Design Principles and Design Patterns"
Apps start not-sucking, end up sucking because of changes. To resist negative side effects of change, good code should be:
- loosely coupled
- highly cohesive
- easily composable
- context-independent
SOLID:
- single-responsibility: only does one thing
- open/close: open to extension, closed to modification
- liskov: obeys liskov substitution. when working with derived objects, if you have to use is_a? to figure out whether you're dealing with the parent or child, then they aren't interchangeable enough to justify derivation
- interface segregation: for statically-typed languages only. yay ruby!
- dependency inversion: inject dependencies instead of linking classes together
"Design is emergent when you follow object-oriented principles, just like features are emergent when you follow TDD."
Resistance is a resource - if you feel like the code is wrong, it probably is, even if you can't express why.
Normal loop is Red -> Green -> Refactor. After Green, ask these questions:
- Is it DRY?
- Does it have one responsibility?
- Does everything in it change at the same rate?
- Does it depend on things that change less than it does?
If any of these are "No", use the responsibility refactoring loop: Extract -> Inject -> Refactor, then through the Red -> Green -> Refactor loop again.
Tip for detecting violation of single-responsibility principle: Read your object's spec from top to bottom and connect the sentences with prepositions. Listen for things that don't seem to go together. e.g. "It downloads the file AND it populates the database."
"Refactor not because you know the abstraction, but because you want to find it."
No comments:
Post a Comment