Agile Evolutionary Design & SOLID Principles

Introduction

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

Typical Evolution of System

Dream system designed to perfection and beauty. Meaning of beauty and perfection are subjective. What does it mean for you?

Typical Evolution of System

Adding features

Typical Evolution of System

Changing features

Birth of Legacy System

Somewhere in near future

Agile Design Process

Beautiful System

Beautiful System

Adding a feature

Clean the mess

We will see some of the techniques which will help us tokeep the system clean in this presentation.

After a period of time

Beautiful System.

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?

XP Practices

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

Sample Application – Reporting AppConcentrate on the principles and not on the app

Reporter App

File

Read the flat file and generate the report

Reporter App

● WriteReport● ReadFile● FormatReport

SOLID Principles

SOLID Principles

● Single Responsibility Principle● Open Closed Principle● Liskov Substitution Principle● Interface Segregation Principle● Dependency Inversion Principle

Single Responsibility Principle

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

Better design applying SRP

Reporter App

File Reader

Report Formatter

CSV File JSON File

Requirement Changes

● Support for more file formats● May be will add more report formats (Graphical etc..)

Open Closed Principle

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

Better design applying OCP

File Reader

CSV File JSON File

File Reader Service

Reporter App(UI + Formatter)

Liskov Substitution Principle

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.

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

LSP Violation

File Reader

CSV File JSON File

File Reader 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

Better design confirming to LSP

File Reader

CSV File JSON File

File Reader Service

Reporter (UI + Formatter)Database Database Reader Service

Keep Database separate as it doesn't fit in File Reader Service

Interface Segregation Principle

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)

ISP Violation

Better design confirming to ISP

● WriteReport● ReadFile● FormatReport

ReporterReporter

FormatReport

Report Formatter

WriteReport

Report Writer

GetData

FileReaderService

GetData

DatabaseReaderServiceInitial Interface

Current Interface

Dependency Inversion Principle

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

DIP Violation

Text Report Formatter

Reporting App

CSV File Reader

JSON File Reader

Stuck with CSV File Reader andText Report Formatter implementations !!!

Arrows are Dependency

Fixing for DIP

Text Report Formatter

Reporting App

CSV Data Extractor

JSON Data Extractor

IFormatReport

IExtractReportData

Design confirming to DIP

IExtractReportData

CSV Data Extractor

JSON Data Extractor

Data Extractor Service Reporter WriterDatabase Reader Service

XML Data Extractor

Reporting Application

Report Data

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

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

Thank you