Encapsulate For Easy Refactors

An application is a living, breathing code base that will continually change over time. As the application evolves, early decisions won’t scale, and shortcuts taken will reveal technical debt. When the time comes to address these problems, one thing you can start doing today to make refactoring tomorrow easier is using encapsulation.

Example

Imagine your application has a User model, and the User can have a role. The role is stored as a column on the model.

You might have actions in your controller where you check if a user has a specific role. You might decide to directly access the role attribute and compare it with the role you care about:

While this seems harmless at first, it becomes painful to refactor when you have to extend the relationship so a user can have many roles.

Extending Role To Its Own Model

Imagine your product manager asks you to support users having multiple roles. You will have to move the role attribute from the User model to its own model.

Models

The resulting model design might look like the following. The User model now has a has_many relationship through a joining class ( UserRole) to a Role model.

User

UserRole (Joining Class)

Role

Usages

Instead of checking if a user.role is equal to a role, we'll now check if a specific role is in the list of roles attached to a user.

Refactoring Usages

When we refactor the ItemController to use these new models and methods, we first want to bring all methods into the User class and then update usages.

With these methods now encapsulated in the User class, checking if a user has a certain role becomes easy!

Originally published at https://www.jshah.dev.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store