Evolutionary Design Solid


Published on

This ppt.is presented by Sai Venkatakrishnan (Developer in test at Thoughtworks) at Agile NCR 2009 Conference held on 18th July at Park Premier Hotel.

Published in: Technology, Business
  • 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 ● Typical Design Process ● Agile Design Process ● SOLID principles ● And coding time :) ● Questions anytime.
  3. 3. Typical Evolution of System Dream system designed to perfection and beauty. Meaning of beauty and perfection are subjective. What does it mean for you?
  4. 4. Typical Evolution of System Adding features
  5. 5. Typical Evolution of System Changing features
  6. 6. Birth of Legacy System Somewhere in near future
  7. 7. Agile Design Process
  8. 8. Beautiful System Beautiful System
  9. 9. Adding a feature
  10. 10. Clean the mess We will see some of the techniques which will help us to keep the system clean in this presentation.
  11. 11. After a period of time Beautiful System.
  12. 12. 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. ● Not doing an anticipatory design ● But still setting a stage for design to evolve for tomorrow But what helps to set the stage?
  13. 13. XP Practices
  14. 14. But at code level what helps to create simple and evolutionary design?
  15. 15. Sample Application – Reporting App Concentrate on the principles and not on the app Reporter App Reporter App ● WriteReport ● ReadFile ● FormatReport File Read the flat file and generate the report
  16. 16. SOLID Principles
  17. 17. SOLID Principles ● Single Responsibility Principle ● Open Closed Principle ● Liskov Substitution Principle ● Interface Segregation Principle ● Dependency Inversion Principle
  18. 18. Single Responsibility Principle
  19. 19. Single Responsibility Principle ● A class should have one, and only one, reason to change. ● Or a class should not handle more than one responsibility ● Design smell – Class changed when unrelated responsibilities change. High afferent coupling? Or multiple classes changed when a responsibility changes. High Efferent Coupling? ● Shotgun surgery and divergent change ● If it is not possible to separate the responsibilities at least show the presence of multiple roles played by the object. ● Applies not just for classes but also for modules, functions as well ● Better cohesion, encapsulation and less coupled design
  20. 20. Better design applying SRP Reporter App Requirement Changes ● Support for more file formats ● May be will add more report Report Formatter formats (Graphical etc..) File Reader CSV File JSON File
  21. 21. Open Closed Principle
  22. 22. Open Closed Principle ● You should be able to extend software entities (Classes, Modules, Functions, etc.), without modifying them. ● Design smell - Change ripples through code base. ● Abstraction and polymorphism are the key. ● Chain of responsibility, Strategy pattern, Aspects... ● Separate creation from usage of objects. ● No module is 100% closed (Open/Closed/Open principle) ● Easy to lead to anticipatory design. Better to burn finger at least once. ● Service and framework interface follow OCP. Open for extension, closed for modification
  23. 23. Better design applying OCP Reporter App (UI + Formatter) File Reader Service File Reader CSV File JSON File
  24. 24. Liskov Substitution Principle
  25. 25. 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.
  26. 26. Liskov Substitution Principle ● Functions that use references to base classes must be able to use objects of derived classes without knowing it. ● Used when inheritance was a main form of reuse. ● Design smell – Type checking in client code and changing the behavior for a specific type in client. ● Due to forcing an unrelated object into an inheritance hierarchy ● Prefer composition over inheritance whenever possible
  27. 27. LSP Violation Database File Reader Service Reporter (UI + Formatter) File Reader CSV File JSON File New Requirement - Adding Database as a data source for report data. Adding it to File Reader Service as it is conveniently there
  28. 28. Better design confirming to LSP Database Database Reader Service Reporter (UI + Formatter) File Reader Service Keep Database separate as it doesn't fit in File Reader Service File Reader CSV File JSON File
  29. 29. Interface Segregation Principle
  30. 30. 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 ● Design smell – NotImplementException thrown for some methods (which are really not needed by the client) ● Flat and non cohesive interface problem - SRP? ● Role based interface design – Intent Revealing Interfaces by Udi Dahan (IExtractReportData)
  31. 31. ISP Violation
  32. 32. Better design confirming to ISP Reporter Report Writer FileReaderService ● WriteReport ● ReadFile WriteReport GetData ● FormatReport Report Formatter DatabaseReaderService Initial Interface FormatReport GetData Current Interface
  33. 33. Dependency Inversion Principle
  34. 34. Dependency Inversion Principle ● High level modules should not depend upon low level modules. Both should depend upon abstractions ● Abstractions should not depend upon details. Details should depend upon abstractions ● Design smell – Unable to change the choice of implementation & code untestable in isolation ● Classic - Code for an interface not for an implementation ● DI frameworks to the rescue if object graph is complex ● Less coupled design
  35. 35. DIP Violation Reporting App Text Report Formatter JSON File Reader CSV File Reader Stuck with CSV File Reader and Text Report Formatter implementations !!! Arrows are Dependency
  36. 36. Fixing for DIP Reporting App IFormatReport Text Report Formatter IExtractReportData JSON Data CSV Data Extractor Extractor
  37. 37. Design confirming to DIP XML Data CSV Data JSON Data Extractor Extractor Extractor IExtractReportData Database Reader Service Data Extractor Service Reporter Writer Report Data Reporting Application
  38. 38. Credits ● SOLID Motivational Posters, by Derick Bailey, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License. ● Uncle Bob for consolidation of these principles and his books Agile Software Development: Principles, Practices and Patterns and Clean Code ● Presentation is under Creative Commons Attribution-Share Alike 2.5 India License
  39. 39. About Me ● Developer in Test at Thoughtworks ● Interested in OO, DDD, Functional Programming languages, Agile, Lean, TDD, Mocks, Automated Testing, ATDD..... ● Author and maintainer of ChromeWatir and FireDriver ● Places to find me - ● http://developer-in-test.blogspot.com ● http://twitter.com/sai_venkat ● http://github.com/saivenkat
  40. 40. Thank you