WRITING S.O.L.I.D CODERAJEEV N B

RAJEEV N B

2

Developer at ThoughtWorks

Blogs at www.rajeevnb.com

@rbharshetty - Twitter

@rshetty - Github

XP

3

This is me doing XP

4

IN THE BEGINNING

5

YOUR APPLICATION WAS PERFECT

THEN SOMETHING HAPPENED

6

YOUR APPLICATION CHANGED

7

DESIGN TO THE RESCUE

8

DESIGN ?

9

It is all about managing your DEPENDENCIES

10

DEPENDENCIES

11

Client Dependent on Logger

DEPENDENCIES

12

DEPENDENCY MANAGEMENT

• Controlling interdependencies among various software

entities

• As interdependencies increase, Reusability, Flexibility

and Maintainability of your applications decrease

• Unmanaged dependencies lead to “Dependency Hell”

13

DEPENDENCY HELL

14

SUCCESSFUL DESIGN

• INCREASED COHESION

• DECREASED COUPLING

• SUPPORTS REUSE

• TESTABLE

• FLEXIBLE

15

DESIGN STAMINA

16

SOFTWARE ROTS

17

WHY DOES SOFTWARE ROT ?

• Changing requirements

• Improper Design

• No Continuos Design - Refactoring

• Limited Project Resources

• Complexity

18

ROBERT MARTIN

19

Design Principles and Design Patterns

SYMPTOMS OF ROTTING SOFTWARE

• RIGIDITY

• FRAGILITY

• IMMOBILITY

• VISCOSITY

20

RIGIDITY

21

22

RIGIDITY

• Difficult to change

• Cascading of Changes in Dependent Modules

• Impact of change cannot be predicted

• Thus, It can’t be estimated

• Time and Cost can’t be quantified

23

FRAGILITY

24

25

FRAGILITY

• Break many places when changed

• Errors appear in areas unrelated to changed areas

• Quality is unpredictable

• Development Team Credibility Loss

• Sometimes breakage increases with time

26

IMMOBILITY

27

28

IMMOBILITY

• Inability to reuse Software Components

• Lack of reusable modules

• Desirable parts of the system dependent on

undesirable parts

• Work and risk of extracting greater than cost of

writing it from scratch

29

VISCOSITY

30

31

VISCOSITY

• VISCOSITY OF DESIGN

• VISCOSITY OF ENVIRONMENT

32

VISCOSITY OF DESIGN

• Design Preserving methods are harder than Hacks

• Easy to do Wrong thing but harder to do right thing

• As time progresses, it will become increasingly difficult to

continue developing the application

33

VISCOSITY OF ENVIRONMENT

• Development Environment is slow and inefficient

• Slower feedback

Ex: Longer compile times, Slower builds, Long running tests

34

PREVENTING SOFTWARE ROT

• Refactoring (Continuos Improvement of Design)

• Testing (Unit/Integration/Contract tests)

• Code Reviews

• Documentation

• Design Principles

• Simplicity

35

OO DESIGN PRINCIPLES

36

S.O.L.I.D

37

Single Responsibility Principle

Open/Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

SINGLE RESPONSIBILITY

38

39

40

A software entity should have one and only one

reason to change

BEFORE

41

AFTER

42

Why is it important to separate these two

responsibilities into separate classes ?

• Each responsibility is an axis of change

• Changes in one responsibility may affect another

• Coupling among classes leads to Fragile Design

43

SIGNS ?

44

• Description of class ( and/or ) • Rigidity and Fragility in code

BENEFITS ?

45

• Reduced Coupling • Separation of Concerns • Better readability • Your code evolves cleanly (Maintainable)

OPEN/CLOSED

46

47

48

Software entities should be closed for modification but

open for extension

OCP

49

Add functionality by adding new code, not

by modifying old code

ABSTRACTION IS THE KEY

50

• Client/Server relationship is open • Changes in Server cause changes in the

client

ABSTRACTION IS THE KEY

51

• Client/Server relationship is closed • Abstract Servers close clients to changes in

implementation

BEFORE

52

AFTER

53

SIGNS ?

54

● Switch cases littered all over your application

● Hunt and replace policy

BENEFITS ?

55

• Reusability

• Maintainability

• Flexible design

DESIGN BY CONTRACT

56

• Methods of class define pre-conditions and

post-conditions

• The preconditions must be met for method

to execute

• Upon completion, method guarantees that

the post conditions are met

DESIGN BY CONTRACT

57

LISKOV SUBSTITUTION

58

59

Sub-types must be substitutable for their

base- types

When is something Substitutable ?

60

Requires No Less Promises No More

61

ELLIPSE/CIRCLE

62

ELLIPSE/CIRCLE

63

● Violation of LSP

● Circle violates the post conditions

● Circle not substitutable for Ellipse

BEFORE

64

AFTER

65

SIGNS ?

66

• Explicit Checking type of a class in the code

• Derived types not substitutable for the base

types

BENEFITS ?

67

• Ability to re-use code increases • Flexible code

INTERFACE SEGREGATION

68

69

70

Clients should not be forced to depend on methods it

does not use

BEFORE

71

AFTER

72

SIGNS ?

73

● Client requiring things it does not need

● Methods littered with “NotImplemented”

exceptions

BENEFITS ?

74

• Lot of small, focused interfaces • Flexible design

DEPENDENCY INVERSION

75

76

77

Depend upon Abstractions not upon Concretions

DIP

78

• High Level Modules should not depend on low level modules, Both should depend on Abstractions

• Abstractions should not depend on details. Details should depend on abstractions.

BEFORE

79

AFTER

80

BEFORE

81

AFTER

82

SIGNS ?

83

● High level modules are harder to reuse

● Changes in the lower level modules directly

affect the higher level modules

ADVANTAGES ?

84

• Reusable modules • Easier to extend • Low Coupled code

KENT BECK

85

4 Simple Design Rules

PASSES TESTS

86

87

PASSES TESTS

88

● Unit tests with Red, Green, Refactor cycles

● Tests help communicate Design

REVEALS INTENTION

89

90

REVEALS INTENTION

91

● Self Documenting code

● Meaningful names to software entities

● Clear code

NO DUPLICATION

92

93

NO DUPLICATION

94

● Once and only once

● DRY

FEWEST ELEMENTS

95

96

FEWEST ELEMENTS

97

● No Superfluous parts/elements

● YAGNI

● KISS

● Minimum number of classes/methods

98

WRAPPING UP

99

● SRP - One responsibility per class

● OCP - Extend not modify

● LSP - Derived substitutable for base

● ISP - Split into Focussed interfaces

● DIP - Depend on Abstractions

REFERENCES

100

● Design Principles and Patterns (http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf)

● Design By Contract - Eiffel (https://www.eiffel.com/values/design-by-contract/)

● Code from the talk - Java: https://github.com/rShetty/S.O.L.I.D-Java

● Code from the talk - Ruby: https://github.com/rshetty/S.O.L.I.D

THANK YOU