Your SlideShare is downloading. ×
  • Like
Evolutionary Design Solid
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Evolutionary Design Solid


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

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

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


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