This content originally appeared on DEV Community and was authored by David J. Davis
TRIGGER WARNING && TL;DR
I think that service objects are sometimes over engineered in Rails, when in fact a plain old ruby object would potentially be better. If you are using a gem to manage services, presenters, library modules, etc, then maybe you should reconsider and weight what benefits it provides.
During the Digital Rails Conf this year I watched a video called the The Missing guide to Service Objects;
To me this was an opinionated guide to service objects, but he did discuss multiple ways of handling those service objects and some ways to accomplish it for newcomers to Rails. While it was a great talk I think that my thought process would be refactoring that talk into a "Lets talk about POROs".
To me the best rails setups do the following:
- Rails is best used when all things in the Models folder are strictly for setting up and modeling your data, meaning that it directly deals with database data.
- The controllers are simple and reference business logic or models directly.
- Business Logic is stored in the appropriate name format and is away from the controller logic.
In order to do this you may think, "I need need: #{insert_one}". Service objects, presenters, components, monkey-patches, flying-monkeys, pokémon, modular objects, and widgets.
You might, but most likely they are going to be plain old ruby objects anyway, so call them whatever the hell you want, just focus on a design pattern that works for you and your team.
Why PORO?
To establish why, examine the following code. A simple class that takes a parameter and runs a perform method. Putting it simply this is a service object, but it is also a plain old ruby object.
class Num::SquaredService
def initialize(num)
@num = num
end
def call
@num * @num
end
alias_method :peform, :call
end
Looking at this file inspector. This assumes that you have access to multiple classes, it determines a type based on a matcher method inside each class. This file inspector can be a factory, it could be in the lib folder, or references as any other name.
class FileInspector::Type
TYPES = [
FileInspector::Image,
FileInspector::Audio,
FileInspector::Video,
FileInspector::Text,
FileInspector::Pdf,
FileInspector::Other
].freeze
# Sets up mime type instance
def initialize(file)
@mime = `file --b --mime-type #{file}`.strip
end
# Determines the Type to be used in another object.
def inspect
TYPES.find { |type| type.matches?(@mime) }.name.demodulize
end
end
With a few keystrokes this PORO can look a lot like a service object, lets do that.
class FileInspector::TypeService
TYPES = [
FileInspector::Image,
FileInspector::Audio,
FileInspector::Video,
FileInspector::Text,
FileInspector::Pdf,
FileInspector::Other
].freeze
# Sets up mime type instance
def initialize(file)
@mime = `file --b --mime-type #{file}`.strip
end
# Determines the Type to be used in another object.
def call
TYPES.find { |type| type.matches?(@mime) }.name.demodulize
end
alias_method :peform, :call
end
With that, we now have a service object. With a few more changes and some HTML we could turn this into a presenter. My point is that we should be thinking more about the functionality of the object; not the name, or the location of the object in a directory structure.
The reason I lean towards keeping them as POROs is to keep everything simple and keep all classes focusing on a single responsibility. Breaking down big problems to small problems that are easily testable.
This content originally appeared on DEV Community and was authored by David J. Davis
David J. Davis | Sciencx (2021-04-30T12:43:32+00:00) Plain Ole Ruby Objects. Retrieved from https://www.scien.cx/2021/04/30/plain-ole-ruby-objects/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.