43
Single Responsibility Principle By Eyal Golan Design around the…

Single Responsibility Principle

Embed Size (px)

DESCRIPTION

This presentation is based on a blog post I made: http://eyalgo.com/2014/02/01/the-single-responsibility-principle/ More details are in that blog post. I had a presentation at work with these slides.

Citation preview

Page 1: Single Responsibility Principle

Single Responsibility Principle

By Eyal Golan

Design around the…

Page 2: Single Responsibility Principle

Agenda

1. SOLID

2. SRP overview

3. Why SRP?

4. Recognizing SRP violation

5. Develop for SRP

6. Summarize

2

Page 3: Single Responsibility Principle

3

Page 4: Single Responsibility Principle

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

oriented_design)4

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

Page 5: Single Responsibility Principle

SOLID

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

responsibility

5

Page 6: Single Responsibility Principle

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…”

6

Page 7: Single Responsibility Principle

SOLID

•Liskov substitution principle•Replace objects with instances of their

subtypes without altering the correctness of that program

7

Rectangle

Square

Page 8: Single Responsibility Principle

SOLID

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

than one general-purpose interface

8

Page 9: Single Responsibility Principle

SOLID•Dependency inversion principle

•Abstractions should not depend on details•Don’t depend on anything concrete

•Work with interfaces

9

Page 10: Single Responsibility Principle

10

SingleResponsibilityPrinciple

Page 11: Single Responsibility Principle

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

11

Page 12: Single Responsibility Principle

Which Components?

•Methods•Classes•Packages•Modules•System

12

Page 13: Single Responsibility Principle

13

Why SRP ?

Page 14: Single Responsibility Principle

Why SRP?

•Organize the code

14

George A. Miller

Page 15: Single Responsibility Principle

15

Why SRP?

• A place for everything and everything in its place

Page 16: Single Responsibility Principle

Why SRP?

•Less fragile code

•Low coupling

•High cohesion

16

Page 17: Single Responsibility Principle

Why SRP?

•Easier code changes (Refactoring)

17

Page 18: Single Responsibility Principle

Why SRP?

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

be easier to name

18

Page 19: Single Responsibility Principle

Why SRP?

•Maintainability

•Testability and easier debugging

19

Page 20: Single Responsibility Principle

20

RecognizingSRPViolation

Page 21: Single Responsibility Principle

Recognizing By Structure

•Class / method is too long

21

Class:

LOC > 250

Bad

Page 22: Single Responsibility Principle

Recognizing By Structure

•Too many dependencies (fields / parameters)

22

ClassDependency 1

Dependency 2

Dependency 3

Dependency 4

Dependency 5

Dependency 6

Page 23: Single Responsibility Principle

Recognizing By Structure

•Low cohesion

23

Page 24: Single Responsibility Principle

Recognizing By Structure

•Description / name needs: “AND”

•Generic name: “EmployeeManager”

24

void calculateAndSend(…)

Page 25: Single Responsibility Principle

Recognizing By Structure

•A method with many levels

25

if

while

Page 26: Single Responsibility Principle

Recognizing By Behavior

•Complicated test

26

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

when(…).then(…);

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

when(…).then(…);

Page 27: Single Responsibility Principle

Recognizing By Behavior

•Change here, break there

•Test may be broken elsewhere

•The “shotgun effect”

27

Page 28: Single Responsibility Principle

Recognizing By Behavior

•Unable to encapsulate the module

28

Page 29: Single Responsibility Principle

29

Develop ForSRP

Page 30: Single Responsibility Principle

Develop for SRP

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

be conscious of events, objects, or sensory patterns

30

Page 31: Single Responsibility Principle

Develop for SRP

•Testable code

•TDD

31

Test

CodeRefactor

Page 32: Single Responsibility Principle

Develop for SRP

•Code quality metrics•Coverage•SONAR

32

Page 33: Single Responsibility Principle

Develop for SRP

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

•Law of Demeter

33

Page 34: Single Responsibility Principle

Develop for SRP

34

Keep it simple, stupid!

Keep it simple and short!

Keep it simple, short and specific!

Page 35: Single Responsibility Principle

Develop for SRP

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

35

Page 36: Single Responsibility Principle

36

Develop for SRP

• Extract method

• Extract class

Page 37: Single Responsibility Principle

Develop for SRP

•Refactor mercilessly

•Use design patterns

•Keep modularization clear

37

Page 38: Single Responsibility Principle

Example

38

Precise name(method, class)

Short class,35 lines

High cohesion

Page 39: Single Responsibility Principle

Conclusion

•OOD

•Clean code

•Better practice

39

Do 1 thingA class should have one reason to change!

SRP

Page 41: Single Responsibility Principle

Simple, Isn’t It?

41

Page 42: Single Responsibility Principle

Q & A

42

Page 43: Single Responsibility Principle

43

Thank You ! Eyal Golan

[email protected]

Connect