The Solid Principles

2,984 views

Published on

My presentation slides from the recent Reading Geek Night event

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,984
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
73
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • What is SOLID
  • Collection of object orientated design best practicesSpaghetti code often due to poor dependency management
  • Collection of object orientated design best practicesSpaghetti code often due to poor dependency management
  • 0
  • SRP
  • The Solid Principles

    1. 1. The SOLID Principles<br />Reading Geek Night<br />
    2. 2. My digital identity<br />Blog: http://blog.lukesmith.net<br />Twitter: @lukesmith<br />
    3. 3. What the?<br />An acronym of acronyms<br />Collection of best-practices<br />loose-coupling<br />Maintainability<br />Principles – not Rules<br />Focus on dependency management<br />
    4. 4. Dependency management<br />Poor dependency management<br />Hard to change<br />Fragile<br />Non-reusable<br />Good dependency management<br />Flexible<br />Robust<br />Reusable<br />
    5. 5. Single Responsibility Principle<br />A class should have one, and only one, reason to change<br />
    6. 6. Single Responsibility Principle<br />Benefits<br />More readable code<br />More robust<br />More maintainable<br />Smaller functions<br />
    7. 7. Open Closed Principle<br />Software entities should be open for extension, but closed for modification<br />
    8. 8. Open Closed Principle<br /><ul><li>Change to an entity cascades changes to dependent modules
    9. 9. Fragile
    10. 10. Unpredictable
    11. 11. Modules should never change
    12. 12. Extend behaviour – add new code
    13. 13. Don’t change existing working code</li></li></ul><li>Liskov Substitution Principle<br />Derived classes must be substitutable for their base classes<br />
    14. 14. Liskov Substitution Principle<br /><ul><li>Important for any program conforming to OCP
    15. 15. Caller should not be surprised by substituting base type for subtype
    16. 16. Virtual members must exist in derived classes
    17. 17. Must do useful + expected work</li></li></ul><li>Liskov Substitution Principle<br /><ul><li>Useful work
    18. 18. Must be implemented
    19. 19. Expected work
    20. 20. Should keep behaviour of base class</li></li></ul><li>Interface Segregation Principle<br />Make fine grained interfaces that are client specific<br />
    21. 21. Interface Segregation Principle<br />Deals with disadvantage of “fat” interfaces<br />Clients forced to depend on interfaces they don’t use subjected to changes in that interface<br />MembershipProvider – forces 27 methods/properties<br />Benefits<br />Lower coupling – better maintainability<br />Higher cohesion – better robustness<br />
    22. 22. Dependency Inversion Principle<br />Depend on abstractions, not concretions<br />
    23. 23. Dependency Inversion Principle<br />Modules should not depend on modules implementing details<br />Depend on abstractions<br />
    24. 24. Dependency Inversion Principle<br />
    25. 25. Further info<br />http://www.butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod<br />

    ×