あなたはNULLですか?会話の最後の質問が変だろ?代わりに、もしJeffreyへの取り次ぎをお願いした後で電話が切れたら、自分に問題(例外)が発生した、ということにする。この時点で、もう一度電話してみるか、Jeffreyにつながらないので仕事が進みませんと上司に報告する。Jeffreyにしかわからない用事だから無理、と拒否してくるかもしれない(Nullオブジェクト)。遅いエラーフェイルファストなgetByName()に対して、Nullオブジェクトを使った方はゆっくり死のうとしている。途中で他のものを殺しながら。問題が発生したので例外処理をすぐに始めるべきだと周りに知らせる代わりに、クライアントからエラーを隠している。この議論は、前述した「アドホックエラー処理」に近い。コードはできるだけもろい方がいい。必要なときに壊れるように。メソッドを、それが扱うデータに対してできるだけ厳しくさせ、与えられたデータに不備があったりメソッドの使用方法に反していたら、例外を投げるようにすべきだ。共通的な挙動をする他は常に例外を投げるNullオブジェクトを返すべきだ。employee;}可変で不完全なオブジェクト一般的に、オブジェクトは不変的に設計することが望ましい。これはつまり、オブジェクトはインスタンス化の際に必要な情報を全て受け取り、その後そのライフサイクル全体に渡ってその状態を変えないということだ。NULLは、遅延読み込みをする際によく使われ、オブジェクトを不完全で可変にしてしまう。}}この手法は、広く使われてはいるが、OOPにおけるアンチパターンだ。主な理由は、実行環境の性能問題の責任をオブジェクトに負わせているからだ。本来それはEmployeeオブジェクトが気にすべきことではない。オブジェクトが、自身の状態を管理して、自身の役割に関するふるまいを公開する代わりに、戻り値のキャッシュの面倒を見なければいけない。これが遅延読み込みというものだ。遅延読み込みを上記の例みたいな原始的な方法でやらないことだ。代わりに、キャッシュ処理をアプリケーションの他のレイヤに移せばいい。Javaなら、アスペクト指向プログラミングのアスペクトが使える。jcabi-aspectsには@Cacheableというアノテーションがあり、メソッドの戻り値をキャッシュできる。}}君がこの分析に納得してNULLを使うのをやめることを願う。以上がYegorの記事。オブジェクト界に降り立って見たときに感じる違和感というオブジェクト哲学的な側面からも説明する辺りが面白い。まあNullを完全に使わないという境地には、少なくともJavaのコードでは一生たどり着ける気がしないが。メソッドの先頭で引数のNullチェックをするとかもダメなんだろうか。それがダメだとフェイルファストができなかったり、メッセージのないNullPointerExceptionが発生したりして微妙。あ、フルスクラッチで完全に自己完結したアプリケーションを作る場合の話か。それならそもそもNullを渡すなという話にしかならないか。自分で書くクラスやライブラリについて、Nullは内部的には使うけど、APIには一切Nullを返させない、くらいなら実現するのは難しくなさそうだし、やったほうがいい気もする。(この場合遅延読み込みで一時的にNullをセットしておくのはあり。性能を考えた場合は、例えばエラー処理はアドホックが一番軽くて、次にNullオブジェクトパターンで、例外はちょっと重めという風になるだろうから、Nullを返したくなることもありそう。ことあるごとに例外を投げてくるAPIは使う側にとってはうっとうしいしなぁ。多彩な例外を投げ分けるJavaのリフレクションみたいなのは、使うとコードが散らかってかなわん。ormGetter/Setterは悪だ。