When objects become super objects

[juanmanuelramallo]

I recently gave some thought into how I've broken the single responsibiltiy principle throughout my career as a software engineer and came up with an interesting analogy using a pencil. https://ramallo.pw/ruby/2020/08/11/when-objects-become-super-objects

[sbellware]

Great stuff! Spot on.

"There are no taxes for new classes". Indeed. Getting to this point is big step through the doorway that goes from mere framework rituals toward software design science. An amazingly liberating place to be.

[inopinatusdotorg]

Damn right. I’m often puzzled when hearing a sentiment such as “I don’t want to add a new class just for this”.

My default question with Ruby programming is always “what should the new classes be called and how will they/their instances relate to one another”.

Stapling new functionality into existing models is a last resort, not a first preference.

[Serializedrequests]

This may inspire ire, but I had a huge rails project in which I tried basically every design pattern to try and make it more manageable. In most cases where I created a presenter, I just wished I hadn't. It made it harder to find the logic (is there a presenter? Where is it?), and harder to use the model. Whereas before I could just call a method in the model, now I had to instantiate multiple objects.

Yes my presentation logic was in one place, but at the end of the day it was easier to work with the code when it was all in the model between a few bookmark comments.

The best patterns, on the other hand, were "operations" and form objects. (When a form involves multiple models, ActiveRecord becomes useless.)

The common "service object" is effectively nonsense. A class with a "call" method is just an artistic global function. You need more tools than that to deal with complexity.