Establishing a SOLID Foundation
•Download as PPTX, PDF•
3 likes•364 views
This document discusses the SOLID principles of object-oriented design. It introduces each principle - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion - and provides examples of how to identify violations of the principles in code and refactor to improve code quality and maintainability. Specific refactoring techniques demonstrated include extracting classes, using factories and dependency injection, and defining role interfaces.
Recommended
More Related Content
What's hot
Similar to Establishing a SOLID Foundation
Similar to Establishing a SOLID Foundation (20)
More from Cameron Presley
More from Cameron Presley (6)
Recently uploaded
Recently uploaded (20)
Establishing a SOLID Foundation
- 1. Cameron Presley @pcameronpresley Cameron@TheSoftwareMentor.com Establishing a SOLID Foundation An Intro to Software Design Slides can be found at: http://blog.TheSoftwareMentor.com/Presentations/#SOLID
- 4. @pcameronpresley Mnemonic for a set of principles that allows us to write easier to maintain code Concepts aren’t new (late 80’s) Introduced by Robert C. Martin in Agile Principles, Patterns, and Practices 4
- 5. @pcameronpresley Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion 5
- 18. @pcameronpresley A class should have one reason to change 18
- 20. @pcameronpresley Classes can be measured in hundreds (or thousands) of LOCs 20
- 22. @pcameronpresley Single public method with 54 private methods 22
- 25. @pcameronpresley 25 1. Break large methods down to smaller methods 2. Move private methods to new classes 3. Instantiate/use new classes
- 27. @pcameronpresley Classes should depend upon abstractions Classes shouldn’t be responsible for creating their own dependencies 27
- 29. @pcameronpresley Only way to change dependencies is to change the class Impossible to write unit tests that cross system boundaries Provides another way to determine if a class is doing too much (32 dependencies) 29
- 33. @pcameronpresley Two Goals 33 1. Make sure the dependency can be passed 2. Make sure the dependency has an abstraction
- 34. @pcameronpresley First Steps 34 1. If the class is static, make it not static 2. If the class doesn’t have an abstraction, define one
- 35. @pcameronpresley Final Step 35 1. Inject the dependency using constructor injection or method injection
- 37. @pcameronpresley Problem with Static Classes 37 Can’t pass them as parameters Can’t implement an interface or base class
- 38. @pcameronpresley Removing Static Cling 38 Removing the static attribute is ideal, but not always possible Using the Wrapper pattern, we can define another class that is not static to wrap around the static and then pass that around
- 41. @pcameronpresley Passing Dependencies 41 Constructor vs Method Injection “Will this dependency need to change during the object’s lifetime?”
- 46. @pcameronpresley 80% of issues come from these two principles Remaining principles cover the additional 20% 46
- 50. @pcameronpresley Classes should be open for extension, closed for modification 50
- 51. @pcameronpresley Add new functionality by adding new classes, not modifying existing ones 51
- 53. @pcameronpresley Modifying a class to add functionality can break something downstream OCP forces us to add functionality by creating new classes and then using an abstraction Safer to create a new class and inject the behavior 53
- 54. @pcameronpresley Modifying a class to add functionality can break something downstream OCP forces us to add functionality by creating new classes and then using an abstraction Safer to create a new class and inject the behavior 54
- 55. @pcameronpresley Modifying a class to add functionality can break something downstream OCP forces us to add functionality by creating new classes and then using an abstraction Safer to create a new class and inject the behavior 55
- 57. @pcameronpresley 57 1. Refactor to Factory Pattern 2. Original class becomes the Factory 3. Update clients to use the Factory instead
- 63. @pcameronpresley Adding a New Calculator 63 1. Create the class 2. Implement IShippingCalculator interface 3. Implement business rules 4. Update the factory to return the correct calculator
- 71. @pcameronpresley Type casting to perform logic is a bad abstraction “Leaky Abstractions” Can’t lean on the compiler for error finding 71
- 73. @pcameronpresley Not all Books are created equally What if we changed our abstraction? 73
- 76. @pcameronpresley If two classes are derived from the same abstraction, then they should be interchangeable Should not depend upon the class of the abstraction to do work 76
- 82. @pcameronpresley Can find out what “can” be done, not what “should” be done Header vs Role Interface Shape abstractions based on roles 82
- 84. @pcameronpresley 84 1. One role to track inventory when an order is made 2. Define an interface with required methods 3. Update InventoryManager so that it implements the new interface 4. Update client code to use the new interface
- 88. @pcameronpresley
- 89. @pcameronpresley 89 • What is SOLID? • Why should our code be SOLID? • What do the principles stand for? • How to spot issues? How to fix them? • Doing Too Much and Bad Abstractions
- 91. @pcameronpresley Agile Principles, Patterns, and Practices by Robert C. Martin Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin Working Effectively With Legacy Code by Michael Feathers Refactoring by Martin Fowler SOLID Principles of Object Oriented Design by Steve Smith Role Interfaces by Martin Fowler https://blog.TheSoftwareMentor.com/presentations/#SOLID 91
Editor's Notes
- What is SOLID? Why Should Our Code Be SOLID? Exploring the SOLID principles Additional Resources
- What is SOLID?
- Why is this a good idea?
- Spend most of your time reading?
- Or writing?
- Optimize for Time-To-Context (i.e. how long does it take to read code before understanding what it does?)
- Who maintains the code once you leave?
- Optimize for Time-To-Context (i.e. how long does it take to read code before understanding what it does?)
- Extract to methods!
- Extract to classes!
- How Do We Spot Errors?
- How do we fix this?
- Optimize for Time-To-Context (i.e. how long does it take to read code before understanding what it does?)
- How do we fix this?
- Optimize for Time-To-Context (i.e. how long does it take to read code before understanding what it does?)
- How do we fix this?
- Optimize for Time-To-Context (i.e. how long does it take to read code before understanding what it does?)
- How do we fix this?
- Optimize for Time-To-Context (i.e. how long does it take to read code before understanding what it does?)
- How do we fix this?
- Wrapping Things Up