Optimizing an Object’s Lifecycle Using Callbacks

For my Flatiron School Ruby on Rails project I built a web app called “Stairway to Stardom”. It is fantasy band simulator, similar in concept to fantasy football, but with nuances peculiar to the music industry.

The aim was an end product that played like a game while still honoring the CRUD interfacing and Rails conventions that we have been studying in our curriculum. The mixture of project requirements and logic required to run the game was a challenge that helped deepen my understanding of Object Oriented Programming as a microcosmic ecosystem.

The utilization of Active Record’s callback methods helped play a key role in allowing my models to creatively interact with their own data.

The Ruby on Rails Guide describes callbacks as:

“Callbacks are methods that get called at certain moments of an object’s life cycle. With callbacks it is possible to write code that will run whenever an Active Record object is created, saved, updated, deleted, validated, or loaded from the database.” — https://guides.rubyonrails.org/active_record_callbacks.html

Callbacks allow us to “hook in” to an object at different stages of it’s lifecycle. They abstract the idea of needing to call methods at the “right-place, right-time” into something we can build into the models themselves.

One way this can be implemented is using an after_initialize method to set default values that may or may not get passed through our params on form submission.

Using||= (“or equals”) let’s the model check if a value was set before it writes the default in case there are use cases where a value is manipulated by a user.

Before_destroy is another callback that can allow an object to communicate anything it might need to communicate to it’s relatives before it goes away.
In the example case of “Stairway to Stardom” a user could break up their band in which case the Band object would be destroyed while the musician objects would disassociate and return to the pool of available musicians where they can then be picked up by other bands.

One last example from this project uses a before_save on the join table model “Show”. This spot where the “Band” models and “Venue” models conjoin represents the moment in our application where all the moving parts converge into a single moment in time. This moment houses much of the game logic and algorithms that process the outcomes of this unique meeting and conjoining of objects.

Using before_save allows us to run the appropriate validations that affirm the objects playing in this “show” are of the right quality and type before commencing to calculate outcomes.

The Rails documentation lists 16 different callbacks. These call backs pivot on each side of most of your major controller actions. For example, there are before_save, around_save, and after_save callbacks available to plug your additional logic at all sides of this same call. There are even

It is important to not explicitly call methods like save or update inside your callbacks or you can end up with infinite loops and other unexpected behaviors.

A final note. It is best when utilizing callbacks to write the methods we will be calling as private methods in our models. This ensures that these methods can only be called from within which honors object encapsulation, a fundamental principal of Object Oriented Programming. We want our objects to be self reliant in processing their own data and only be sending strictly necessary messages to each other in a clear and concise manner.

With callbacks we can best optimize on this principal by creating a ripple effect via various lifecycle events to breath more life and functionality into our objects.