• メイボック

三鷹の森 ジブリ美術館のカフェ 麦わらぼうしにて。

• Guinness
• Hoegaarden White

浅草橋のくうかいにて。 新人くんの研修期間明け打ち上げ飲み会。

• Guinness

渋谷のバグースにて。

• Spaten Optimator
• Spaten Munchner Hell
• Spaten PremiumBock
• 富士桜高原麦酒 メルツェン

日比谷オクトーバーフェスト2008 にて。 五月だけど、オクトーバーフェストらしい。 10月はアサヒビールが抑えちゃったんだろうね・・・。 古株はこっちなんだけどね。 複雑な事情があるんでしょうな。

仕事帰り、19:00 くらいに着いたら結構混んでました。 いやぁ、外で飲むビールはおいしいね！！

• Leffe Vieille Cuvee
• Westmalle Tripel

オクトーバーフェストは 21:00 までなので、当然二次会へ。 二次会は日比谷公園から歩いて10分ほどの、ANTWERP SIX にて。

最近、どうもタイ料理とかパクチーとか、そっち方面の食べ物を口にする機会が多く、いっそ自分でも思う存分そっち系の料理を作ってみたくなり、吉祥寺をウロウロして食材を探してみました。

ひとまず狙いはこのあたり。

• パクチー / 香菜 / コリアンダー
• ナムプラー / ニョクマム
• ナム・チム・ガイ
• フライド・オニオン

タイ料理とあまり関係のないものも混ざっていますが・・・。 パクチー / 香菜 / コリアンダーは、呼び名は違えど、要はあの草です。 実はこいつを見つけるのが一番の目標。 ナムプラーはタイの魚醤で、ニョクマムはベトナムの魚醤。 ナム・チム・ガイは、名前は知らなくとも見たことのある人が多いと思う。 生春巻きを頼むと小皿で添えられたりする、甘酸っぱいチリソース、あれです、あれ。 またの名を "スイート・チリ・ソース" として売られているようです。 最後のフライド・オニオンはタイ料理には直接関係ないのだけれど、rewse から、なかなか使い勝手が良いという話を聞いたのでついでに探してみます。 多分全部、大きくは「輸入食材」というカテゴリーでくくられるので、きっと "ついで" でも見つかるはず。 パクチーだけは生鮮食品なので、探すのが他よりはちょっと難しいかなぁ、という予感がします。

以下は、いずれも 2008-05-25 時点での情報です。 また、（当然ですが）吉祥寺のすべてのお店を回ったわけではないので、これ以外にもこれら食材を手に入れられるお店はある筈です。

まずは駅に最も近いロンロンから攻めます。 ロンロン内にはいくつか食材を扱っているお店がありますが、駅の側から進むとまずはぶつかる「ザ・ガーデン自由が丘」へ。 ここは野菜も置いているので、パクチーに淡い期待を抱きつつ覗いてみます。

はい。 あっさりです。 "コリアンダー" 発見です。 一株で 158 円。 すさまじく拍子抜けしましたが、駅からこんなに近いお店でパクチーを買えるという事実に狂喜乱舞。 会社帰りに寄れちゃう。

いきなり最大の目標を達成してしまったので、ちょっと探索気分がしぼんで来ましたが、気を取り直して同じくザ・ガーデン自由が丘の調味料売り場へ。 すると、はい、ナムプラー、ニョクマム、ナム・チム・ガイ発見です。

ザ・ガーデン自由が丘、すごいね！ 一店で目的の大半を達成してしまいました。 あまりの大漁っぷりに、フライド・オニオンを探し忘れるほどでした。

他を回るモチベーションを失いかけたけれど、なんとか奮い立って伊勢丹の地下食料品売り場へ。 エスカレーターを降りると、目の前が調味料売り場でした。 ここでも、はい、ナムプラー発見です。 そして野菜売り場には "香菜" が。 こちらも一株入りで、お値段は確か198円ほど。 ちょいとお高めですな。

なんだよー。 パクチーって案外普通な感じの食材なのか・・・。 ちなみに、ここでもフライド・オニオンのことはすっかり忘れていました。

続いては、輸入食材がかなり充実しているという話の KALDI COFFE へ。 よく店頭でコーヒーの試飲をしているお店ですな。

一階はざっと見た感じ、輸入食材という雰囲気ではなかった（コーヒーとか乳製品とか）だったので二階へ。 すると、目の前にフライド・オニオンのビンの山が。 おー、素晴らしい（この時点まで、フライド・オニオンのことは忘れてた）。 なんかもう当たり前になってきて悔しいのですが、ここでもナムプラー、ニョクマム、ナム・チム・ガイ発見。 ナム・チム・ガイはロンロンで見かけたものと同じものが、ちょっとだけ安く売っていました。 なお、ここは生鮮食料品やさんではないのでパクチーは置いていませんでした。 残念。

吉祥寺通りを渡り、一本裏手に入ったところにある "カーニバル" へ。 目の前を通ったことは結構あるのだけれど、入るのは今日が初めてでした。 食材だけじゃなくて食器とか調理道具とかも置いてるんですね。 食材系は奥のほう。 ナム・チム・ガイはロンロンと KALDI COFFEE と同じブランドの大瓶がおいてありました。 100円くらいの違いで、ビンの大きさが二倍弱くらいになっています。 うわぁ、お買い得！！ と思ったけど、750ml もいらないよね・・・。 四合瓶じゃあるまいに。 ナンプラー、フライド・オニオンもあります。 ここも、生鮮食料品は置いていない（デリはありますが）ので、パクチーはありませんでした。

東急の地下には FoodShow が入っています。 生鮮食料品も扱っているので、まずは野菜売り場を覗いてみると "香菜" 発見です。 しかもこちらは3,4株入って198円。 これまでで一番安いです。 これは買いだな。

調味料売り場に行ってみると、なんかもう見慣れた光景、という感じでナム・チム・ガイとナムプラーが。 ナム・チム・ガイはこれまで見たのとはちょっと違って、全体が赤いチリ・ソースでした。 味は同じなのかもしれないけれど、ビジュアルがぼくの中のいわゆる「タイ料理のスパイス」としてのナム・チム・ガイとはちょっと違ったのでパス。

ナムプラーは家にあった気がしたので、最終的に KALDI でナム・チム・ガイとフライド・オニオンを、東急でパクチーを買って帰ってきました。 あちこち回って思ったけれど、吉祥寺は案外いろいろな食材がそろってるんですなぁ。 アジア系だけではなくて、ビネガーだオリーブだサーディンだと、欧州系もなかなか充実でした。 面白いぞ。

家に帰ってみると、残念ながらナムプラーは切れていたので、また今度買いに行かないと。

• クローネンブルグ ブラン

吉祥寺の ラパンアジル にて。

• オゼノユキドケ IPA
• LION STOUT
• CHIMAY WHITE

BICKE にて。

日曜の昼からビールってのはなかなかよろしいですなぁ。

先日、調布飛行場の脇にある "プロペラカフェ" に行ってきました。 会員制の飛行クラブが母体で、一応は「空港関係者以外立ち入り禁止」なエリアにあるので堂々と紹介していいのかどうか躊躇するところではあるのですが・・・。

• 調布飛行場 - Wikipedia
• プロペラカフェ

このカフェは調布飛行場の滑走路脇、もう少し正確には滑走路脇の空港関連施設の中にあります。 店内はもう、空港内に片足突っ込んでる状態で、ガラス扉一枚で誘導路に出られます。 滑走路に面した壁は広いガラス窓になっているので、離着陸する飛行機が良く見えます。 それも、間近に。 さらにもう一面の壁は飛行機の格納庫に面していて、これもまた広いガラス窓。

調布飛行場なので大型機はもちろんありませんが、目の前に中型小型の機体が並んでいます。 なんとも非日常な光景。 さっき着陸してきた飛行機が目の前まで運ばれて来たりします。 このサイズの飛行機は、格納庫から出し入れするときは人の手で引っ張って動かすんだね。 うーむ、ぜひともぼくも飛行機を引っ張ってみたいぞ。

ぼくが行ったのは土曜日の午後。 ちょっと混んでいたため、残念ながらどちらの窓にも面していない席になってしまったのだけれど、それでも滑走路も格納庫も眺められてご満悦でした。 滑走路に面した席に座ったら楽しいんだろうなぁ。 案外頻繁に離着陸があるようです。

• ライジングサンペールエール - ベアードビール

吉祥寺の HOLIC にて。

• Tiger
• TUSKER
• ハートランド
• Kingfisher

経堂のパクチーハウス東京にて。 さすが専門店だけあって、恐ろしいまでのパクチー尽くし。 パクチーお代わり自由のスープとか。 デザートまでパクチー。 うむ、また行かねばなるまいて。

• SAMUEL SMITH TADDY PORTER
• Duchesse de Bourgogne

パクチーは大満足だったのだけれど、まだちょっと飲めたので吉祥寺の THE KID へ。 そこで、またもビールのおいしいお店を紹介していただく。 いやぁ、やはり言ってみれば情報が集まってくるもんだねぇ。

• 「サッポロ　ＶＩＶＡ！ＬＩＦＥ（ビバライフ）」新発売～　発泡酒ではじめて糖質ゼロとアルコール５％を両立（＊注1）　～ :: サッポロビール／ニュースリリース

ぼくが禁酒しているときに発売になった発泡酒です。 04/16 発売で、糖質0%。 発泡酒なのに、原材料にエンドウたんぱくを使用しているようです。 これにより発酵度を高めて、残留する糖質を減らしているとのこと。 サッポロビールは、新ジャンルの主力商品 Draft One でエンドウたんぱくによる醸造の実績を積んでいます。 とうとう発泡酒にまでですか。

液色は淡色。 香りは、殆どありませんな。 味は、やはりどうも味に硬さがあります。 糖質を減らすときには、同時に糖質が寄与していた味わいや香りも失うことになるのはやはり避けらないようで、昨今の糖質オフ / 糖質ゼロビール系飲料はどれもこんな味です。

サッポロビールは既に糖質オフビール "ビア・ファイン" を今年三月に発売しています。 ここでさらに糖質オフ発泡酒を市場に投入するのは、どうなんでしょうね。 市場の立ち上がり時期との兼ね合いもあると思いますが、どうしたってカニバると思うんですがねぇ。

• 深大寺ビール ピルゼン

深大寺のそばやさん 門前 にて。 そばにてんぷらに酒。 乙ですなぁ。

• SINGHA

吉祥寺のタイ料理屋さん チャオチェンマイ にて。

その後、同じく吉祥寺の more に行ってみたのですが、残念ながらビールの品揃えはイマイチだったので諦め。 ただ、その向かいのビルにビールを置いていそうな店発見。 次回だな。

亜急性甲状腺炎を患って以来、自主的に規制していたビールをとうとうこの日解禁することに。 会社のみなさまが八名も解禁を祝って集まってくれて、みんなで両国のポパイへ。

• ポパイのホームページへようこそ

「まだ病み上がりなので、今日は抑え目に」といっていたのに、ふたを開けてみれば。

• 伊勢角屋 ペールエール
• ベアードビール ライジングサンペールエール
• ベアードビール 夏みかんエール
• 箕面ビール WIPA
• 那須高原ビール ナインテールフォックス
• 隅田川ポーター

いやー、うまかった。 至福でした。 ほかにも飲んだ気がするんだけど忘れてしまいました。

中央線沿線に引っ越して初のゴールデン・ウィーク。 せっかくなので、中央線（中央本線）で行ける山梨へ旅行に行ってきました。

予定よりちょっと早くに駅に着いたので、予定より早い電車に乗ってみました。

次の駅で乗り換えたほうが良いことが分かったので、結局はじめから乗る予定だった電車を待つことに。 電車は案外混んでいて座れません。

三鷹から乗った快速は高尾が終点だったので乗り換え。 ここからはちょっと古い型の電車です。 うーん、旅っぽくていいねぇ。 そしてやっぱり混んでいて座れません。 せっかくのボックス席なのに。 残念。

途中の駅は降りる人はいるものの、乗ってくる人があまりいなく、車内は少しずつすいていきます。 30分ほど揺られたあたりで座ることができました。

朝ごはんが早かったので、甲府駅に着いたときには空腹です。 比較的暖かい日だったのでちょっと迷ったのですが、山梨に来たならやっぱりほうとうだろうということになり、駅の観光案内所でおいしいお店を聞いてみました。 駅前に「小作」というお店があるが開店にはまだちょっと早いとのこと。 オープンまでの時間、これまた駅前にある甲府城址に行くことに。

甲府城は駅から歩いて五分程度。 電車の窓からも見える城です。

• 甲府城
• 甲府城 - Wikipedia

山梨の武将といえばやはり武田信玄が一番に挙がりますが、この甲府城は武田氏の居城だった歴史はないようです。 天守台に上ると甲府盆地が一望できます。 この日は晴れていたので、正面の山並の向こうに富士山が頭を出しているのがよく見えました。 それにしても天気のよい日で、暑いくらいでした。 甲府城の案内係のおじいちゃん曰く、予報では28度になるそうで・・・。 「ほうとうを食べる」という決意が揺らぎかけましたが、もう開店する時間なので、観光案内所で教えてもらったお店へと向かいました。

観光案内所で教えてもらったのはここ。

• 甲州ほうとう 小作

お城をのんびり見ていたので開店時間をちょっと過ぎた頃に着きました。 すると、既に店内はほぼ満員。 こんなに暑いのに、みんなほうとうなんてよく食べるよなー。 幸い、あまり待たずに席に案内してもらえましたが「ほうとうはできるまでちょっとお時間かかります」とのこと。 まー、ここまで決意を固めて来てほうとう以外を選ぶ筈もなく、そりゃ待つでしょう。 ぼくは「かぼちゃほうとう」を注文。 ほどなくして、意外と早く出て来ました。 しかし、その量にちょっとめまいが。 一人ひとつの鉄鍋、かなりの量の具材がぐつぐつと煮込まれています。 あぁ、決意が揺らいでゆく。 かぼちゃ、じゃがいも、里芋など、ホクホクと煮られていて、食べてみるとさすがうまい。 最後ちょっと無理しましたが見事完食しました。 ほうとうって、基本は肉系の具が入らないんだね。 野菜のみでした。

苦しいほど満腹になったおなかを抱え、武田氏ゆかりの神社、武田神社へ向かいます。

• 甲斐　武田神社

駅からバスが出てはいるものの、タイミングが合わなかったので徒歩で向かうことに。

武田神社は甲府駅の北側の山のふもとにあるので、微妙な上り坂を延々と歩き続けます。 その道中でふと気になったのですが、甲府は犬が少ないように思えます。 時間帯もあるのかもしれませんが、犬を散歩させている人も殆ど見ませんし、「その庭だったらこの辺りに犬小屋あってもおかしくないよね」という雰囲気の場所にも犬はいません。 甲斐犬は有名なので、本当に少ないわけではないのかもしれませんが、とにかく甲府駅から武田神社までの道中に犬の姿はありませんでした。

30分ほど歩いて、なんとか武田神社に到着。 案外遠かった・・・。 境内はそれなりに広いことは広いのですが、建物はあまり豪奢ではなくて良い感じです。 日光東照宮の派手派手しい感じも嫌いではないですが、この手の寂びれた感じも素敵です。 境内ではなぜか鶏が放し飼いになっていました。 そばに掛けられていた、子供の名前を書いて奉納された紙にちなんで、ぼくらはこの鶏を「エキュテル（永久輝）」と命名しました。 なんとなく、読み方が間違っているような気はしますが。

境内には「藤村記念館」という明治期の洋館があるということで、これも楽しみにしていたのですが、なんと。

• 甲府市 ホームページ - 藤村記念館

移設につき閉鎖。 次期開館は平成22年の予定だそうです。 うわぁ。 残念だ。

ちょっとがっかりしつつ、また同じような距離を歩いて甲府駅まで戻ります。 ここからは帰り道、上り電車に乗ります。

しばらくすると、車窓から「足湯無料」の文字が。 駅のすぐ目の前だったので、降りてみることにします。

• 山梨県　笛吹市：観光・地図情報　施設一覧

どうやら町営の施設らしく、腕章をつけた管理人（？）監視人（？）のような人がパイプ椅子に座っています。 足湯は 2,30 人くらいが浸かれそうな広さ。 まぁ、浸るといっても足を突っ込む程度なので、実際の広さは大したことないわけですが。 ぼくらが着いたときには、二家族と二カップルくらいがお湯に足を浸していました。 その脇のほうで、ぼくらも足を浸します。

歩き回って疲れた足をぬるま湯に浸して、正面に見えるは富士山。 いやぁ、至福です。 次の電車までの 25 分ほどをなかなか有意義に過ごすことができました。

勝沼ぶどう郷駅のそばに、明治期から最近まで使われていた鉄道トンネルがあり、今は遊歩道として整備されているということで行ってみました。

• 大日影トンネル遊歩道 - Wikipedia

さすがにトンネルは移設により閉鎖されることもなく、ちゃんとその場所にありました。 が、公開は 15:00 までとのことで、着いたときには既に大きな鉄柵でふさがれていました。 とことんついていない・・・。 さすが、ワインカーヴに使われるだけあって、柵の間からは非常に冷たい風が吹き渡ってきていました。 遠くに見える出口まで、歩いてみたかった。

再び駅まで戻り、今度はバスで "勝沼ぶどうの丘" という複合観光施設のようなところへ。 ワインを飲めたりするようですが、今回のお目当てはお風呂でした。

• 甲州市勝沼ぶどうの丘
• ぶどうの丘　天空の湯

この温泉の露天風呂の眺望がなかなか素晴らしくて、甲府盆地を眼下に一望できます。 ぼくが入っていたのはちょうど日の沈む頃合で、少しずつあたりが暗く沈んで行き、かわりにあちこちに灯りが入っていきます。 残念ながら雲が出てきてきれいな夕焼けはありませんでしたが、素敵な眺めでした。 お湯も熱すぎず、長居には最適です。 気づいたら40分くらい、ポケーッと露天風呂に浸かっていたようです。 いやー素敵だ。 湯船にお湯を張る文化のある国に生まれてよかったと心底思います。 最初に湯船を発明した人は国民栄誉賞ものだと、常日頃思っています。

酒が飲めない時期だったので、風呂から出て飲むのはぶどうジュース。 これがうまいんだ。 さすが地元産（多分）。 最後に自分用にお土産を買い、タクシーで駅まで戻りました。

帰りはかなり疲れてしまい、殆ど寝ていました。 吉祥寺で晩御飯を食べて帰ろうとしていたのですが、そんな気力もなかったので直帰。

とある資料を作るにあたって、Java で Generics を使った際のパフォーマンスについて調べてみました。

まず、java.lang.ArrayList をベースにして StringArrayList を作成しました。 このクラスは ArrayList 中で型パラメーターを使っている箇所をすべて String に置き換えたものです。 いわゆる String 専用の ArrayList です。 これと同じことは、Generics による ArrayList<String> でも実現できます。 型パラメーターを置き換えただけなので当然ですよね。

それを踏まえて、以下の二つのコードの処理時間を比較して見ましょう。

StringArrayList stringArrayList = new StringArrayList(ARRAY_LENGTH);
...
for (int i = 0; i < ARRAY_LENGTH; ++i) {
    String str = stringArrayList.get(i);
}

ArrayList<String> arrayList = new ArrayList<String>(ARRAY_LENGTH);
...
for (int i = 0; i < ARRAY_LENGTH; ++i) {
    String str = arrayList.get(i);
}

すると 1M 要素でおよそ 130-150% ほど StringArrayList のほうが速いという結果になりました。 この理由を探るためにコンパイル後の *.class を逆コンパイルしてみました。

        for(int i = 0; i < 0xf4240; i++)
        {
            String s = stringArrayList.get(i);
        }

        for(int i = 0; i < 0xf4240; i++)
        {
            String s1 = (String)arrayList.get(i);
        }

注目すべきは Generics を使用した場合のキャストです。 対照実験として次のコードを測定してみます。

for (int i = 0; i < ARRAY_LENGTH; ++i) {
    Object obj = arrayList.get(i);
}

この場合は stringArrayList と arrayList で速度に差はなく、逆コンパイルの結果は次のようになっていました。

        for(int i = 0; i < 0xf4240; i++)
        {
            Object obj = arrayList.get(i);
        }

キャストがありません。 このことから、自動的に実行されるキャストが、Generics を使った ArrayList のパフォーマンスを押し下げている可能性が高いと結論付けられます。

さすがに、いまさら特定型専用の Collections を再発明すべきだとは思いませんが、本当にカッツカツにパフォーマンスを求める場合はこのあたりも気にする必要があるんですね。

酒の席の議論がなかなか面白かったのでこちらでも展開。 Java プログラミングを対象とした話です。

• null check は呼び側で行う？呼ばれ側で行う？
• null check を怠って NullPointerException を投げていいの？

つまり、

void methodA () {
      ...
      methodB (str);
}

void methodB (String str) {
      if (str != null) {
          return;
      }
       ...
}
（呼ばれ側主義）

とするか、

void methodA () {
      ...
      if (str != null) {
          methodB (str);
      }
}

void methodB (String str) {
       ...
}
（呼び側主義）

とするか。

呼ばれ側主義者の主張はこう。

• 呼び元で null check すると複数箇所に同じ check コードが分散し、コード量を増大させる
• null check をせずに NullPointerException が発生するのは恥ずかしい
• 事実これまで、呼ばれ側で null check しないと困ることが多かった（プラグマティズム）

一方、呼び側主義者の主張はこう。

• メソッド先頭に null check の if 文がずらずらと並ぶのは可読性を損ねる
• JDK のライブラリ群だって null を入れたら NullPointerException を投げている

この議論は平行線をたどり、お互い決定打が出ずなんとなくもやっとしたまま次回に持ち越されました。

ここから、その後にいろいろ考えた末の私見です。 ちなみに、ぼくは呼ばれ側主義穏健派の立場です。 呼ばれ側でもちろん行うべきであるが、さらに呼び元でもチェックするにやぶさかではない、と。

ぼくはこの話は、

• 前提条件をチェックすべきはどんなとき？チェックするならどこで？
• 前提条件を満たさなかった場合、呼び元にどう伝える？

という二つの話に分解すべきではなかろうかと考えています。 議題に現れる null check と NullPointerException という概念が、一見 null というキーワードでつながっているように見えますが、実は一方は処理の前提条件の話で、一方は処理失敗を伝える話なのではなかろうかと。

処理失敗にも二種類あります。 実行前に発生が予見できないものと、できるものです。 前者の代表例は OutOfMemory など java.lang.Error のサブ・クラスとなっているものです。 後者は、前提条件が満たされていないまま処理が実行された場合が挙げられます。 例えば次のような処理の場合、

    String name = item.getName();

item が非 null であることが処理の暗黙の前提条件となっています。 もし前提条件が破られた場合は例外が発生します。 この例外は、

    if (item == null) {
        return;
    }
    String name = item.getName();

のように、明確に前提条件を確認することで回避可能です。 特に、たとえば次のような場合、

• コストの高い処理を行う
• 副作用を伴う処理を行う

「やってみたけど途中でだめになりました」となった場合の影響が大きいため、処理の前に前提条件を確認し、条件が満たされていないのであれば、はじめから実行すべきではありません。 null check はこういった前提条件確認の典型で、他にも例えば値域や非零の確認なども考えられます。

次に、連続する処理の前提条件について考えてみます。 例えば次のような処理の場合を考えます。

    ...
    /*
     * アイテムを追加する
     */
    // item の null check
    if (item == null) {
        return;
    }
    // 追加
    ++ this.itemCount; // 副作用あり
    this.items.put(item.getId(), item); // null check のおかげで何事もなく完了

    /*
     * 割引率を適用する
     */
    // discount の値域チェック
    if (discount < 0 || 100 < discount) {
        // 割引率が 0-100 の範囲になければ例外
        throw new IllegalArgumentException
            ("dicount should be between 0 and 100");
    }
    // 適用
    this.totalPrice += item.getPrice() * (1D - (double) discount / 100D);
    ...

全体としては、アイテム追加と割引率適用の大きく二つの処理から構成されています。 アイテム追加の直前に item の null check が行われているので、アイテム追加処理は正常に完了します。 割引率の適用処理も直前に値域を判断しているので、定価を超えたりマイナスになったりすることはありません。 個々の処理は正常に完了します。 しかし、item が非 null かつ discount が負値の場合などには、アイテム追加処理の正常完了後に例外が発生してしまい、アイテム追加処理の副作用だけが残ってしまいます。 このように後続の処理が失敗すると、先行処理の取り消しが必要になるような場合があるため、前提条件の確認はできる限り早い段階で行うべきであると言えます。

    ...
    /*
     * 前提条件を確認する
     */
    // item の null check
    if (item == null) {
        return;
    }
    // discount の値域チェック
    if (discount < 0 || 100 < discount) {
        // 割引率が 0-100 の範囲になければ例外
        throw new IllegalArgumentException
            ("dicount should be between 0 and 100");
    }

    /*
     * アイテムを追加する
     */
    ++ this.itemCount; // 副作用あり
    this.items.put(item.getId(), item); // null check のおかげで何事もなく完了

    /*
     * 割引率を適用する
     */
    this.totalPrice += item.getPrice() * (1D - (double) discount / 100D);
    ...

では、どこまで早い段階であれば良いのでしょうか。 これがまさに議論になった「呼び元側（より早い段階）で行うべき」か「呼ばれ側（それよりは遅い段階）で行うべき」かという論点に解を与える話かと思います。 先ほどの例に挙げた処理が、ひとつのメソッドであるとしましょう。

public void addItem(Item item, int discount) {
    /*
     * 前提条件を確認する
     */
    // item の null check
    if (item == null) {
        return;
    }
    // discount の値域チェック
    if (discount < 0 || 100 < discount) {
        // 割引率が 0-100 の範囲になければ例外
        throw new IllegalArgumentException
            ("dicount should be between 0 and 100");
    }

    /*
     * アイテムを追加する
     */
    ++ this.itemCount; // 副作用あり
    this.items.put(item.getId(), item); // null check のおかげで何事もなく完了

    /*
     * 割引率を適用する
     */
    this.totalPrice += item.getPrice() * (1D - (double) discount / 100D);
}

メソッドが呼ばれた時点で引数の値は確定しています。 前提条件の確認はできるだけ早く行うという原則に従い、確認は呼び出し直後よりも後に行うべきではありません。 では、それよりも早い時点ではどうでしょう。 呼び側が呼ぶ直前でも値は確定しています。 呼び側で前提条件を確認する場合を考えてみましょう。

public class Main {
    public void main (String [] args) {
        ...
        if (item == null) {
            ...
        } else if (discount < 0 || 100 < discount) {
            ...
        } else {
            cart.addItem(item, discount);
        }
        ...
    }
}

public class Cart {
    public void addItem(Item item, int discount) {
        /*
         * アイテムを追加する
         */
        ++ this.itemCount; // 副作用あり
        this.items.put(item.getId(), item);

        /*
         * 割引率を適用する
         */
        this.totalPrice += item.getPrice() * (1D - (double) discount / 100D);
    }
}

処理全体としては先ほどと変わりなく、前提条件が満たされた場合のみ処理が行われます。 しかし、クラスの堅牢性を考えると、この例は非常に大きな問題を孕んでいると言えます。 items と totalPrice の整合性に責任を持つべきは Cart（呼ばれ側）です。 しかしこの例では、Cart 自身は整合性を保つために必要な前提条件確認を行っていないため、悪意（もしくはミス）により不正な引数が与えられると壊れる、非常に脆弱なクラスとなっています。 引数としてどのような値を受け入れるかはクラスに属すべき情報であり、特に public メソッドはクラス内外の境界をなすため、引数のチェックは確実に行うべきです。

今回の議論の範囲からは少し外れますが、メソッドの先頭で前提条件を記述することで、そのメソッドが受け入れられる引数の範囲を "コードで" 明確化することができると考えています。 これは特にコードにアクセスできる開発者にとって、コードの可読性が高まるというメリットがあります。 もちろん、前提条件を確認すれば万事 OK なのではなく、別途明確に文書化もすべきですが。

ここまでをまとめると、

• 処理の前提条件はできる限り早くに確認すべし
• 堅牢性の観点から、前提条件の確認をクラスの外のみで行うべからず
• 上記二つより、特に public メソッドの引数は呼び出し直後に確認すべし
• 副次的に、読みやすくなるというメリットもあるよ

という主張になります。

前提条件を満たさなかった場合には、呼び側にその旨を伝える必要があります。 その代表的な方法として以下のようなものが考えられます。

1. 例外を投げる
2. 戻り値として null を返す
3. 戻り値としてエラーを示すオブジェクトを返す
4. 引数として渡されたオブジェクトにエラーを示すオブジェクトを埋め込む

これらの方法は、伝えられる情報 / 呼び元への依存性 / コストなどがそれぞれ異なります。 こういったメリット / デメリットを考慮し、またはアプリケーションの設計方針に従って、前提条件が満たされていなかった旨を呼び元に戻す手段を決定します。

議論に挙がった "NullPointerException" を投げるべきか否かも、この枠組みで考えるべきものです。 検討した結果 NullPointerException を投げるべき場合もあります。 しかし、NullPointerException は "null でした" という非常に汎用的な意味しか持ちません。 アプリケーション上では、それはもっと特化した意味を持つはずです（引数が不正であるとか、結果としてユーザー情報の取得が行えないとか）。 アプリケーション・コードは、それらの意味を適切に呼び側に伝える必要がある場合が殆どなので、NullPointerException をそのまま返すことはあまりないと言えるでしょう。 JDK のライブラリ群が NullPointerException を投げるのは、アプリケーションとは違って NullPointerException は文字通り NullPointerException の意味しかもてないためであると考えられます。 それに意味を加えるのは、JDK のライブラリを呼ぶ側のアプリケーション・コードの役割です。

ここまでをまとめると、

• 前提条件を満たさない場合は適切な方法でその旨を呼び側に戻すべし
• null check の結果を NullPointerException で戻すことも考えるべし
• しかし、アプリケーション・コードは NullPointerException ではなくより適切な情報を戻すべし
• 非常に汎用的なライブラリなどでは NullPointerException も辞さない覚悟で

といった主張です。

これまで、null check を呼ばれ側で行うことを当然のことと捉えていたため、それがなぜなのかを深く考えたことがありませんでした。 改めて分析したところ、やはり呼ばれ側で行うべきだとの思いを強くした次第です。 いかがでしょう。