If you are a Rails-developer you know at least MVC pattern. Most of us know of course that it has some limitations in terms of structuring your code (fat controllers/models) and in some point of your developer's path you start thinking about code quality and here I mean not code style and other minor things but more general - single responsibility principal (SRP) and how we can organize code in order to make it real, Liskov’s Substitution Principle etc.
Ok, we have spotted a problem and what can we do with it?
As you can have noticed - SOLID principles and general OO design are our tools. But they are too general. Are there something more specific? Googling will provide you at least next possible patterns:
- Builder
- Decorator
- Form
- Interactor
- Observer
- Policy
- Presenter
- Query
- Service
- Value
I am not going to retell them, you can easily find definitions. But I want to light on next moment: how many from them you are using in yours projects? Is it straightforward which pattern you need to use?
Let take for example Service and Interactor:
The service design pattern breaks down a program into its functional constituents. Each service object completes one task, such as running payment for a customer, completing a bank transaction, etc.
You can use the interactor design pattern to split a large task into a series of small, inter-dependent steps. If any of the steps fail, the flow stops, and a relevant message appears about why the execution failed.
The definitions are different but the aim is the same - breaks down something big into small blocks. From my point of view, the interactor pattern is a special case of service.
class AuthenticateUser
include Interactor
def call
if user = User.authenticate(context.email, context.password)
context.user = user
context.token = user.secret_token
else
context.fail!(message: "authenticate_user.failure")
end
end
end
This excerpt was written in context of interactor gem.
and
class AuthenticateUserService < BaseService
def perform
if (user = User.authenticate(context.email, context.password))
success_result(status: :success, message: nil, data: user) # this method as and error_result are implemented in BaseService
else
error_result(status: :error, message: user.errors, data: {})
end
end
end
Does it look similar? From my perspective, they are not different patterns but one pattern with slightly different implementation.
Let's take anther one confusing couple: Decorator vs Presenter:
The Decorator pattern adds new functionality to an existing object by wrapping it with additional objects containing the new features. This helps to modify an instance of a class for extra features and not define new static subclasses in the code.
The Presenter design pattern aims to isolate view rendering logic from the controller and model and encapsulate it into a reusable component. It makes the controller and models leaner and enhances code readability.
Let's take a look into code snippets:
class PostPresenter
def initialize(post)
@post = post
end
def image
@post.image? ? @post.image.url : 'no-image.png'
end
# similary define other methods with their logic
end
class Car
def roof
"fixed"
end
end
class ConvertibleDecorator < SimpleDelegator
def roof
"collapsible"
end
def self.decorate(car)
new(car)
end
private
def model
__getobj__
end
end
#using
basicCar1 = Car.new()
basicCar2 = Car.new()
basicCar1 = ConvertibleDecorator.decorate(basicCar1)
puts(basicCar1.roof) # => collapsible
puts(basicCar2.roof) # => fixed
You can argue that is different approach... but I would like to say - different implementation but the aim is the same. Both examples are trying to separate some additional(auxiliary) logic in separate place. And there are other way for do it, for example:
class Car
def roof
"fixed"
end
end
module ConvertibleDecorator
def roof
"collapsible"
end
end
#using
basicCar1 = Car.new()
basicCar2 = Car.new()
basicCar1 = basicCar1.extend ConvertibleDecorator
puts(basicCar1.roof) # => collapsible
puts(basicCar2.roof) # => fixed
Some other patterns are more straightforward and not so confusing. But the main idea of the post is:
- try to use general principle when you structure the code (SOLID);
- not use patterns because it is just the best practice but when you can see that it makes sense; if you cannot match you class with one of this patterns it is ok if you use something new what related to you problem (often developers see
Services
in a project and try to put all new classes there however it can be QueryObject or ValueObject).
The definitions of the patterns and part of examples were taken from here
Top comments (0)