グアバのオプションクラスのポイントは何ですか

私は最近これについて読んだり、このクラスを使用している人々を見たりしましたが、ほとんどすべての場合、使用nullすることも同様にうまくいきました。誰かOptionalがnullできなかった、またははるかにクリーンな方法で達成できる具体的な例を誰かが提供できますか？私が考えることができる唯一のことMapsは、nullキーを受け入れないでそれを使用することですが、それでもヌルの値の「マッピング」側で行うことができます。誰かがもっと説得力のある議論を私に提供できますか？ありがとうございました。

グアバのチームメンバーはこちら。

おそらく単一の最大の欠点はnull、特定のコンテキストでそれが何を意味するのかが明らかではないことです。これには、説明的な名前がありません。それがnull「このパラメータに値がない」という意味であることが常に明らかであるとは限りません。つまり、戻り値として、「エラー」または「成功」（!!）を意味することもあれば、単に「正しい答えは何もない」こともあります。Optional多くの場合、変数をNULL可能にするときに実際に意味する概念ですが、常にそうであるとは限りません。そうでない場合は、Optional実際の意味を明らかにするために、命名スキームが似ているが異なる命名規則を使用して独自のクラスを作成することをお勧めします。

しかし、私が言う最大の利点はOptional読みやすさではありません。その利点は、ばかであるということです。プログラムをコンパイルする必要がある場合は、存在しないケースについて積極的に考える必要がOptionalあります。それは、を積極的にアンラップして対処する必要があるためです。Nullを使用すると、物事を簡単に忘れることが非常に簡単になります。FindBugsは役立ちますが、この問題にはほとんど対応していないと思います。これは、「存在」する場合としない場合がある値を返す場合に特に関係があります。あなた（およびその他）のことを忘れることがはるかに可能性がありますother.method(a, b)返すことができるnullあなたがそれを忘れるためにそうしているよりも、値をaすることができnull、あなたが実装しようとしているときother.method。戻るOptional 呼び出し側はオブジェクト自体をアンラップする必要があるため、その場合を忘れることはできません。

これらの理由により、Optionalメソッドの戻り値の型として使用することをお勧めしますが、必ずしもメソッドの引数では使用しないでください。

（ちなみに、これはここでの議論から完全に不満です。）

それは本当にMaybeHaskell のモナドパターンに似ています。

次のウィキペディアモナド（関数型プログラミング）をお読みください。

また 、モナドとして使用されるグアバのオプションについては、Kerflynのブログで「オプションからモナドへのグアバへ」を参照してください。

編集： Java8には、のようなモナド演算子を持つ組み込みのOptionalがありflatMapます。これは物議を醸す問題でしたが、ついに実装されました。

http://www.nurkiewicz.com/2013/08/optional-in-java-8-cheat-sheet.htmlを参照してください

public Optional<String> tryFindSimilar(String s)  //...

Optional<Optional<String>> bad = opt.map(this::tryFindSimilar);
Optional<String> similar =       opt.flatMap(this::tryFindSimilar);

flatMapオペレータは、簡単にチェーンコールそのすべての戻りオプションの結果にモナドの操作、および許可を許可することが不可欠です。

考えてみてください。map演算子を5回使用した場合Optional<Optional<Optional<Optional<Optional<String>>>>>、結果flatMapはになりますが、使用するとOptional<String>

Java8以降は、それほど強力ではないGuavaのOptionalを使用したくありません。

これを使用する理由の1つは、ヌルを非常に意味のあるものにすることです。多くのことを意味する可能性のあるnullを返す代わりに（エラー、失敗、空など）、nullに「名前」を付けることができます。この例を見てください：

基本的なPOJOを定義しましょう：

class PersonDetails {

String person;
String comments;

public PersonDetails(String person, String comments) {
    this.person = person;
    this.comments = comments;
}

public String getPerson() {
    return person;
}


public String getComments() {
    return comments;
}

}

次に、この単純なPOJOを使用します。

public Optional<PersonDetails> getPersonDetailstWithOptional () {

  PersonDetails details = null; /*details of the person are empty but to the caller this is meaningless,
  lets make the return value more meaningful*/


    if (details == null) {
      //return an absent here, caller can check for absent to signify details are not present
        return Optional.absent();
    } else {
      //else return the details wrapped in a guava 'optional'
        return Optional.of(details);   
    }
}

ここで、nullの使用を避け、オプションでチェックを実行して、意味のあるものにします。

public void checkUsingOptional () {

    Optional<PersonDetails> details = getPersonDetailstWithOptional();

    /*below condition checks if persons details are present (notice we dont check if person details are null,
    we use something more meaningful. Guava optional forces this with the implementation)*/
    if (details.isPresent()) {

      PersonDetails details = details.get();

        // proceed with further processing
        logger.info(details);

    } else {
        // do nothing
        logger.info("object was null"); 
    }

    assertFalse(details.isPresent());
}

したがって、最終的にはnullを意味のあるものにし、あいまいさを減らす方法です。

Optionalの最も重要な利点は、関数の実装者と呼び出し元の間のコントラクトに詳細が追加されることです。このため、パラメーターと戻り値の型の両方に役立ちます。

Optional可能性のあるnullオブジェクトに対して常に持つ規則を作成する場合は、次のような場合にさらに明確化を加えます。

1. Optional<Integer> maxPrime(Optional<Integer> from, Optional<Integer> to)

   ここでの契約は明らかに結果が返されない可能性があることを指定するだけでなく、それはで動作することを示しているfromとto不在として。

2. Optional<Integer> maxPrime(Optional<Integer> from, Integer to)

   コントラクトはfromがオプションであることを指定しているため、存在しない値はstart from 2のような特別な意味を持つ可能性がtoあります。パラメーターのnull値が例外をスローすると予想できます。

したがって、Optionalを使用することの良い点は、コントラクトが（@NotNull注釈と同様に）説明的であると同時に正式なものになったことです。これは.get()、に対処するコードを記述する必要があるためですOptional。