SOLID principles: single responsibility // Alessandro Bellini @ Spryker

SOLID principlesAlessandro Bellini

06.04.2016

Single responsibilityOpen/closedLiskov substitutionInterface segregationDependency inversion

Single responsibilityOpen/closedLiskov substitutionInterface segregationDependency inversion

SOLID principles: single responsibility // Alessandro Bellini @ Spryker

Summary

Definition

Multi/single responsibility scenarios

It’s suspect when...

Examples (switch to code)

Partial responsibility scenario

Common closure principle

Conclusions

SOLID principles: single responsibility // Alessandro Bellini @ Spryker

A class should have one, and only one, reason to change.

● the job of the class● what the class is for● responsibility

A class should have one, and only one, reason to change.“

SOLID principles: single responsibility // Alessandro Bellini @ Spryker

Multi/single responsibility scenarios

Multi responsibilities

Many reasons to change: higher probability of modification

More code: worse to maintain

Higher class coupling

Harder to test

Multi purpose: harder to understand or guess, need to remember what it does internally

Single responsibility

One reason to change: lower probability of modification

Less code: better to maintain

Lower class coupling

Easier to test

Single purpose: simple to understand or guess, no need to remember what it does internally

SOLID principles: single responsibility // Alessandro Bellini @ Spryker

It’ suspect when...

Too many instance variables

Too many public methods

Each method uses other instance variables

Specific tasks are delegated to private methods

We need some code here...

SOLID principles: single responsibility // Alessandro Bellini @ Spryker

Let’s switch to our beloved language...

JS

SOLID principles: single responsibility // Alessandro Bellini @ Spryker

Partial responsibility scenario

When a responsibility is shared across multiple files

1. Complementary

2. Overlapping

Code fragmentation and redundancy

Hard to maintain (potentially hell)

Test redundancy

Same purpose in different classes: who do what? Harder to understand or guess, need to remember what it does internally

Inconsistency

SOLID principles: single responsibility // Alessandro Bellini @ Spryker

Common closure principle

The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package.

Similarities (class - package)

One reason to change

Reduce coupling

“

SOLID principles: single responsibility // Alessandro Bellini @ Spryker

“DOTADIWDo one thing and do it

wellDoug McIlroy

Unix Philosophy

That’s all, folks.Thanks.

Bibliography

Noback M., Principle of Package Design - Preparing your code for reuse, Leanpub, 2015.

Osmani A., Learning JavaScript Design Patterns - A JavaScript and jQuery Developer’s Guide, https://addyosmani.com/resources/essentialjsdesignpatterns/book/, version 1.6.2, 2015.

Code examples

https://github.com/spryker/solid-devtalks/tree/master/01-single-reposibility