The document focuses on agile evolutionary design and the SOLID principles, outlining typical and agile design processes. It explains the significance of each SOLID principle—Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion—emphasizing their importance in creating clean, maintainable software. The presentation concludes with practical examples and insights from the author's experience in software development.

1. Agile Evolutionary Design & SOLID
Principles

2. Introduction
● Typical Design Process
● Agile Design Process
● SOLID principles
● And coding time :)
● Questions anytime.

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. Typical Evolution of System
Adding features

5. Typical Evolution of System
Changing features

6. Birth of Legacy System
Somewhere in near future

7. Agile Design Process

8. Beautiful System
Beautiful System

9. Adding a feature

10. Clean the mess
We will see some of the techniques which will help us to
keep the system clean in this presentation.

11. After a period of time
Beautiful System.

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. XP Practices

14. But at code level what helps to create simple and
evolutionary design?

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. SOLID Principles

17. SOLID Principles
● Single Responsibility Principle
● Open Closed Principle
● Liskov Substitution Principle
● Interface Segregation Principle
● Dependency Inversion Principle

18. Single Responsibility Principle

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. 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. Open Closed Principle

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. Better design applying OCP
Reporter App
(UI + Formatter)
File Reader Service
File Reader
CSV File JSON File

24. Liskov Substitution Principle

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. 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. 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. 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. Interface Segregation Principle

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. ISP Violation

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. Dependency Inversion Principle

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. 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. Fixing for DIP
Reporting App
IFormatReport
Text Report Formatter
IExtractReportData
JSON Data CSV Data
Extractor Extractor

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. 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. 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. Thank you