Published on February 19, 2014
Design around the… Single Responsibility Principle By Eyal Golan
Agenda 1. SOLID 2. SRP overview 3. Why SRP? 4. Recognizing SRP violation 5. Develop for SRP 6. Summarize 2
S O L I D • Robert C. Martin – Uncle Bob • http://en.wikipedia.org/wiki/SOLID_(objectoriented_design) 4
SOLID • Single responsibility principle • A class should have only a single responsibility 5
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
SOLID • Liskov substitution principle • Replace objects with instances of their subtypes without altering the correctness of that program Rectangle Square 7
SOLID • Interface segregation principle • Many client-specific interfaces are better than one general-purpose interface 8
SOLID • Dependency inversion principle • Abstractions should not depend on details • Don’t depend on anything concrete • Work with interfaces 9
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
Which Components? • • • • • Methods Classes Packages Modules System 12
Why SRP? • Organize the code George A. Miller 14
Why SRP? • A place for everything and everything in its place 15
Why SRP? • Less fragile code • Low coupling • High cohesion 16
Why SRP? • Easier code changes (Refactoring) 17
Why SRP? • Easier naming • The smaller and more focused class, it will be easier to name 18
Why SRP? • Maintainability • Testability and easier debugging 19
Recognizing By Structure • Class / method is too long 21
Recognizing By Structure • Too many dependencies (fields / parameters) Dependency 3 Dependency 4 Dependency 2 Dependency 1 Dependency 5 Class Dependency 6 22
Recognizing By Structure • Low cohesion 23
Recognizing By Structure • Description / name needs: “AND” • Generic name: “EmployeeManager” 24
Recognizing By Structure • A method with many levels 25
Recognizing By Behavior • Complicated test 26
Recognizing By Behavior • Change here, break there • Test may be broken elsewhere • The “shotgun effect” 27
Recognizing By Behavior • Unable to encapsulate the module 28
Develop for SRP • Awareness • The state or ability to perceive, to feel, or to be conscious of events, objects, or sensory patterns 30
Develop for SRP • Testable code Test • TDD Refactor Code 31
Develop for SRP • Code quality metrics • Coverage • SONAR 32
Develop for SRP • Use other principles • • • • High cohesion Decrease coupling Interfaces Real encapsulation • Law of Demeter 33
Develop for SRP Keep it simple and short! 34
Develop for SRP • Naming • Think about it • Role play your entities • Longer and more focused name 35
Develop for SRP • Extract method • Extract class 36
Develop for SRP • Refactor mercilessly • Use design patterns • Keep modularization clear 37
Example Short class, 35 lines Precise name (method, class) High cohesion 38
Conclusion • OOD • Clean code • Better practice SRP Do 1 t h i A s o c c l a s s h o u l d h a v e ne r e a s on t o h a n g e ! 39
Resources • http://butunclebob.com/ArticleS.UncleBob.Principles OfOod • Uncle Bob about SRP • http://www.codinghorror.com/blog/2007/03/curlyslaw-do-one-thing.html • Coding Horror • https://docs.google.com/file/d/0ByOwmqah_nuGNH EtcU5OekdDMkk/ • PDF about SRP • http://eyalgo.com/2014/02/01/the-singleresponsibility-principle/ • My blog post about SRP 40
Simple, Isn’t It? 41
Eyal Golan 43
Presentación que realice en el Evento Nacional de Gobierno Abierto, realizado los ...
In this presentation we will describe our experience developing with a highly dyna...
Presentation to the LITA Forum 7th November 2014 Albuquerque, NM
Un recorrido por los cambios que nos generará el wearabletech en el futuro
Um paralelo entre as novidades & mercado em Wearable Computing e Tecnologias Assis...
The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the ...
Das Single-Responsibility-Prinzip (SRP, dt. Prinzip der eindeutigen Verantwortlichkeit) ist eine Entwurfsrichtlinie in der Softwarearchitektur.
SOLID principles: Single Responsibility Principle, a simple example in C#; Author: Christian Vos; Updated: 27 Jun 2013; Section: Design and ...
Single Responsibility Principle Motivation. In this context a responsibility is considered to be one reason to change. This principle states that if we ...
The calculatePay method implements the algorithms that determine how much a particular employee should be paid, based on that employee's contract, status ...
In this video Uncle Bob will take you on a deep dive through the Single Responsibility Principle. After a little General Relativity, you'll learn just what ...
Single Responsibility (SRP), Open/Close, Liskov's Substitution, Interface Segregation, and Dependency Inversion. Five agile principles that should guide ...
In this article Ralf Westphal invesigates the Single Responsibility Principle, what it means in real-world scenarios and how that may translate into code
The Single Responsibility Principle (SRP) states that a class should have only one reason to change. It was first cited in this form by Robert C. Martin in an
单一职责原则（SRP：The Single Responsibility Principle） 一个类应该有且只有一个变化的原因。 There should never be more than one ...