design

The problem If you have a growing Rails application and you feel your models are getting too fat you might have a problem. We’ve all been educated with the “fat models, thin controllers” dogma - but sometimes putting all the domain logic inside the models has its downsides. As an example, the typical flow of an ActiveRecord object through a Rails request involves: fetching the object from the DB based on the params you receive (controller); doing something with the object inside the model (model); when something goes wrong, you set errors onto the model attributes (model); you finally return the object to the view, and present it accordingly (view)....

The problem Recently I’ve seen in a project I work on a lot of occurrences of this code: if user.privacy && user.privacy.enables_page?(...) The first part of the condition above is a bad practice in object oriented design. It forces collaborators of user to know a part of its implementation it could have a privacy or it couldn’t. What we want Wouldn’t it be much better to just write this:...