"S"OLID Principles - Single responsibility principle

“S”OLID - Single
Responsibility Principle
- By Nishant Upadhyay @TuesdayTalks

What’s SOLID Principle?
It’s a set of 5 principles which when followed will result into a program which is
being much more easy to maintain, is bug free, and faster to develop.
SOLID consist of the following principles:
1. Single responsibility
2. Open-closed
3. Liskov substitution
4. Interface segregation
5. and Dependency inversion

When SOLID principle emerge?
- Programming is all about breaking problems down into parts.
- There's lots of ways to break down code
- For example, The close button - Object that’s responsible for close button vs
The object that’s responsible for all read buttons. Which one is more relevant?
- Programmers worked out rules for how to organize their code so it would be
easy to reuse or change. One set of rules is called "SOLID". Every letter stands
for a different principle.
- SOLID is a set of rules that's probably a good idea to follow, but you won't
instantly get into trouble if you break it. You'll see a lot of these as you grow
up.

Why should we care about “SOLID”?
Benefits of using SOLID in your programming.
1. Easy to maintain
2. Easy to extend
3. Robust code

Coupling and Cohesion
Remember two relevant concepts in the development of any software
1. Coupling - The degree to which a class, method or any other software entity, is
directly linked to another, Dependency.
Example: If two classes are tightly coupled then changes in one class may
require lots of changes in another class.
1. Cohesion - Cohesion is a degree (quality) to which a component / module
focuses on the single thing.
Example : A well focused class, Use of modules, packages, libraries

The “S” of SOLID - Single Responsibility
Our objects should only solve one problem. When they do too many things they get
confused, so let's keep them as simple as possible.
Benefits:
● Coupling reduced.
● Code easier to understand and maintain
A class should have only a single responsibility.
OR
A class should have only one reason to change.

Let’s understand “S” by example
Usage of APIs are very common now. Let's say we need to call BlogService to get
list of blog posts.
So two corresponding classes here:
BlogService and Post
Let’s see some code now..

Let’s identify responsibilities
1. Configuration
url = 'https://jsonplaceholder.typicode.com/posts'
url = 'https://prod.myserver.com' if env == 'production'

2. Logging
puts "[BlogService] GET #{url}"
3. HTTP Layer
response = Net::HTTP.get_response(URI(url))
return [] if response.code != '200'

4. Response processing.
Assume we will get response like given below:

posts = JSON.parse(response.body)
posts.map do |params|
Post.new(
id: params['id'],
user_id: params['userId'],
body: params['body'],
title: params['title']
)
end

So At least 4 responsibilities for one class!

Let's try to follow this rule and refactor the code

Extract configuration part into separate class:
class BlogServiceConfig
def initialize(env:)
@env = env
end
def base_url
return 'https://prod.myserver.com' if @env == 'production'
'https://jsonplaceholder.typicode.com'
end
end

Now we can use this class in BlogService:
class BlogService
# ...
def posts
url = "#{config.base_url}/posts"
puts "[BlogService] GET #{url}"
# ...
end
private
# ...
def config
@config ||= BlogServiceConfig.new(env: @env)
end
end

Let's move forward and extract logging
module RequestLogger
def log_request(service, url, method = 'GET')
puts "[#{service}] #{method} #{url}"
end
end

class BlogService
include RequestLogger
# ...
def posts
log_request('BlogService', url)
# ...
end
end

We've extracted 2 classes so far. Now we need to
figure out how to handle HTTP layer and
response processing.

Implementing HTTP request handler
class RequestHandler
ResponseError = Class.new(StandardError)
def send_request(url, method = :get)
raise ResponseError if response.code != '200'
JSON.parse(response.body)
end
end

Let's send API call using RequestHandler:
class BlogService
# ...
def posts
posts = request_handler.send_request(url)
# ...
end
private
# ...
def request_handler
@request_handler ||= RequestHandler.new
end
end

ResponseProcessor to process response
class ResponseProcessor
def process(response, entity)
return entity.new(response) if response.is_a?(Hash)
if response.is_a?(Array)
response.map { |h| entity.new(h) if h.is_a?(Hash) }
end
end
end

Now, we can use the processor in our main class:
class BlogService
# ...
def posts
response_processor.process(posts, Post)
end
private
# ...
def response_processor
@response_processor ||= ResponseProcessor.new
end
end

Method posts looks much smaller now and we can read some boring code there:
1. Construct url
2. Log request
3. Send request
4. Process response

Still one problem!
In initial implementation we had sort of mapping between fields:
Post.new(
id: params['id'],
user_id: params['userId'],
body: params['body'],
title: params['title']
)

Let’s make it more flexible!
class ResponseProcessor
def process(response, entity, mapping = {})
return entity.new(map(response, mapping)) if response.is_a?(Hash)
if response.is_a?(Array)
response.map { |h| entity.new(map(h, mapping)) if h.is_a?(Hash) }
end
end
def map(params, mapping = {})
return params if mapping.empty?
params.each_with_object({}) do |(k, v), hash|
hash[mapping[k] ? mapping[k] : k] = v
end
end
end

Let’s add another method and see how it works!
def post(id)
url = "#{config.base_url}/posts/#{id}"
response_processor.process(posts, Post, mapping)
end

As you see without any significant change, We
are able to add a method easily.!!!
This is the beauty of Single Responsibility Rule!

“Your actions become your habits,
Your habits become your values,
Your values become your destiny.”
- Mahatma Gandhi

My point is to always strive to be better by challenging
yourself. At some point, you will ask, but you will know already
the answer…

"S"OLID Principles - Single responsibility principle

"S"OLID Principles - Single responsibility principle

Recommended

Recommended

More Related Content

Similar to "S"OLID Principles - Single responsibility principle

Similar to "S"OLID Principles - Single responsibility principle (20)

Recently uploaded

Recently uploaded (20)

"S"OLID Principles - Single responsibility principle

Editor's Notes