Downloaded 320 times
Uploaded bySteven Smith
Refactoring Applications using SOLID Principles
The document outlines strategies for refactoring applications using SOLID principles to enhance code maintainability and reduce duplication. It covers the refactoring process, the importance of automated tests, and provides examples of common refactorings related to each SOLID principle. The principles discussed include Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, accompanied by practical examples and pitfalls.
In this document
Powered by AI
Introduction to refactoring applications based on SOLID principles, presented by Steve Smith from Telerik.
Discusses the importance of refactoring to eliminate duplication, simplify design, and ensure automated tests verify correctness.
Outlines the process of writing characterization tests to ensure existing behaviors are preserved when refactoring.
Introduction to SOLID principles of object-oriented design including DRY (Don't Repeat Yourself) and detailed aspects of each principle.
Introduction to SOLID principles of object-oriented design including DRY (Don't Repeat Yourself) and detailed aspects of each principle.
Lists common refactors such as replacing magic numbers/strings, extracting classes, and addressing excessive coupling.
Describes OCP focusing on software being open for extension but closed for modification, with examples of failure and proper implementation.
LSP states that subtypes must be substitutable for their base types, with examples of violations and corrections.
ISP emphasizes small, cohesive interfaces over fat ones, providing examples of violations and improved design.
DIP discusses how high-level modules should not depend on low-level modules, emphasizing the importance of abstractions.
Overview of application layers, compile/runtime aspects, and common dependencies affecting software architecture.
Discusses common refactorings like extracting classes/interfaces, applying patterns, and enhancing software architecture.
Summarizes key points on maintaining application code, applying SOLID principles, and the importance of tests.
Refactoring Applications using SOLID Principles
- 1. Refactoring Applications using SOLID Principles Steve Smith Telerik ardalis.com @ardalis www.devreach.com
- 2. www.devreach.com
- 4. Preventive Maintenance • Refactoring – Eliminate Duplication – Simplify Design • Automated Tests – Verify correctness – Avoid regressions – Increase Confidence www.devreach.com
- 5. Refactoring Process • Verify existing behavior • Write Characterization Tests if none exist – Find test points – Break dependencies • Apply Refactoring • Confirm existing behavior is preserved www.devreach.com
- 6. Characterization Tests Process 1. Write a test you know will fail 2. Use the output of the failing test to determine the existing behavior to assert 3. Update the test with the new value/behavior 4. Run the test again – it should pass www.devreach.com
- 9. SOLID Principles http://flickr.com/photos/kevinkemmerer/2772526725
- 10. Principles of OODesign 0. Don’t Repeat Yourself (DRY) 1. Single Responsibility 2. Open/Closed 3. Liskov Substitution 4. Interface Segregation 5. Dependency Inversion www.devreach.com
- 12. Don’t Repeat Repeat Yourself • Duplication in logic calls for abstraction • Duplication in process calls for automation www.devreach.com
- 13. Common Refactorings • Replace Magic Number/String • Parameterize Method • Pull Up Field • Pull Up Method • Replace Conditional With Polymorphism • Introduce Method www.devreach.com
- 14. Role Checks if(user.IsInRole(“Admins”) { // allow access to resource } // favor privileges over role checks // ardalis.com/Favor-Privileges-over-Role-Checks var priv = new ContentPrivilege(user, article); if(priv.CanEdit()) { // allow access } www.devreach.com
- 16. Single Responsibility Principle The Single Responsibility Principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. Wikipedia There should never be more than one reason for a class to change. Robert C. “Uncle Bob” Martin www.devreach.com
- 17. Example Responsibilities • Persistence • Validation • Notification • Error Handling • Logging • Class Selection / Construction • Formatting • Parsing • Mapping www.devreach.com
- 18. Dependency and Coupling • Excessive coupling makes changing legacy software difficult • Breaking apart responsibilities and dependencies is a large part of working with existing code www.devreach.com
- 19. Common Refactorings • Extract Class • Move Method www.devreach.com
- 20. Heuristics and CodeSmells • Visual Studio Metrics www.devreach.com
- 21. Code Smell: Regions More on Regions: http://ardalis.com/regional-differences www.devreach.com
- 23. Open / ClosedPrinciple The Open / Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. Wikipedia www.devreach.com
- 24. Open / ClosedPrinciple Open to Extension New behavior can be added in the future Closed to Modification Changes to source or binary code are not required Dr. Bertrand Meyer originated the OCP term in his 1988 book, Object Oriented Software Construction www.devreach.com
- 25. Common Refactorings • Extract Interface / Apply Strategy Pattern • Parameterize Method • Form Template Method www.devreach.com
- 26.
- 27. OCP Fail public bool IsSpecialCustomer(Customer c) { if(c.Country == “US” && c.Balance < 50) return false; if(c.Country == “DE” && c.Balance < 25) return false; if(c.Country == “UK” && c.Balance < 35) return false; if(c.Country == “FR” && c.Balance < 27) return false; if(c.Country == “BG” && c.Balance < 29) return false; if(c.Age < 18 || c.Age > 65) return false; if(c.Income < 50000 && c.Age < 30) return false; return true; } www.devreach.com
- 28. OCP OK private IEnumerable<ICustomerRule> _rules; public bool IsSpecialCustomer(Customer c) { foreach(var rule in _rules) { if(rule.Evaluate(c) == false) return false; } return true; } www.devreach.com
- 30. Liskov Substitution Principle The Liskov Substitution Principle states that Subtypes must be substitutable for their base types. Agile Principles, Patterns, and Practices in C# Named for Barbara Liskov, who first described the principle in 1988. www.devreach.com
- 31. Common Refactorings • Collapse Hierarchy • Pull Up / Push Down Field • Pull Up / Push Down Method www.devreach.com
- 32. Liskov Substitution Fail foreach(var employee in employees) { if(employee is Manager) { Helpers.PrintManager(employee as Manager); break; } Helpers.PrintEmployee(employee); } www.devreach.com
- 33. Liskov Substitution OK foreach(var employee in employees) { employee.Print(); // or Helpers.PrintEmployee(employee); } www.devreach.com
- 35. Interface Segregation Principle The Interface Segregation Principle states that Clients should not be forced to depend on methods they do not use. Agile Principles, Patterns, and Practices in C# Corollary: Prefer small, cohesive interfaces to “fat” interfaces www.devreach.com
- 36. Common Refactorings • Extract Interface www.devreach.com
- 37. ISP Fail (sometimes) public IRepository<T> { T GetById(int id); IEnumerable<T> List(); void Create(T item); void Update(T item); void Delete(T item); } www.devreach.com
- 38. ISP OK (forCQRS for example) public IRepository<T> : IReadRepository<T>, IWriteRepository<T> { } public IReadRepository<T> { T GetById(int id); IEnumerable<T> List(); } public IWriteRepository<T> void Create(T item); void Update(T item); void Delete(T item); } www.devreach.com
- 40. Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. Agile Principles, Patterns, and Practices in C# www.devreach.com
- 41. Dependency Inversion Principle • Depend on Abstractions – Interfaces, not concrete types • Inject Dependencies into Classes • Structure Solution so Dependencies Flow Toward Core – Onion Architecture www.devreach.com
- 42.
- 43. Compile Time Runtime User Interface Database www.devreach.com
- 44. Compile Time Runtime User Interface Helper Class Database www.devreach.com
- 45. Compile Time Runtime User Interface Core Infrastructure IFooRepository SqlFooRepository Database www.devreach.com
- 46.
- 47. Common Dependencies • Framework See also responsibilities: • Third Party Libraries • Persistence • Validation • Database • Notification • File System • Error Handling • Email • Logging • Web Services • Class Selection / Construction • System Resources (Clock) • Formatting • Configuration • Parsing • The new Keyword • Mapping • Static methods • Thread.Sleep • Random www.devreach.com
- 48. Common Refactorings • Extract Class • Extract Interface / Apply Strategy Pattern • Extract Method • Introduce Service Locator / Container www.devreach.com
- 49.
- 50.
- 51.
- 52.
- 53. Summary • Maintain / Improve Application Code • Follow DRY/SOLID Principles • Use Characterization Tests to “fix” behavior • Apply Common Refactorings • Re-run Tests After Refactorings www.devreach.com
- 54. www.devreach.com
- 55. Thank You! –Благодаря! Find Me Online: Blog: http://ardalis.com Twitter: @ardalis http://facebook.com/StevenAndrewSmith www.devreach.com
- 56.
Editor's Notes
- #7 Note that characterization tests, though they should be automated, are often not what we would think of as unit tests, or perhaps even integration tests. For instance, you could dump a log file showing the relevant state of the application, and then use that as the basis for your characterization test by comparing against it after your changes.
- #8 Avoid creating a big ball of mud system, where tracing through your code and its dependencies is like trying to unwind a tangled mess of spaghetti.
- #15 A very common source of repetition of code is role checks. These often describe different scenarios in different circumstances. For instance, maybe administrators can do anything, but managers can access resources within their division, etc. Encapsulating the logic of CanView, CanCreate, CanEdit, etc. in privilege objects makes these rules explicit, easier to test, and gives them a single location to live in the application.
- #21 Visual Studio can quickly analyze a project and show statistics for the classes and methods in the project. The maintainability index, cyclomatic complexity, and lines of code are all great metrics to pay attention to. The ideal maintainability index is 100, but don’t expect to hit that with any code that’s doing real work. However, you should certainly able to keep it above 50.
- #22 I’m not a fan of regions. They mainly exist because at one time they were a reasonable means of hiding generated code, before we had support for partial classes and other language features to deal with this. The worst offense with regions is when they’re used within a method, like this:(click)They’re also bad when used at the class level for “standard” formatting of code, making it impossible to actually see what the code does, like this:(click)Can someone tell me what this class does?(click)I have a whole article devoted to why using regions is a bad habit, anti-pattern, code smell, whatever you prefer. It includes some survey results on the most common ways people use them as well. (click)
- #28 What happens when we need to add another country?What happens when we must add another rule?How can we refactor this so this method no longer needs to change?
- #29 Define a type to describe a rule. Move each rule into its own type. Create a collection of rules to apply and apply them.Pass the set of rules into the IsSpecialCustomer() method’s class (or even the method itself).
- #33 Any time you find that you need to check the type of an object within a polymorphic block of code (such as a foreach), this is a sign that you are breaking LSP.
- #38 This is anextemely common example of the Repository design pattern. In fact, I use this exact pattern in quite a few production applications today. There’s nothing inherently wrong with this implementation on its own. However, sometimes it does violate ISP if you need to separate Commands from Queries
- #39 You can create small interfaces and compose the larger interfaces from the smaller ones if you control all of the code and you can’t simply do away with the larger interfaces. In this case, the separation of interfaces would allow us to do something like implement caching only on the read operations, and implement delayed writes using some kind of queue or message bus for the write operations.
- #52 Extract interfaceImplement interface with tightly coupled original code
- #55 http://en.wikipedia.org/wiki/Template_method_pattern