Single Responsibility Principle @ Clean Code Alliance Meetup

Single Responsibility Principle

By Eyal Golan

About Me

2

Senior Java developer and agile practitioner.Practicing TDD, clean code. Software craftsmanship advocate.

Tech lead / Scrum master @ eBayTeam lead @ StartApp, doing, among other things:● Manages the continuous integration and deployment of the system.● Leading the coding practices.

Engineering team lead @ AppLift (Berlin)

Agenda

1. SOLID

2. SRP overview

3. Why SRP?

4. Recognizing SRP violation

5. Develop for SRP

6. Summarize

3

4

•Robert C. Martin – Uncle Bob•http://en.wikipedia.org/wiki/SOLID_(object-

oriented_design)5

Single responsibility principleOpen / closed principleLiskov substitution principleInterface segregation principleDependency inversion principle

SOLID

•Single responsibility principle•A class should have only a single

responsibility

6

SOLID

•Open/closed principle•Open for extension, but closed for

modification•Alistair Cockburn: “…Identify points of predicted

variation and create a stable interface around them…”

7

SOLID

•Liskov substitution principle•Replace objects with instances of their

subtypes without altering the correctness of that program

8

Rectangle

Square

SOLID

•Interface segregation principle•Many client-specific interfaces are better

than one general-purpose interface

9

SOLID•Dependency inversion principle•Abstractions should not depend on details•Don’t depend on anything concrete

•Work with interfaces

10

11

SingleResponsibilityPrinciple

Single Responsibility Principle

•Wikipedia• …the single responsibility principle states that every class

should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility…

•Clean Code•A class or module should have one, and only

one, reason to change

12

Which Components?

•Methods•Classes•Packages•Modules•System

13

14

Why SRP ?

Why SRP?

•Organize the code

15

George A. Miller

Why SRP?

• A place for everything and everything in its place

16

Why SRP?

•Less fragile code

•Low coupling

•High cohesion

17

Why SRP?

•Easier code changes (Refactoring)

18

Why SRP?

•Easier naming•The smaller and more focused class, it will

be easier to name

19

Why SRP?

•Maintainability

•Testability and easier debugging

20

21

RecognizingSRPViolation

Recognizing By Structure

•Class / method is too long

22

Class:

LOC > 250

Bad

Recognizing By Structure

•Too many dependencies (fields / parameters)

23

ClassDependency 1

Dependency 2

Dependency 3

Dependency 4

Dependency 5

Dependency 6

Recognizing By Structure

•Low cohesion

24

Recognizing By Structure

•Description / name needs: “AND”

•Generic name: “EmployeeManager”

25

void calculateAndSend(…)

Recognizing By Structure

•A method with many levels

26

if

while

Recognizing By Behavior

•Class needs to be changed for more than one behavioral change

27

Recognizing By Behavior

•Complicated test

28

when(…).then(…); when(…).then(…);

when(…).then(…);

when(…).then(…);when(…).then(…);

when(…).then(…);

Recognizing By Behavior

•Change here, break there

•Test may be broken elsewhere

•The “shotgun effect”

29

Recognizing By Behavior

•Unable to encapsulate the module

30

31

Develop ForSRP

Develop for SRP

•Awareness•The state or ability to perceive, to feel, or to

be conscious of events, objects, or sensory patterns

32

Develop for SRP

•Testable code

•TDD

33

Test

CodeRefactor

Develop for SRP

•Code quality metrics•Coverage•SONAR

34

Develop for SRP

•Use other principles•High cohesion•Decrease coupling• Interfaces•Real encapsulation

•Law of Demeter

35

Develop for SRP

36

Keep it simple, stupid!

Keep it simple and short!

Keep it simple, short and specific!

Develop for SRP

•Naming•Think about it•Role play your entities•Longer and more focused name

37

Develop for SRP

• Extract method

• Extract class

38

Develop for SRP

•Refactor mercilessly

•Use design patterns

•Keep modularization clear

39

Example

40

Precise name(method, class)

Short class,35 lines

High cohesion

Conclusion

•OOD

•Clean code

•Better practice

41

Do 1 thingA class should have one reason to change!

SRP

Resources• http://butunclebob.com/ArticleS.UncleBob.Principles

OfOod• Uncle Bob about SRP

• http://www.codinghorror.com/blog/2007/03/curlys-law-do-one-thing.html• Coding Horror

• https://docs.google.com/file/d/0ByOwmqah_nuGNHEtcU5OekdDMkk/• PDF about SRP

• http://eyalgo.com/2014/02/01/the-single-responsibility-principle/• My blog post about SRP

42

Simple, Isn’t It?

43

Q & A

44

45

Thank You ! Eyal Golan

[email protected]

@eyalgo_egolan

http://eyalgo.com/