The private method and its uses in a Rails app

As I am nearing the end of phase 4 in my coding bootcamp, private methods have made more of an appearance. By now, there should be a good understanding of scope and the difference between public and private methods, especially since many object-oriented languages have this concept. Let’s discuss further and gain a good core understanding so we can see how it can be used to better format and organize our code while keeping it efficient and safe.

Conventions of the private method

• use it to refactor repetitive code to keep it DRY (Don’t Repeat Yourself)
• provide comments explaining their functions to help others or your future self understand the behavior
• group all private methods together, typically at bottom of class, to improve readability
• as of Ruby 2.7, you can call private methods with or without self from other methods in the same Class without receiving an error

an example in my Teachers controller for my Phase 4 project

Using private methods for validations

The screenshot above that shows some examples of conventions in a private method is taken from one of my projects where I am using validations in my controller.

The purpose of the controller is to contain our CRUD actions that will run whenever the specific route they are linked to is requested. For every action, we want to have an error display for both during production and on the user side if a bad or incomplete request was made. Here is where we can train our brain to think about refactoring and efficiency… notice I said “for every.” That’s an indicator we can take the same code and apply it for multiple cases.

Here is how it would look if we explicitly wrote our error handling logic for each action. This could look even more cluttered if the teacher_params (strong params) didn’t exist as a private method, too. We will get to that later.

Versus condensing it and applying our rescue block to the entire controller instead:

Now this is a much more succinct, readable, neat and organized block.

So as mentioned above, what are strong params?

Another reason we use the private method is to keep certain code and functionality more secure. If you put a byebug to hit your Rails console when making a request, you will get something called a params hash.

Here, I was logged in as a user on my server and made a request to localhost:3000/users. So with my current session running, it shows a hash of my logged in user. You can access these key/value pairs like params[:username] or params[:action].

This is very helpful when it comes to condensing down code. If you utilize a CREATE action in a controller, you will need the params to create new attributes of the model you are wanting to add to. Again, as above, you can see in the CREATE action and the private section example for teachers, we have a method called teacher params. This is an example of strong params which helps protect against mass assignment vulnerability. Rails has a built in protector against passing through params as a whole so sensitive information is not directly accessed by a user.
So in this case, we call .permit on our params and manually choose which attributes should be included when creating, in our teachers case, their name, specialty, and a description. The teacher_params method can also be used in other code as well, such as in update!

And there you have it! Make sure you keep your code DRY and utilize your private class to condense repeated code.