November 20th, 2015
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: firstname.lastname@example.org
Trailblazer for Ruby On Rails has some very good ideas in it though they are somewhat buried by the Object Oriented programming garbage:
To give an example of how operation works, let’s say you click on a delete button. What happens when you do that is you go to the control that knows a little bit of this action because it does authentication—if it’s valid it does one thing and if it’s not it does another thing. Instead of delegating to a model that has 10 lines of code delegating to different models and eventually ends up needing three layers of application code, the controller in the Trailblazer framework will delegate this delete action to a service object. You can have as many operations as you want.
That sounds similar to what I try to do with my Clojure code, but my Clojure code tends to get a hashmap, and polymorphically dispatches on what is in that hashmap. The result is very similar, but I don’t have to deal with all the object hierarchy stuff. The key idea here is polymorphic dispatch, and that is a good idea, but I feel like Trailblazer is forced to bury some of that goodness under a thick blanket of Object Oriented Programming.
Trailblazer reintroduces object-orientation.
For each public action, there’s one operation class.
Operations inherit contract, policies, representers, etc. and can be fine-tuned for their use case.
This seems to be a common refrain among those who do Object Oriented Programming — those other people are not doing it right, but if you do it the way that we do it, then you will like it, because we are doing True Object Oriented Programming!!!!
This example is offered:
class Comment::Update < Create policy do is_owner?(model) end end
Nick Gorbikoff says the fun is back:
I haven't been this excited about Rails since 2007! Trailblazer - makes Rails development fun again. Especially on large projects. It's one of the better implementations of the ServiceObject / ViewModel / Form Object / Policy layers I've seen, which sooner or later ( rather sooner) you'll need.
But where did the fun go, and why is the fun in such need of frequent rescue? If Object Oriented Programming was a good idea, would it need these frequent efforts at reform, renewal, and rebuilding? Many talented programmers have devoted absurd amounts of time to saving various Object Oriented Programming projects, and so one inevitably ends up encountering some good ideas in these projects, and yet one also runs into the constant feeling that this is some kind of hard struggle.
Rather sad to consider what the initial impetus was:
For the last few years I’ve been hired from different companies to refactor messed up Rails applications, and one of the most common problems I’ve run into are legacy projects with huge models of PHP scripts put into a Ruby model, where all the domain, rendering, processing, validation and etcetera are put in the model. Another one I’ve run into are horrible view layers, where the partials weren’t encapsulated and therefore every partial had access to every variable, which ends up in a messy view layer.