3. What the heck is a principle?
Guideline for creating software
that stands up well to iterative
development
4. What the heck is a principle?
Guideline for creating software
that stands up well to iterative
development
Statements that can be made
about your code’s design
5. What the heck is a principle?
Guideline for creating software
that stands up well to iterative
development
Statements that can be made
about your code’s design
FSM avoidance
9. Why should I care?
Uncle Bob Martin
- Old Dude
- Wrote tons of books
10. Why should I care?
Uncle Bob Martin
- Old Dude
- Wrote tons of books
- Knows a thing or two about
writing software
11. Why should I care?
Uncle Bob Martin
- Old Dude
- Wrote tons of books
- Knows a thing or two about
writing software
These things will make you
better codes
12. Why should I care?
Uncle Bob Martin
- Old Dude
- Wrote tons of books
- Knows a thing or two about
writing software
These things will make you
better codes
50% less Y U NO!!!
25. Single Responsibility Principle
an Object should only have one
“axis of change”
as software requirements shift,
refactoring is reflected through
changes of responsibility in your
code
26. Single Responsibility Principle
an Object should only have one
“axis of change”
as software requirements shift,
refactoring is reflected through
changes of responsibility in your
code
complex code only gets more
complex
34. Open/Closed Principle
“[objects] should be open for
extension, but closed for
modification”
makes code that’s more resilient
over time
very important for maintaining
large, production codebases
38. Open/Closed Principle
anti-pattern: modifying native
Prototypes in Javascript
used and violated in Backbone.js
test coverage alleviates some of
the pain that open/close want to
shield you from
41. Liskov Substitution
derived types should be
completely substitutable from
their base types
about preserving expectations when
creating classes and subclasses
42. Liskov Substitution
derived types should be
completely substitutable from
their base types
about preserving expectations when
creating classes and subclasses
Often this is a built in
language feature
45. Interface Segregation
favor many specific interfaces
over a single, “fat” interface
an api should only contains the
methods its caller needs
46. Interface Segregation
favor many specific interfaces
over a single, “fat” interface
an api should only contains the
methods its caller needs
leading cause of FSM, tightly
coupled code
50. Interface Segregation
jQuery is written as a series of
separate interfaces with a
common core
increases performance, sanity
“no client should be forced to
depend on code it does not use”
51. Interface Segregation
jQuery is written as a series of
separate interfaces with a
common core
increases performance, sanity
“no client should be forced to
depend on code it does not use”
another consequence of TDD
54. Dependency Inversion
“depend on abstractions, not on
concretions.”
create high-level software that is
decoupled from low-level software
through abstraction
55. Dependency Inversion
“depend on abstractions, not on
concretions.”
create high-level software that is
decoupled from low-level software
through abstraction
allows for saner, more flexible
resources
60. What does it mean?
You don’t create re-usable code
by accident.
61. What does it mean?
You don’t create re-usable code
by accident.
You experience these principles
every day
62. What does it mean?
You don’t create re-usable code
by accident.
You experience these principles
every day
Creates a good checklist of
“objective refactoring” statements
63. S.
Single Responsibility
O.
Open / Closed
L.
Liskov Substitution
I.
Interface Segregation
D.
Dependency Inversion
