### **Other Handlers** ### We can improve many other types of "handlers" using this same approach to decoupling. By restricting all handlers to being simple *translation layers*, you can keep your heavy business logic neatly organized and decoupled from the rest of the framework. To drive the point home further, let's examine a route filter that verifies that the current user of our application is subscribed to our "premium" pricing tier. ~~~ <!-- lang:php --> Route::filter('premium', function() { return Auth::user() && Auth::user()->plan == 'premium'; }); ~~~ On first glance, this route filter looks very innocent. What could possibly be wrong with a filter that is so small? However, even in this small filter, we are leaking implementation details of our application into the code. Notice that we are manually checking the value of the ``plan`` variable. We have tightly coupled the representation of "plans" in our business layer into our routing / transport layer. Now, if we change how the "premium" plan is represented in our database or user model, we will need to change this route filter! Instead, let's make a very simple change: ~~~ return Auth::user() && Auth::user()->isPremium(); ~~~ A small change like this has great benefits and very little cost. By deferring the determination of whether a user is on the premium plan to the model, we have removed all implementation details from our route filter. Our filter is no longer responsible for knowing how to determine if a user is on the premium plan. Instead, it simply asks the ``User`` model. Now, if the representation of premium plans changes in the database, there is no need to update the route filter! > ### **Who Is Responsible?** ### > > Again we find ourselves exploring the concept of responsibility. Remember, always be considering a class' responsibility and knowledge. Avoid making your transport layer, such as handler, responsible for knowledge about your application and business logic.