5

数日前に初めて OOP の原則を知ったばかりだったので、私は何年もの間、「教えて、尋ねるな」という OOP の原則を見落としていたに違いありません。

しかし、コンテキストは、ASP.NET Web フォーム ページからデータ/ビジネス オブジェクトに移動された検証コードについての議論であり、「Validate()」メソッドはなく、それ自体が検証と検証を行う save メソッドだけでした。 （おそらく）例外を発生させました。なぜこれがこのように設計されたのかを尋ねたところ、聞いたことのない OOP の「言うな、聞くな」という原則に導かれたので、一緒に Google を調べたところ、すぐに教えてもらいました。;)

データがユーザーから引き渡され、処理および/または収集されるビジネス層に渡される前に、データをスクラブするべきではありませんか? その逆ではありませんか? これがどのように良いデザインになるのか、私は混乱しています。

「教えて、尋ねるな」というルールは、ターゲット オブジェクトの状態についてターゲット オブジェクトに尋ねてはならないという考えに関連しているように思われます。この原則は、対象物。

4

3 に答える 3

4

大量の「ベスト プラクティス」と「設計方法論」が間違っているように聞こえると思いましたが、今では意味が通じます。このように見てください：

検証をビジネス オブジェクトに配置し、「検証が失敗した場合はどうすればよいか」をプレゼンテーション レイヤーに配置することを想像してください。これにより、複数の異なるプレゼンテーション レイヤーが同じ検証ロジックを再利用できますが、エラーの処理方法が異なります。

public Foo
{
  Validate(Baz bar)
  {
      if(!is_number(bar)) throw numberexception();
  }

  AssignBar(Baz bar)
  {
      Validate(bar);
  }
}


//...

try
{
  foo.AssignBar(bar);
}
catch(numberexception e)
{
  alert('Not a number!');
}

例外をスローすることについて、あなたが望むすべてを主張することができます.nbは、例として意図されていました。状態、ブール値など、必要なものを返します。

于 2009-02-18T16:33:54.330 に答える
2

私はAviewAviewに同意しますが、ユーザーが指示した場合にのみ例外をスローします（彼が尋ねた場合ではありません）：

public Foo
{
  bool Validate(Baz bar)
  {
        if(!is_number(bar)) return false;
        return true;
  }

  AssignBar(Baz bar)
  {
        if (!Validate(bar)) throw numberexception();
  }
}

教えて：

try
{
  foo.AssignBar(bar);
}
catch(numberexception e)
{
  alert('Not a number!');
}

聞く：

if (foo.Validate(bar)
{
  foo.AssignBar(bar);
}
else
{
  alert('Not a number!');
}

したがって、AssignBar は VALID バーを期待し、そうでない場合は例外をスローしますが、例外をスローしない Validate へのメソッドも提供します。

于 2009-02-18T16:43:17.087 に答える
0

これは「聞くな」というよりも「関心の分離」の問題なのだろうか。データの検証は誰の責任ですか? 間違いなく、それはそれを永続化する責任があります。

もちろん、複数のレイヤーでデータを検証すると便利な場合もあります。あなたのアプリがこれに該当する場合、「ユーザー」レイヤーで検証ロジックを公開しても問題ありません。しかし、私はまだビジネス層でそれを望んでいます。

于 2009-02-18T16:43:40.080 に答える