3

私は通常、Guava の Precondition メソッドを介して、ほぼすべてのコンストラクターとパブリック メソッドのパラメーターをチェックしています。通常、アサーションを伴うプライベート メソッド パラメーター。ただし、現在、「内部」前提条件チェック、つまりコンストラクター/ファクトリメソッド/一般的なメソッド (パブリック API/アプリケーション API の一部ではない) のチェックをアサーションに置き換えることを考えています。 ? 私はたくさんのチェックをしているので、この方法は少し速いかもしれません;-)

編集:パブリックAPIの一部であってはならないパブリックコンストラクターとファクトリも意味します。たとえば、内部で使用されます:

/**
 * Constructor with both, complete and modifying page.
 * 
 * @param complete
 *          to be used as a base for this container
 * @param modifying
 *          to be used as a base for this container
 */
public NodePageContainer(final @Nonnull NodePage complete,
    final @Nonnull NodePage modifying) {
  assert complete != null;
  assert modifying != null;
  mComplete = complete;
  mModified = modifying;
}

私が持っていた前にmComplete = checkNotNull(complete);...しかし、それは別のパッケージのクラスからのみ呼び出され、パブリックAPIの一部であってはなりません. Javaがそのようなクラスの可視性を減らすことを許可するなら素晴らしいでしょう;-)

4

3 に答える 3

7

アサーションと前提条件は同じものではありません。

アサーションは、不変条件が尊重されていることを確認します。つまり、独自のアルゴリズムが期待どおりに機能することを確認します。たとえば、乱数発生器によって生成される数値は常に正です。すべてが正常に機能し、アサーションの失敗がないことを確認したら、それらを非アクティブ化できます。

Guava の前提条件は、呼び出し元が無効な引数を渡さないこと、または呼び出してはならないメソッドを呼び出さないことを確認します。たとえば、引数としてメソッドに渡された制限がnextInt()0 より大きいかsetSeed()、ランダム ジェネレーターの開始後に呼び出されていません。

APIの呼び出し元がその契約を尊重することを強制することが目標である場合、アサーションではなくグアバの前提条件を使用します。

于 2012-10-18T09:48:16.557 に答える
3

によると、API 公開メソッドにEffective Javaはチェック ( Preconditions) を使用し、非 API メソッドにはアサーションを使用する必要があります。これは、チェックを使用しないprivate、または使用する必要があるメソッド/コンストラクターを意味します。package privateWRT、privateおよびpackage private、デバッグを支援するために展開の早い段階でアサーションを有効にすることを提案してアサーションを使用し、信頼が高まりパフォーマンスが問題になるにつれて本番サイクルの後半でそれらを無効にすることを選択する方が効率的です。

于 2012-10-18T10:34:02.643 に答える
0

私はあなたの推論に同意しますがPrecondition、あなたの例で使用します。コンストラクターは外側から見えるので、いつか誰かがそれを呼び出すことは間違いありません。そして、テストはとても安いので、面倒な価値はありません.

実際には、それが私の補助的な基準です。私はほとんどの場合、API / 非 API の原則に従って決定しますが、非常に安価または非常に高価なチェックを例外にすることもあります (コンテキストとチェックの欠落による損害の可能性にもよります)。

于 2012-10-18T14:52:10.667 に答える