Whether there is a change in the business rules or in the infrastructure, we must edit the same piece of code. Believe me, in CS, you don't want many people touching the same piece of code for different reasons. Try to make your functions do one and just one thing so it is less probable having people messing around with the same piece of code. You can learn more about this by having a look at the Single Responsibility Principle (SRP). For more information about this principle: http://www.objectmentor.com/resources/articles/srp.pdf
Listing 1 is clearly this case. If we want to move to Redis or add the author notification feature, you'll have to update the rateAction
method. Chances to affect aspects of the rateAction
not related with the one updating are high. Listing 1 code is fragile. If it is common in your team to hear If it works, don't touch it, SRP is missing.
So, we must decouple our code and encapsulate the responsibility for dealing with fetching...