<commit_before># Focused Controller: Bringing Real OOP to Rails Controllers. #

[![Build Status](https://secure.travis-ci.org/jonleighton/focused_controller.png?branch=master)](http://travis-ci.org/jonleighton/focused_controller)


## Description ##

Classical Rails controllers violate the Single Responsibility Principle.

Each different "action" has separate responsibilities. The "create"
action does something entirely different to the "destroy" action, yet
they are lumped into the same object.

This has two unfortunate side effects:

1. *Instance variables are shared with the view*. We don't declare public
   methods in the controller and call them from the view, because not all
   of these methods would make sense for every action. Using instance
   variables for this purpose makes it hard to change your implementation
   and can lead to subtle bugs (for example referencing an undeclared
   instance variable is not an error in ruby, but calling an undefined
   method is, so you catch the mistake sooner).

2. *Action-specific APIs are needed*. For example, you might write a
   `before_filter` which only applies to certain actions, so we have an
   API which allows you to write `before_filter :find_post, except:
   :index`. *If each 'action' is a separate object this is entirely
   unnecessary*. Just use the normal methods of sharing code -- inheritance
   and mixins -- to apply the filter to the actions which should receive
   them. A secondary effect is that filters are often themselves
   unnecessary; for example a `before_filter` might be replaced by a call
   to `super` to receive some shared behaviour.<commit_msg>Reword side effect No. 1<commit_after># Focused Controller: Bringing Real OOP to Rails Controllers. #

[![Build Status](https://secure.travis-ci.org/jonleighton/focused_controller.png?branch=master)](http://travis-ci.org/jonleighton/focused_controller)


## Description ##

Classical Rails controllers violate the Single Responsibility Principle.

Each different "action" has separate responsibilities. The "create"
action does something entirely different to the "destroy" action, yet
they are lumped into the same object.

This has two unfortunate side effects:

1. *We end up using instance variables to share data with our views when
   we should really be using methods*. Using instance variables for this
   purpose makes it harder to change your implementation and can lead to
   subtle bugs. For example, referencing an undeclared instance variable
   in a view will work, when it should probably raise an error. We could
   define public methods in our controllers and access those in our views,
   but this will quickly get unmaintainable.

2. *Action-specific APIs are needed*. For example, you might write a
   `before_filter` which only applies to certain actions, so we have an
   API which allows you to write `before_filter :find_post, except:
   :index`. *If each 'action' is a separate object this is entirely
   unnecessary*. Just use the normal methods of sharing code -- inheritance
   and mixins -- to apply the filter to the actions which should receive
   them. A secondary effect is that filters are often themselves
   unnecessary; for example a `before_filter` might be replaced by a call
   to `super` to receive some shared behaviour.
{'fraction_non_alphanumeric': 0.0558743581999396, 'fraction_numerical': 0.0015101177891875567, 'mean_word_length': 4.316211878009631, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3329606', 'n_tokens_mistral': 829, 'n_tokens_neox': 804, 'n_words': 445}