17 minute read
I’ve been programming for a long time and I’ve had countless arguments about different things. I’d like to list top four reasons I’ve had an argument online.
Style guide. Thankfully, the number of arguments reduces as I mature, but I’m still spending a lot of time on them. I’d rather have an extremely opinionated styleguide and just stop talking about it. Something like wemake-python-styleguide, but for Ruby.
Monads. I have to admit that this word is almost banned from my vocabulary because of how many arguments I’ve had about it. It’s getting better, but people still like to argue about them. I wrote an article recently about them in hope to show that there’s nothing special to argue about – monads are just abstractions that may or may not be helpful. It all depends on your problems and approaches.
How to design domain logic. It may be an extremely interesting and helpful discussion, or it may turn into a useless argument. When it goes bad, it’s usually because we’re trying to discuss insignificant details and lower-level things. Where do we put arguments? What about dependency injection? How do we use instance variables? Fat model? Service objects? Ughh!
Different interpretation of common terminology. What do we mean when we say “interactor”? What about “architecture”? Is it a state when we’re just passing values from function to function? Is duck typing really an absence of types? What is a type, anyway? What does it mean to write “object oriented” code? What about “functional” approach? Do we need immutability in OO design? Those topics lead to endless discussions with little output.
As much as I love learning about new things, those arguments are extremely energy-draining. They got me thinking: since we’re usually going over the same thing, why don’t we just dump the knowledge somewhere and refer to it instead of arguing? That’s what I’m going to do.
I’m starting a series of blog posts about different topics in Ruby world. My goal is to describe different approaches to the same problems and highlight pros and cons of each one. Perhaps, pick a favorite one and promote it.
Right now I want to focus on two larger topics:
- Designing service objects
- Handling errors in domain logic. Exceptions, values, result objects
This is a first post of the series, and it will cover the first topic: building helpful service objects.
We will go through the basics: what are we talking about when we say “service object”. We’ll look through different approaches and see which ones bring the most benefit and which ones should probably be put to rest. In the end, I’m going to suggest a working design and a couple of guidelines you can use to improve your service object game.
