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
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
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
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
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
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
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
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?)