Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Establishing a SOLID Foundation - An Intro to Software Design

129 views

Published on

Are you tired of opening classes that have hundreds or thousands of lines of code? Do you feel that you spend too much time trying to understand how something (that should be simple) in your application works? Are you frustrated with following spaghetti-like logic through your code's core?

In this presentation, we're going to examine a set of design principles that yield easy-to-read, decoupled code referred to as SOLID. To start, we'll explore the history of SOLID and establish the problems it solves. From there, we'll dive into the different principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion) by defining what each principle means, how to spot violations, and how to resolve them. Intended for developers wanting to learn more about software design, by the end of the presentation, you should be able to describe what SOLID code is. In addition, you should also be able to spot trouble areas in your codebase and have the tools to undo the damage
Prerequisites

Familiarity with an object-oriented language (like .NET or Java)

Published in: Software
  • Be the first to comment

Establishing a SOLID Foundation - An Intro to Software Design

  1. 1. Establishing a SOLID Foundation An Intro To Software Design Cameron Presley @PCameronPresley http://blog.thesoftwarementor.com
  2. 2. Outline • What is SOLID? • Why should our code be SOLID? • Exploring the SOLID principles • Additional Resources
  3. 3. What is SOLID? • 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 (Uncle Bob) in Agile Principles, Patterns, and Practices
  4. 4. What is SOLID? Single Responsibility Open/Closed Liskov Substitution Interface Segregation Dependency Inversion
  5. 5. Doing Too Much Bad Abstractions
  6. 6. Why Should We Write SOLID Code?
  7. 7. Reading vs Writing
  8. 8. Overdesign is the root cause of issues
  9. 9. Time-to-Context
  10. 10. Who Maintains The Code Once You Leave?
  11. 11. Optimize for time-to-context
  12. 12. What are signs of SOLID Code?
  13. 13. Many small classes composed into larger classes
  14. 14. Easy to test
  15. 15. Exploring the SOLID Principles
  16. 16. Single Responsibility Principle
  17. 17. A class should have one reason to change
  18. 18. Why It’s a Problem • Large classes are hard to test and to maintain • If multiple developers need to work on the class at the same time…
  19. 19. How to Spot Classes can be measured in hundreds (or thousands) of LOCs
  20. 20. How to Spot 27 public methods
  21. 21. How to Spot Single public method with 54 private methods
  22. 22. How to Fix • Break large methods down into smaller methods • Move private methods to new classes • Instantiate and use the new classes
  23. 23. Single Responsibility Principle Summary • Classes should only have one reason to change • By breaking classes down into smaller pieces, it allows us to work on the separate pieces of functionality • Combine just-what-we need functionality into new classes
  24. 24. Dependency Inversion Principle
  25. 25. Dependency Inversion Principle Classes should depend upon abstractions Classes shouldn’t be responsible for creating their own dependencies
  26. 26. Why it’s a problem • 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)
  27. 27. How to Fix • Two goals • Make sure the dependency can be passed in • Make sure the dependency has an abstraction • If the class is static, make it not static • If the class doesn’t have an interface, define one • Inject the dependency using constructor injection or method injection
  28. 28. Static Classes • Issues with static classes • Can’t pass them as parameters • Can’t implement an interface or base class • 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
  29. 29. Working With Static Classes
  30. 30. Introducing the Wrapper
  31. 31. Passing Dependencies Constructor vs Method Injection “Will this dependency need to change during the object’s lifetime?”
  32. 32. Passing Dependencies
  33. 33. Passing Dependencies
  34. 34. Dependency Inversion Principle Summary • Classes should depend upon abstractions • Allows us to switch dependencies at runtime • Useful for testing • Use the Wrapper pattern to handle static classes • Use method injection or constructor injection for passing dependencies
  35. 35. Writing SOLID Code 80% of issues with these two principles The remaining principles cover the additional 20%
  36. 36. Open/Closed Principle
  37. 37. Calculating Shipping Costs
  38. 38. Adding a new rule
  39. 39. Open/Closed Principle • Classes should be open for extension, closed for modification • Means that we should add new functionality by adding new classes, not modifying existing ones • NOTE: Doesn’t mean that we can’t modify a class to fix bugs
  40. 40. Why it’s a problem • 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
  41. 41. How to Fix • Refactor to Factory Pattern • Each logic branch is a class • Original class becomes the Factory that returns a concrete class • Update clients to use the Factory instead
  42. 42. Need To Add a Calculator? • Create the class • Implement IShippingCalculator interface • Implement business rules • Update the factory to return the correct calculator
  43. 43. Open/Closed Principle Summary • Classes should be open for extension, closed for modification • Abstractions allow us to extend our app without breaking something downstream • Allows us to add additional functionality by creating new classes, not modifying pre-existing ones
  44. 44. Liskov Substitution Principle
  45. 45. New Requirement - EBooks
  46. 46. • Type casting to perform logic is a bad abstraction • “Leaky Abstractions” • Can’t lean on the compiler for error finding
  47. 47. Not all Books are created equally What if we changed our abstraction?
  48. 48. Liskov Substitution Principle • 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
  49. 49. LSP – Resolving Violations • Some cases, the abstraction doesn’t make sense • Makes sense to find a better abstraction • If possible, move special logic to the offending class
  50. 50. Liskov Substitution Principle Summary • Two classes derived from the same abstraction should be interchangeable • Shouldn’t have to add special handling code in the client • Try to find a better abstraction or move offending logic to the specific class
  51. 51. Interface Segregation Principle
  52. 52. Adding Books to an Order
  53. 53. Problem?
  54. 54. Shape our abstraction to roles, not a list of everything it can do
  55. 55. • One role is to track inventory when an order is made • Define an interface with the methods required • Have the InventoryManager class implement • Update client code to use the new interface
  56. 56. Interface Segregation Principle Summary • Clients should only have access to methods and properties that they need • Use role interfaces, not header interfaces • Similar to Single Responsibility, break down large interfaces into smaller ones and update the client accordingly
  57. 57. Summary • What is SOLID? • Why should our code be SOLID? • What the principles stand for • How to spot violations • How to fix them • Doing Too Much & Bad Abstractions
  58. 58. Resources • Books • 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 • Videos • SOLID Principles of Object Oriented Design by Steve Smith • Articles • Role Interfaces by Martin Fowler
  59. 59. Contact Information • Email: Cameron@TheSoftwareMentor.com • Twitter: @PCameronPresley • Blog: http://blog.thesoftwarementor.com

×