Evolutionary Design Solid


Published on

Presentation on Agile Evolutionary Design and SOLID principles given at Agile NCR.

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Evolutionary Design Solid

  1. 1. Agile Evolutionary Design & SOLID Principles
  2. 2. Introduction <ul><li>Typical Design Process
  3. 3. Agile Design Process
  4. 4. SOLID principles
  5. 5. And coding time :)
  6. 6. Questions anytime. </li></ul>
  7. 7. Typical Evolution of System Dream system designed to perfection and beauty. Meaning of beauty and perfection are subjective. What do those mean for you?
  8. 8. Typical Evolution of System Adding features
  9. 9. Typical Evolution of System Changing features
  10. 10. Birth of Legacy System Somewhere in near future
  11. 11. Agile Design Process
  12. 12. Beautiful System Beautiful System
  13. 13. Adding a feature
  14. 14. Clean the mess We will see some of the techniques which will help us to keep the system clean in this presentation.
  15. 15. After a period of time Beautiful System.
  16. 16. What is Agile Design? <ul><li>Not doing things upfront like having an interface for every class we write (speculative generalization) or writing a system to dynamically load the components.
  17. 17. Not doing an anticipatory design
  18. 18. But still setting a stage for design to evolve for tomorrow </li><ul><li>But what helps to set the stage? </li></ul></ul>
  19. 19. XP Practices
  20. 20. But at code level what helps to create simple and evolutionary design?
  21. 21. Sample Application – Reporting App Concentrate on the principles and not on the app Read the flat file and generate the report Reporter App <ul><li>WriteReport
  22. 22. ReadFile
  23. 23. Extract Data
  24. 24. FormatReport </li></ul>Reporter App File
  25. 25. SOLID Principles
  26. 26. SOLID Principles <ul><li>Single Responsibility Principle
  27. 27. Open Closed Principle
  28. 28. Liskov Substitution Principle
  29. 29. Interface Segregation Principle
  30. 30. Dependency Inversion Principle </li></ul>
  31. 31. Single Responsibility Principle
  32. 32. Single Responsibility Principle <ul><li>A class should have one, and only one, reason to change.
  33. 33. Or a class should not handle more than one responsibility
  34. 34. Design smell – Class changed when unrelated responsibilities change. High afferent coupling? Or multiple classes changed when a responsibility changes. High Efferent Coupling?
  35. 35. Shotgun surgery and divergent change
  36. 36. If it is not possible to separate the responsibilities at least show the presence of multiple roles played by the object.
  37. 37. Applies not just for classes but also for modules, functions as well
  38. 38. Better cohesion, encapsulation and less coupled design </li></ul>
  39. 39. Better design applying SRP Requirement Changes <ul><li>Support for more data formats
  40. 40. May be will add more report formats (Graphical etc..) </li></ul>Reporter App Report Data Extractor Report Formatter CSV Format JSON Format
  41. 41. Open Closed Principle
  42. 42. Open Closed Principle <ul><li>You should be able to extend software entities (Classes, Modules, Functions, etc.), without modifying them.
  43. 43. Design smell - Change ripples through code base.
  44. 44. Abstraction and polymorphism are the key.
  45. 45. Chain of responsibility, Strategy pattern, Aspects...
  46. 46. Separate creation from usage of objects.
  47. 47. No module is 100% closed (Open/Closed/Open principle)
  48. 48. Easy to lead to anticipatory design. Better to burn finger at least once.
  49. 49. Service and framework interface follow OCP. Open for extension, closed for modification </li></ul>
  50. 50. Better design applying OCP Report Data Extractor CSV Format JSON Format Report Data Extractor Service Reporter App (UI + Formatter)
  51. 51. Liskov Substitution Principle
  52. 52. Liskov Substitution Principle <ul>Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T. </ul>
  53. 53. Liskov Substitution Principle <ul><li>Functions that use references to base classes must be able to use objects of derived classes without knowing it.
  54. 54. Used when inheritance was a main form of reuse.
  55. 55. Design smell – Type checking in client code and changing the behavior for a specific type in client.
  56. 56. Due to forcing an unrelated object into an inheritance hierarchy
  57. 57. Prefer composition over inheritance whenever possible </li></ul>
  58. 58. LSP Violation Data Extractor CSV Format JSON Format Data Extractor Service Reporter (UI + Formatter) Database New Requirement - Adding Database as a data source for report data. Adding it to File Reader Service as it is conveniently there
  59. 59. Better design confirming to LSP File Reader CSV File JSON File File Data Extractor Service Reporter (UI + Formatter) Database Database Data Extractor Service Keep Database separate as it doesn't fit in File Data Extractor Service
  60. 60. Interface Segregation Principle
  61. 61. Interface Segregation Principle <ul><li>Clients should not be forced to depend on interface they don't use. </li></ul><ul><li>Make fine grained interfaces that are client specific or clients should not be forced to implement interfaces they don't need
  62. 62. Design smell – NotImplementException thrown for some methods (which are really not needed by the client)
  63. 63. Flat and non cohesive interface problem - SRP?
  64. 64. Role based interface design – Intent Revealing Interfaces by Udi Dahan ( IExtractReportData ) </li></ul>
  65. 65. ISP Violation
  66. 66. Better design confirming to ISP Initial Interface Current Interface <ul><li>WriteReport
  67. 67. ReadFile
  68. 68. FormatReport </li></ul>Reporter Reporter FormatReport Report Formatter <ul>WriteReport </ul>Report Writer GetData FileDataExtractor GetData DatabaseDataExtractor
  69. 69. Dependency Inversion Principle
  70. 70. Dependency Inversion Principle <ul><li>High level modules should not depend upon low level modules. Both should depend upon abstractions
  71. 71. Abstractions should not depend upon details. Details should depend upon abstractions
  72. 72. Design smell – Unable to change the choice of implementation & code untestable in isolation
  73. 73. Classic - Code for an interface not for an implementation </li></ul><ul><li>DI frameworks to the rescue if object graph is complex
  74. 74. Less coupled design </li></ul>
  75. 75. DIP Violation Stuck with Text Format and Text Report Formatter implementations !!! Arrows are Dependency Text Report Formatter Reporting App Text Format JSON Format
  76. 76. Fixing for DIP Text Report Formatter Reporting App CSV Format JSON Format IFormatReport IExtractReportData
  77. 77. Design confirming to DIP IExtractReportData CSV Data Extractor JSON Data Extractor Data Extractor Service Reporter Writer Database Reader Service XML Data Extractor Reporting Application Report Data
  78. 78. Credits <ul><li>SOLID Motivational Posters, by Derick Bailey, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
  79. 79. Uncle Bob for consolidating these principles and his books Agile Software Development: Principles, Practices and Patterns and Clean Code
  80. 80. Presentation is under Creative Commons Attribution-Share Alike 2.5 India License </li></ul>
  81. 81. About Me <ul><li>Developer in Test at Thoughtworks
  82. 82. Interested in OO, DDD, Functional Programming languages, Agile, Lean, TDD, Mocks, Automated Testing, ATDD.....
  83. 83. Author and maintainer of ChromeWatir and FireDriver
  84. 84. Places to find me - </li><ul><li>http://developer-in-test.blogspot.com
  85. 85. http://twitter.com/sai_venkat
  86. 86. http://github.com/saivenkat </li></ul></ul>
  87. 87. Thank you