from 2ch

>比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても
>影響ないってことだろ。
ということであれば、それでもなお、カプセル化の話は当てはまると思います。カプセル化さえされていればクラスの内部で、Extract Classした先への委譲でも、Replace Type Code with State/Strategyでも、なんでもやりたい放題できますから。

ここでいってる外部は、クラス(Entity)の外部。仕様としてクラスを使う人に公開されてる情報です。別に私が言ってる方法でも、業務ロジックを実行するときに、State/StrategyのFactory経由で、タイプコードを置き換えれば効果は同じじゃないですかね。public String hoge;のようなほんとのpublic属性だと思っているならそれは違います。
PayCalculatorの話は、委譲先のコンポーネントがStatelessなのかStatefulなのかの話で違うといってるのかな。べつにくーすでは、Statefulなコンポーネントを否定してません。業務ロジックは、データではなく、役割でクラスを分割すべきだといってるだけです。


コメントに書いている例でも、職務を表すデータと職務が果たさなければいけない機能が同じなら、あれで十分だと思います。実際は、扶養家族だとか、さまざまなファクタが絡み合ってきて、データによる分割ではうまくいかないと思います。
もし、私がOOだとか、リファクタリングだとか良く知らないだろうということで、アドバイスしていらっしゃるのでしたら、その心配はしなくても(たぶん)大丈夫です。Seasar2は、そのようなベース(OO、リファクタリング)が出来ていないととても作れませんから。
これまでのオブジェクト指向は、素晴らしいと言われながら実はあまり成功しているとはいえない状況だと思います。これは、決してオブジェクト指向をマスターすることがかなり難しいということを意味しているだけではないと思うのです。手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。
こんなにやっても、うまくいかないのは、どこか考え直さなければならないところがあるからではないでしょうか。
その原因は、過度なデータ中心のクラス設計にあると私は考えています。データと振る舞いを1つのクラスにまとめるのは、自然なことですが、あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスになりやすいと考えています。業務アプリケーションなどはとくそうで、直接関係のない機能が1つのエンティティに押し込まれやすくなります。また、複数のデータにまたがるような機能は、そもそも適したクラスに振る舞いを割り当てるのが難しくなります。
役割によってクラスを分割するのが、最もうまくいく確率が高いのではないかというのが今の私の考えです。
blogに、これまでのオブジェクト指向の批判を書くのは、私にとってはものすごくリスクの高いことです。なにを言われてもおかしくないですから。現にいろいろ言われているわけですが、それでもあえて書いているのは、これまでのオブジェクト指向がなぜうまくいっていないのかを考え直すきっかけになればと思っているからなのです。