RubyFlow The Ruby and Rails community linklog

×

The Ruby and Rails community linklog

Made a library? Written a blog post? Found a useful tutorial? Share it with the Ruby community here or just enjoy what everyone else has found!

This is the way... the Callable Way

by Luan Gonçalves Barbosa —

We’ll talk about the Callable Pattern and how it can be used to make a powerful and flexible construct that will allow you to put order in your Ruby app. https://blog.codeminer42.com/this-is-the-way-the-callable-way/

Comments

That’s a pity this blog doesn’t have comments! I have some stuff to add on the topic cause I’m using this approach for over 5 years, initially inspired by this talk by Tim Riley

  1. I have a repo that demonstrates how I structure my rails projects in general, that includes a showcase of callables. It’s idealistic in a way, in some projects it’s better not to use fancy stuff like dry-monads and do notation, but still, thought it might be interesting for people who opened this page

  2. I think that using attr_reader is safe if it is placed under the private directive. This makes it clear that those readers are not a part of the public interface of your class. Maybe even more safe than referencing instance variables in the actual operation code, cause it reduces a chance that somebody will decide to set it’s value rather than get it.

  3. You have that separation into actions/interactions in your examples. I got curious, what are their responsibilities? From what I see, actions look like entry points into the domain logic, something that is allowed to call from controllers, while interactions are something “internal” to the business logic and represent “sub-operations”. My confusion here comes from Uncle Bob’s talks where he uses the term “interaction” in an opposite way: interaction is an entry point, an interface of the business logic, a boundary between presentation and business logic layers. Everything that is internal to business logic he calls “entity”.

    In my repo mentioned above (and in real projects), I highlight the public interfaces of my subsystems like this, with a single class that has a method for each entry point. Those methods call the actual operation class, simply proxying the given parameters to it, but have some tooling around (e.g. for logging). A great thing about this approach is that the whole interface is in one place and completely visible for the devs

Dmitrii Krasnov —

Also, great thanks for sharing your thoughts. Think I now have several more arguments for my colleagues in support of callables approach ^_^

Dmitrii Krasnov —

Post a comment

You can use basic HTML markup (e.g. <a>) or Markdown.

As you are not logged in, you will be
directed via GitHub to signup or sign in