beとdoを分離する
The classes that we begin to define should represent data or model the behavior of the data object, but \*not both\*
札幌でおっさんっぽい人達がDCI、DCIって言って盛り上がってたから、最近DCIについて触れるためにClean Rubyって本をゆっくり読んでみてたんだけど、筆者がこういう主張をしてて、ナルホディウス、ナルホディウスですぞーって思ってた。どう在るかというのと、どう振舞うかというのは、それぞれ別の箇所でまとめて定義されているべきとのこと。実装としては、Userみたいなclassがデータ(=どう在るか:be)を定義していて、XXXableとかXXXerみたいなmoduleが処理(=どう振る舞うか:do)を定義していて、Userはそういうmoduleをincludeして使う。意識が高ければ、使う可能性のあるmoduleを全てのUserが予めincludeしている必要はないから、実行時にuser.extend(XXXable)とかしてインスタンスを拡張して使えば良い、とか言ってる。後は、拡張の仕組みや責任や色々なことにもっと言及していて、RoleとかContextが云々みたいな話がもっと載ってる。アプリケーションにはこういうときにこう動いてほしいという要求(=仕様)があるけれど実装にそれが現れていないよね、アプリケーションが大きくなるにつれてどんどんコードの意図が分かりづらくなっていくよねという問題を提示していて、Context(こういうときに)とRole(こう動いてほしい)がOOPで記述できればいいよね、beとdoを分離すればそういう風に書きやすくなるよね、これってcoolだよね、という話が続く。
という気持ちで読んだけど、原著は英語だし、英語は高校の授業以降もうほとんど使う機会なかったし、テスト範囲の文字列を覚えておいて記憶力と想像性だけで答案用紙埋めるみたいな感じだったから、本当にそう言うことを主張しているのかどうか怪しい。半分ぐらい自分の想像で拡張してる気がする。