日々の破片

_ うぐ

同意。したがってある意味においては相当口惜しいような感じ。

それにしても、この日のエントリーは、例外：ひがさん、あなたはわたしですか？ というくらいに同意。テスト：詳細設計書という言葉の示すものが違うかも知れないのではっきりとはわからないけど、どうも同じ考えをもたれているようだ。ロジックの位置：興味深い。

例外については、Javaが最初のころのインタラクティブなプログラミング言語（Swingアプリケーションが代表）の頃の名残が強くて(FileNotFoundExceptionであればそれはキャッチしてユーザーに問い合わせるべきでしょう)、サーバーサイド時代の手法がきちんと確立してないってことではないかとも考えられるけど（サーバーサイドで存在を前提としたファイルがFileNotFoundExceptionなら処理は継続できないでしょう）、MVCでいうとMとCの微妙な境目、BCEなら文句なくCの部分で例外を一律キャッチというのが基本（処理内容によっては再試行可能なものもある）だと思う。

全然、オブジェクト指向的では無い構造化型の機能分割によるオブジェクトによる責務分割というのを考えて

  コントローラ  → エンティティ
                      ↑
　　　　　　　　ビジネスルール（集） --- 機能の固まり

ビジネスルール(集)というのは、ビジターのようなもの(パターンではなくオブジェクトの分割手法として)を想像すれば良くて、（この場合エンティティの）外部のオブジェクト（1対多である）なのだが、ある特定の（この場合エンティティの）オブジェクトに対する操作の権限を持っていて、それを組み合わせてエンティティ自身に実行させる（のはコントローラの役割）というような感じに実装できるのではないかと、まさに現在やっているところだったり。(追記：デザインパターンだとストラテジパターンに近いのだが、コンテキスト（これが上だとエンティティに当たる）が、ストラテジに対して自分を与えるだけという点が本来のストラテジとは異なる――エンティティはストラテジが自分に何をするのか基本的に知らない――したがって関連性はエンティティがthisを与えるという点を除いて単方向――ストラテジ側からの操作――になるので、コンテキストがアルゴリズムを集約するストラテジパターンとは異なる。）

まあ、日本にはひがさんがいるので、ロッドジョンソンはいらないな、というところか。