The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress.
Rails provide powerful callback technique and as a powerful tool it could injure in newbie hands.
Understanding the problem
For example we have simple blog engine. Where we have
Posts, Users, Comments
And system should create a default post with random comments when
User with type
admin created. This could be done through rails callbacks
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
After some time passed you decide that creating user for comments was a bad idea and you remove it. But when you create another one admin you need to search through three different objects to find out why your default post does not have comments. This is the simplest example but you could find even more weird problems and real hell in practice.
For extracting this behavior out of objects we need to keep in mind some of best practices. Sandi Matz recommends to keep your objects unitary and easy to follow check out this blog post for more details.
So lets introduce new object that for now will encapsulate logic around admin user
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
This way we could extract any kind of callbacks out of User class that belongs to specific type of user of certain conditions.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
I recommend to always keep your objects as clean and small as possible, so any changes that you need to introduce touch single class that easy to understand and follow.
Extracting callbacks out of Domain Class could be useful refactoring technique and any of us should use to avoid callback hells and code smells. Unitary class is much easier to test and change.