クラスを責務ごとに分割するということ
上の続きで、ちょっと思考実験。
Rubyの場合、Moduleという仕組でひとつのクラスの責務の実装を複数の単位(ソースファイル)に分割できるわけで、そうすると保守のときに手を入れなきゃならない影響範囲は局所化できますよね。保守/変更の影響範囲を制御できるのなら何の為にクラスを分割しなきゃいけないのかなぁ、と。
実行時にControllerが肥大化するのはクリティカルな問題ではなくて、保守をするときに巨大なController(が定義されているソース)と格闘するのが耐えがたいわけで。あとはインスタンス変数のスコープ問題とかもあるんですけど、そこが問題なんですかね?
少なくとも色んなクラス(DTOとかDAOとかDxOとか、フィルタクラスとかなんとか)を役割ごとに事細かに作るのはそれはそれで大変だし、じゃあクラスを増やすんじゃなくてModuleを使ってユーザに対してはモノリシックでファットに振舞うController/Modelでいいんじゃないだろうか、とちょっと思ってます。正確に言えばなんか違うよなぁ、とは思いつつ自分の思い付きに反論ができないでいます。
例えば以下の感じだと、MVC的にはModelがViewに依存しているわけですが、なんかこれはこれでよさそう、と思ったり。どうなんでしょ。
app/models/my_model.rb
class MyModel < ActiveRecord::Base # attr_accessor id, name, category_id ... end
app/models/view_logic/my_model_to_html.rb
modle MyModelToHTML def to_list "<tr><td>#{category.name}</td><td>#{name}</td></tr>" end def to_show ... end end # ビューロジックの中でモデルにModuleを追加する。 ## このへんを制御するコードを外だしにしても可だと思う。 MyModel.class_eval do include MyModelToHTML end
だと
m = MyModel.new # to_listなんてベタベタな名前だしベタベタな動きの # Viewに書くべきことなのに。 m.respond_to? :to_list # => true
でエラく気持ち悪いんですが、なんでダメなんでしょう。というのがしっくり来ない。不特定のModuleからインスタンス変数を直接いじられる危険がある、つまりカプセルかが壊れてるというのは確かに嫌な感じですね。やっぱりそれ??