■

とりあえず、「カプセル化を破壊する」の意味がわかりました。
使う側がnullチェックをしないといけないから、その(使われる側の)オブジェクト内で収まってないって事ですよね。

次、昨日の、指問題だと、現実世界では、「get薬指」しても、指をget出来ない。(nullを受け取れない。)から、return null;は、現実世界とずれている。
現実世界に合わせるなら、

if(人.has薬指() == true){
　薬指.set指輪(結婚指輪);
} else {
　// 「他の指」はどうやって取ってきているかは省略
　他の指.set指輪(結婚指輪);
}

もしくは、get薬指()メソッドで、指NotFoundExceptionを投げる。

これには、一長一短があり、
・hasメソッドを持たせる場合は、とりあえず、簡単。でも、対にメソッドを用意しないといけない、また、手続きが決まってしまう。hasを呼んで、tureなら、get。いきなりgetを呼んでも保証されない。インターフェースにきちんと定義してれば、良いというかもしれないが、微妙なところ。保証しないで、何を返すか？という最初の話に戻ってしまう気がする。(ヌルポ投げる?)
・例外を投げる場合は、今回の指の例だと、一番、現実に近いと思われる。今回の例だと簡単だが、問題は、try/catchのスコープの範囲や、例外が継承関係にあった場合、とりあえず、コンパイルが通るけど・・・、みたいな事になってしまうかもしれない。きちんと実装されてるかという事が不安になる。(これは、優秀じゃないPGを想定してます。優秀であれば問題ない。return null;の場合でも、優秀じゃないPGは、ifでnullチェックしていないかもしれないが。。。)

最後に、NullObject。
Stateパターンなどであれば、「仕事やる気ある状態オブジェクト」、「仕事やる気ない状態オブジェクト」、の他に、NullObjectとして「それ以前の状態オブジェクト(子供の場合とか?)」が存在するが、指オブジェクトで考えた場合、「存在する指オブジェクト」、NullObjectとして「存在しない指オブジェクト」となるが、「存在しない指オブジェクト」なんて、現実世界にない。無理矢理、概念として作るしかない。ので、いつも、現実世界に合わせて、使えるという訳ではない。

結局、「何が一番大事なのか？」というのが重要で、
1.実装が簡単なのが重要
2.現実のモデルと実装モデルが一致しているのが重要
3.(他に何かあるかも？)
というところで、何を取りますか？
という事になると思う。

実装者は、1を取るだろうし、
モデリングする人は、2を取るかもしれない。

結局、理想というか、ベストプラクティスはなく、ケースバイケースになると思う。
のですが、みなさん、どう思いますか？オレは、絶対に譲れない意見があるという人います？