SRP
Single Responsibility Principle
Replay "POODR" book
by Sandi Metz
Thomas Petrachi
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221447/27_mai_2013_10-04-54.jpg)
Twitter: @thmszpy
Youtube: http://www.youtube.com/channel/thomasPetrachi
Vodeclic: www.vodeclic.com
Blog: blog.space-a.fr
O.O. Design
Easy-to-change application
- No unexpected side effects
- Easy to reuse
- Small product changes == small code changes
Single responsibility
Deciding what belongs in a class
Example
Bicycles + gears
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221451/getfile.jpg)
Example
The "Gear" class
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221452/Capture_d__cran_2014-01-02___14.08.34.png)
Example
Adding more logic
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221454/getfile-1.jpg)
Example
The "Gear" class
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221455/Capture_d__cran_2014-01-02___14.12.17.png)
Single Responsibility
Is this the best way to organize code?
Single Responsibility
Why does SRP matters?
Without SRP:
- Difficult to reuse
- Leads to code duplication
- Or to useless dependencies
Single Responsibility
Determining SRP:
- Mr Gear, what is your ratio?
- Seems fine
- Mr Gear, what is your tire?
- Seems ridiculous
Single Responsibility
When to change
"What is the future cost of doing nothing today?"
Coding Techniques
A few guidelines:
- Hide instance variables
- Hide data structures
- Extract responsibilities (from methods)
- Isolate responsibilities
Hide Instance Variables
Always use accessors
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221465/Capture_d__cran_2014-01-02___14.27.50.png)
Then you can override if nexessary
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221466/Capture_d__cran_2014-01-02___14.29.11.png)
Hide Data Structures
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221467/Capture_d__cran_2014-01-02___14.33.11.png)
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221468/Capture_d__cran_2014-01-02___14.33.24.png)
Each method will need to change if @data changes
Hide Data Structures
Encapsulate knowledge of @data structure
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221469/Capture_d__cran_2014-01-02___14.40.40.png)
Only #weelify method will change if @data changes
Extract Responsibilities
Two responsibilities in one method
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221470/Capture_d__cran_2014-01-02___14.46.54.png)
becomes
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221471/Capture_d__cran_2014-01-02___14.47.24.png)
Avoids the need for comments and improves reusability
Isolate Responsibilities
#diameter method doesn't belong in Gear class
![](https://s3.amazonaws.com/media-p.slid.es/uploads/thomaspetrachi/images/221474/Capture_d__cran_2014-01-02___14.52.52.png)
Conclusion
SRP allows you to:
-
Anticipate future changes (like a real Wheel class)
- Change without consequence
- Reuse without duplication
Thanks !
Any questions?
SRP
By Thomas Petrachi
SRP
- 2,510