4

このトピックを読みました: != null ステートメントの回避ですが、利点がわかりません。

  1. 空の配列を返す場合は、「実際の」配列がどこにあり、空の配列がどこにあるかを調べる必要があります。

  2. のようなコードを使用する代わりに、 を使用getName() != nullする必要がありますgetName().length > 0。例として、私はいくつかのデータをいくつかのアーカイバーで圧縮する必要があるプロジェクトに取り組んでおり、最小サイズの圧縮データを選択することにしました。アーカイバの「compress」メソッドから null を返す場合、返された値が null でないことを確認する必要があります。空の配列を返すことにした場合は、空の配列もチェックする必要があります。

私は正しいですか？

4

3 に答える 3

11

nullの代わりに空のコレクションまたは「空白」アクションを使用する主な利点は、ほとんどの場合、そのようなオブジェクトがさらに変更されることなくコードで機能することです。そのnull本質的な価値は、その性質上、エラーが発生しやすいということです。

たとえば、次のコードを考えてみましょう。

String[] names = data.getNames();
if (names != null) {
    for (String name : names) {
        // Do stuff
    }
}

のチェックnullが必要です。そうでない場合は、NPEを取得します。標準のforループを使用しても、問題は解決しません。一方、常に何らかの配列を取得することがわかっている場合は、追加のチェックを行わなくてもコードは正常に機能します。配列が空の場合、ループはまったく実行されません。問題が解決しました。

何らかのアクションを実装するコードについても同じことが言えます。もう一つの例：

Action myAction = data.getActionToRun();
if (myAction != null) {
    myAction.run();
}

もう一度、nullチェックが必要です。アクションが存在することが保証されている場合は、action.run()副作用なしでいつでも呼び出すことができますが、空白のアクションは何もしません。とても簡単です。

多くの場合、nullメソッドの戻り方法を変更すると、チェックを単純に破棄できるため、コードがはるかに単純で理解しやすくなります。デフォルトの「アクションレス」値がないため、場合によっては、戻るnullことが正しい選択です（たとえば、キーと値のコレクションからオブジェクトを取得する）。ただしnull、値がまったくないことを示しており、レシーバーとして追加の処理が必要です。空白のアクションのないnull以外のオブジェクトを使用すると、データオブジェクトでエラーを処理できます。それは良いカプセル化です。良いプログラミングです。それはうまくいきます。™</p>

最後に、戻るnullことは確かにエラーを処理するための良い方法ではありません。コードで問題が発生した場合、プログラマーがプログラミングの間違いを犯さない限り、問題が発生することはありません。sまたは例外を使用してassertください。それらは失敗です。null失敗の場合として使用するのではなく、単純な値の欠如として使用してください。

于 2012-07-20T05:13:18.123 に答える
7

空の配列は、時々返されるより自然なオブジェクトです。次のようなコードを検討してください。

String [] elements = getElements();

for (String element : elements)
   System.out.println(element);

空の配列 (つまり、要素がない) を返す場合、何も出力されず、コードは正しく実行されます。ただし、getElements() が null を返す場合は、null ポインター例外が発生します。それを防ぐには、さらにコードを追加する必要があり、事態がより複雑になります。空の配列を返すと、コードを追加しなくても目的の動作を実行できます。

于 2012-07-20T05:02:37.623 に答える
1

そんな思いがしばらくありました。NPE の問題はしばらく脇に置いておきます。OOP の観点から私の考えを説明しようと思います。

Glass インスタンスのゲッターを提供するクラスを作成するとします public Glass getGlass()。この署名を読んだとき、Glass インターフェイスのインスタンスを期待していますが、null はそうではありません。

次のアプローチを検討できますpublic Optional<Glass> getGlass()。

Optional クラス (独自に記述したり、Google の guava Optionalを使用したりできます) には、汎用クラスのインスタンスが含まれており、とりわけ isPresent関数を提供しています。クライアントコードgetGlass() != nullの代わりに使用できる冗長な原因に見えるかもしれません。getGlass().isPresent()しかし、ここでの主な利点は、署名が単純であることです。誰も何も隠しませんし、推測する必要もありません。

したがって、次の利点が得られます。

  1. NPEの回避
  2. 直筆サイン
  3. きれいなクライアント コード
于 2012-07-21T14:10:17.943 に答える