Rubyのモジュール機能とRailsのHelperについて考える

Moduleとは

参考サイトを見ながら思ったことをメモ

クラスでは継承をサポートしており1つの基幹クラスを継承して複数のクラスを作成する事が出来ます。これによって同じような機能を持つクラスを別々に1から作成する必要はありません。ただ、同じ様な機能が必要だったとしてもまったく別の目的のクラスである場合はクラスの継承によって共通化する部分を作成するにはおかしい場合があります。そのような場合に共通となる機能をモジュールとして定義し、各クラスにインクルードして利用することでコードの再利用性を高めることができます。

『同じような機能が必要　かつ　全く別の目的であるクラス』とはどんなクラスなのだろうか。
例を挙げて考えてみる。

• 帳簿クラスが複数の売上クラスを持っていて、売上の平均値を取得したい場合
• 生徒名簿クラスが複数の生徒クラスを持っていて、生徒の身長の平均値を取得したい場合
• 帳簿クラスと生徒名簿クラスはそれぞれ別の目的で作られたクラスだが、平均値を取得したいという機能は共通している
• こういうときは共通機能をモジュールに切り出して、各クラスがインクルードして利用しましょう

と、いうことなのだろうか。

上のような『平均値を求める』であれば、わざわざモジュールに切り出す必要もなさそう。
パッと思いつかないが、有効な場面があるのだろう。

• クラスのメンバー変数に依存せず、あくまで受け取った変数のみで閉じる処理を行う
• 関心の異なるクラスを横断する共通処理

を担うのに最適な役者がモジュールなのだろう。

http://ruby-doc.org/core-2.2.0/Module.html

何かしらのクラス内でincludeするとインスタンスメソッドのような振る舞いをする

ここを読んでちゃんと学ぶ。

Helperとは

RailsにあるhelperってModuleと似てると思った。
helperはモジュールのスゴい版って感じだろうか。

ViewでModuleな機能をサポートしてくれるのがHelper

何かしらのHelperを定義しておけば、Viewの中でincludeなどの宣言無し（そもそもView内でinclude呼び出せるのか分からないが）にHelper内で定義された処理を呼び出すことができる。

基本的にはViewに特化した処理をModelに詰め込むのではなく、Helperに移譲することが狙いなのかなと思う。
HelperにView特化な処理を移譲すると、Model側はViewの仕様に依存するような処理を抱えなくて済む。
ModelはModelとして必要な処理だけを保持できる。
すると、複数人が同じModelをイジることがなくなりコンフリクトが減り、運用上のコストが減る。
と、いったところがメリットだろうか。

一方、HelperはどのView上でも横断的に使えるため名前空間的な問題が発生しそう。

『平均値を求める』HelperがA,Bクラスそれぞれに存在して、平均値の求め方がA,Bクラスそれぞれ異なるとき
Average(A)とAverage(B)として、それぞれ中の処理が違うみたいなことをやりたい。
でもHelperはどのViewからでも呼び出せるためAverage(A),Average(B)が衝突する。

対策として、AAverageとBAverageに名前を変える必要があるのかな。。
iOSアプリ開発でやってた謎のプレフィックス付け作業を思い出す。
これはこれでコストになる。

その場合はデコレータを使おう。
みたいな声明をインターネット上で見かける。

Helperの存在意義とは

Helperの設計がイイカンジになっていれば、もしくはそこまでHelperの数が無ければデコレータは不要そうだ。
複雑度がある程度大きくなるとデコレータの出番ですよ、という感じだろうか。

デコレータがHelperの上位モデルだとすると、もはやHelperって何のために存在してるのだろう、と思うわけだ。

だいぶ謎。