SOLID Design Principles

5,537 views
5,581 views

Published on

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
5,537
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • SOLID Design Principles

    1. 1. SOLID Design Principles
    2. 2. What the heck is a principle?
    3. 3. What the heck is a principle?Guideline for creating softwarethat stands up well to iterativedevelopment
    4. 4. What the heck is a principle?Guideline for creating softwarethat stands up well to iterativedevelopmentStatements that can be madeabout your code’s design
    5. 5. What the heck is a principle?Guideline for creating softwarethat stands up well to iterativedevelopmentStatements that can be madeabout your code’s designFSM avoidance
    6. 6. Why should I care?
    7. 7. Why should I care?Uncle Bob Martin
    8. 8. Why should I care?Uncle Bob Martin - Old Dude
    9. 9. Why should I care?Uncle Bob Martin - Old Dude - Wrote tons of books
    10. 10. Why should I care?Uncle Bob Martin - Old Dude - Wrote tons of books - Knows a thing or two about writing software
    11. 11. Why should I care?Uncle Bob Martin - Old Dude - Wrote tons of books - Knows a thing or two about writing softwareThese things will make youbetter codes
    12. 12. Why should I care?Uncle Bob Martin - Old Dude - Wrote tons of books - Knows a thing or two about writing softwareThese things will make youbetter codes50% less Y U NO!!!
    13. 13. Principles vs. Patterns
    14. 14. Principles vs. PatternsAren’t patterns enough?
    15. 15. Principles vs. PatternsAren’t patterns enough?Who are you?
    16. 16. Principles vs. PatternsAren’t patterns enough?Who are you?SOLID Principles are the basisfor useful patterns
    17. 17. S.O.L.I.D.
    18. 18. S. Single ResponsibilityO.L.I.D.
    19. 19. S. Single ResponsibilityO. Open / ClosedL.I.D.
    20. 20. S. Single ResponsibilityO. Open / ClosedL. Liskov SubstitutionI.D.
    21. 21. S. Single ResponsibilityO. Open / ClosedL. Liskov SubstitutionI. Interface SegregationD.
    22. 22. S. Single ResponsibilityO. Open / ClosedL. Liskov SubstitutionI. Interface SegregationD. Dependency Inversion
    23. 23. Single Responsibility Principle
    24. 24. Single Responsibility Principlean Object should only have one“axis of change”
    25. 25. Single Responsibility Principlean Object should only have one“axis of change”as software requirements shift,refactoring is reflected throughchanges of responsibility in yourcode
    26. 26. Single Responsibility Principlean Object should only have one“axis of change”as software requirements shift,refactoring is reflected throughchanges of responsibility in yourcodecomplex code only gets morecomplex
    27. 27. Single Responsibility Principle
    28. 28. Single Responsibility Principleanti-pattern: watch out forlarge branching statements
    29. 29. Single Responsibility Principleanti-pattern: watch out forlarge branching statementsfavor method simplicity
    30. 30. Single Responsibility Principleanti-pattern: watch out forlarge branching statementsfavor method simplicityshould be apparent when practicingTDD
    31. 31. Open/Closed Principle
    32. 32. Open/Closed Principle“[objects] should be open forextension, but closed formodification”
    33. 33. Open/Closed Principle“[objects] should be open forextension, but closed formodification”makes code that’s more resilientover time
    34. 34. Open/Closed Principle“[objects] should be open forextension, but closed formodification”makes code that’s more resilientover timevery important for maintaininglarge, production codebases
    35. 35. Open/Closed Principle
    36. 36. Open/Closed Principleanti-pattern: modifying nativePrototypes in Javascript
    37. 37. Open/Closed Principleanti-pattern: modifying nativePrototypes in Javascriptused and violated in Backbone.js
    38. 38. Open/Closed Principleanti-pattern: modifying nativePrototypes in Javascriptused and violated in Backbone.jstest coverage alleviates some ofthe pain that open/close want toshield you from
    39. 39. Liskov Substitution
    40. 40. Liskov Substitutionderived types should becompletely substitutable fromtheir base types
    41. 41. Liskov Substitutionderived types should becompletely substitutable fromtheir base typesabout preserving expectations whencreating classes and subclasses
    42. 42. Liskov Substitutionderived types should becompletely substitutable fromtheir base typesabout preserving expectations whencreating classes and subclassesOften this is a built inlanguage feature
    43. 43. Interface Segregation
    44. 44. Interface Segregationfavor many specific interfacesover a single, “fat” interface
    45. 45. Interface Segregationfavor many specific interfacesover a single, “fat” interfacean api should only contains themethods its caller needs
    46. 46. Interface Segregationfavor many specific interfacesover a single, “fat” interfacean api should only contains themethods its caller needsleading cause of FSM, tightlycoupled code
    47. 47. Interface Segregation
    48. 48. Interface SegregationjQuery is written as a series ofseparate interfaces with acommon core
    49. 49. Interface SegregationjQuery is written as a series ofseparate interfaces with acommon coreincreases performance, sanity
    50. 50. Interface SegregationjQuery is written as a series ofseparate interfaces with acommon coreincreases performance, sanity“no client should be forced todepend on code it does not use”
    51. 51. Interface SegregationjQuery is written as a series ofseparate interfaces with acommon coreincreases performance, sanity“no client should be forced todepend on code it does not use”another consequence of TDD
    52. 52. Dependency Inversion
    53. 53. Dependency Inversion“depend on abstractions, not onconcretions.”
    54. 54. Dependency Inversion“depend on abstractions, not onconcretions.”create high-level software that isdecoupled from low-level softwarethrough abstraction
    55. 55. Dependency Inversion“depend on abstractions, not onconcretions.”create high-level software that isdecoupled from low-level softwarethrough abstractionallows for saner, more flexibleresources
    56. 56. Dependency Inversion
    57. 57. Dependency InversionActiveRecord allows Rails toabstract database interface awayfrom users
    58. 58. Dependency InversionActiveRecord allows Rails toabstract database interface awayfrom usersSizzle, $.ajax allows jQuery toabstract low level DOM methods
    59. 59. What does it mean?
    60. 60. What does it mean?You don’t create re-usable codeby accident.
    61. 61. What does it mean?You don’t create re-usable codeby accident.You experience these principlesevery day
    62. 62. What does it mean?You don’t create re-usable codeby accident.You experience these principlesevery dayCreates a good checklist of“objective refactoring” statements
    63. 63. S. Single ResponsibilityO. Open / ClosedL. Liskov SubstitutionI. Interface SegregationD. Dependency Inversion

    ×