Hatena::ブログ(Diary)

今日の役に立たない一言 − Today’s Trifle! −

2005-11-07

[]developerWorks新着記事 developerWorks新着記事を含むブックマーク developerWorks新着記事のブックマークコメント

Javaの理論と実践: パフォーマンスに関する都市伝説を再検証する
[日本語] [英語(原文)]

この記事について、id:kazama さんがいいこと書いてる。

[]NAgileで始める実践アジャイル開発 NAgileで始める実践アジャイル開発を含むブックマーク NAgileで始める実践アジャイル開発のブックマークコメント

全体的にとてもいい感じ。シンプルに考える方向性が、自分の考え方とかなり似ている。

ひとつだけ違うなと思ったところがあったり。

  private bool 日付として正しい
  {
    get { return 年が正しい && 月が正しい && 日が正しい; }
  }

ここんとこ、C# の書き方はよくわからんけど、return のところに論理式を書くのは個人的にはあまり好きじゃない。個人的には(C# の書き方がわからんから Java で書くと)

  private boolean 日付として正しい  {
    if (!年が正しい) {
      return false;
    }
    if (!月が正しい) {
      return false;
    }
    if (!日が正しい) {
      return false;
    }
    return true;
  }

みたいに書く。

あと、コンストラクタで例外を出すのはあまり好みじゃなかったり。というのは、「13月32日」というのを言葉に出す人がいるんだから、概念的には「13月32日」という Date は生成できてもかまわない。現実的な問題としては、それって太陽暦や太陰暦では不当な日付だけど、その日付がありうる暦があってもいいやん、て感じ。

そういう観点からすると、

  public boolean 日付として正しい  {
    if (!年が正しい) {
      return false;
    }
    if (!月が正しい) {
      return false;
    }
    if (!日が正しい) {
      return false;
    }
    return true;
  }

として、Date クラスを使う側に正当性の検査を任せたい。

[]あり得ないデータを持つインスタンスの生成を禁止すべきではない あり得ないデータを持つインスタンスの生成を禁止すべきではないを含むブックマーク あり得ないデータを持つインスタンスの生成を禁止すべきではないのブックマークコメント

一般的には、あり得ないデータだからという理由でインスタンスの生成を禁止するのは好ましくない。たとえば、何らかの理由で「あり得ない」範囲に変化があったとする。その変化によって、従来は生成できなかったインスタンスを生成しなければならなくなったり、またはその逆で、生成できていたインスタンスが生成できなくなったりする可能性がある。

後者の、従来は生成できていたインスタンスが生成できなくなるケースは、システムに大きな影響を及ぼすことがある。単純な例で言うと、郵便番号の7桁化がある。郵便番号または住所クラスがあったとして、郵便番号の7桁化に伴って5桁の郵便番号を持つインスタンスを生成できなくしてしまうと、既存のデータを扱うことができなくなる。

あり得ないデータを持つインスタンスは、思考の上では存在し得るのだから、それを禁止するのは思考と実装のアンマッチが発生してしまう。このアンマッチが存在すると、何かのはずみでバグの原因になりかねない。

あり得ないデータを持つインスタンスを許容すると、どこで正当性をチェックすべきかと言う問題が出てくる。これは Validator クラスを用意するのが適切な解決策のひとつだと言える。

システムとシステム外部の接点となる部分では、あり得ないデータを持つインスタンスを生成できるようにしておき、Validator のチェックを通過したものだけがシステムロジック内に侵入できるようにすればよい。



10000番ポートがブロックされている環境ではこちらのカウンターは表示されません2004/02/29に値が壊れたすごいカウンター
←はてなカウンター