4 ms·

This is a very good comment. Every complex Rails app I've worked on, we end up having the same debates: "Our models are too fat, let's refactor." "Where shoul

This is a very good comment. Every complex Rails app I've worked on, we end up having the same debates: "Our models are too fat, let's refactor." "Where should the code go?" "Let's put them in a utility class." "No, a utility class is a code smell from the point of view of true Object Oriented theory." "Then let's put them in a service class." "No, a service class is just a utility class with a different name." "Then where should the code go?" A long debate ensues, and then we end up with some crazy solution that includes everything that jeff_vader just suggested as a problematic: " Where's the code? 'lib'? 'core'? 'app'? 'api'?"

malyk 6y ago
We use the interactor gem with great success for this.
mhoad 6y ago
I think one of the things I have started to realize is how rarely people in Rails-land tend to reach for more established patterns that are generally thought to be important to writing good object oriented code. There seems to be a real adversity among many to go ahead and create new classes as needed especially when that new class isn't obviously a model, view or a controller. I just went over a short YouTube series DHH (creator of Rails) did where he walked through the production code behind Basecamp and I was struck by how different it looked to almost any other Rails app I recalled looking at previously. But it seemed like there was not a whole lot that they were doing that would seem in any way out of place from a SOLID OO perspective. It's a very interesting set of videos to take a look at what a modern Rails app with a decent amount of complexity looks like as intended by the team who wrote the framework. You can find it here if you're interested https://www.youtube.com/playlist?list=PL3m89j0mV0pdNAg6x9oq6S8Qz_4C-yuwj https://www.youtube.com/playlist?list=PL3m89j0mV0pdNAg6x9oq6...
simplify 6y ago
This isn't unique to Rails apps. You'd have code organization tensions in any complex app you write. Fortunately, for whatever you decide, you can create as many folders as you want in `app/` and Rails will detect & autoload them for you.

malyk 6y ago

We use the interactor gem with great success for this.

mhoad 6y ago

I think one of the things I have started to realize is how rarely people in Rails-land tend to reach for more established patterns that are generally thought to be important to writing good object oriented code. There seems to be a real adversity among many to go ahead and create new classes as needed especially when that new class isn't obviously a model, view or a controller. I just went over a short YouTube series DHH (creator of Rails) did where he walked through the production code behind Basecamp and I was struck by how different it looked to almost any other Rails app I recalled looking at previously. But it seemed like there was not a whole lot that they were doing that would seem in any way out of place from a SOLID OO perspective. It's a very interesting set of videos to take a look at what a modern Rails app with a decent amount of complexity looks like as intended by the team who wrote the framework. You can find it here if you're interested https://www.youtube.com/playlist?list=PL3m89j0mV0pdNAg6x9oq6S8Qz_4C-yuwj https://www.youtube.com/playlist?list=PL3m89j0mV0pdNAg6x9oq6...

simplify 6y ago

This isn't unique to Rails apps. You'd have code organization tensions in any complex app you write. Fortunately, for whatever you decide, you can create as many folders as you want in `app/` and Rails will detect & autoload them for you.