This document discusses the single responsibility principle (SRP) in software engineering. SRP states that every class or module should have a single responsibility, and that responsibility should be entirely encapsulated within the class. The document provides examples of when code may violate SRP, such as long methods, controllers, models, or classes. It also suggests that to follow SRP, each class should have one clear responsibility defined by the business domain, and if a class has multiple responsibilities it should be divided. The document encourages identifying responsibilities through realistic naming and reassessing the business definition before adding new functionality to a class.

1. SRP Everywhere
Make your application SOLID

2. SRP
● What
● Why
● How

4. Definition
Long
In object-oriented programming, the single responsibility principle states that every class should
have responsibility over a single part of the functionality provided by the software, and that
responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned
with that responsibility.
Short
… a responsibility is a reason to change...

5. Why?

6. Some ‘good’ code examples
● Long methods
● Long Controllers/Services
● Long Models
● Long Classes/Modules
● Are you adding to ‘legacy’?

7. Pile-on-game!

8. http://blog.codeclimate.com/blog/2013/08/07/deciphering-ruby-code-metrics/

10. Class/Module
1. … should have one responsibility
2. Responsibility is defined by business
3. If there is more than one responsibility follow
step #1

11. Where else?
● Can methods follow SRP?
● Can services follow SRP?
● Can design follow SRP?

12. How to identify and work?
● Realistic and relevant naming
● Think before ‘Pile-On’
● Reassess business definition