引数でJava 8のオプションを使用しない理由


392

多くのWebサイトで読みましたOptionalは戻り値の型としてのみ使用し、メソッドの引数では使用しないでください。論理的な理由を見つけるのに苦労しています。たとえば、2つのオプションパラメータを持つロジックがあります。したがって、次のようにメソッドシグネチャを記述することは理にかなっていると思います(ソリューション1):

public int calculateSomething(Optional<String> p1, Optional<BigDecimal> p2 {
    // my logic
}

多くのWebページでは、オプションをメソッドの引数として使用しないでください。これを念頭に置いて、次のメソッドシグネチャを使用して明確なJavadocコメントを追加し、引数がnullになる可能性があることを指定します。将来のメンテナがJavadocを読み、引数を使用する前に常にnullチェックを実行することを期待します(解決策2) :

public int calculateSomething(String p1, BigDecimal p2) {
    // my logic
}

または、より良いインターフェイスを提供し、p1とp2がオプションであることをより明確にするために、メソッドを4つのパブリックメソッドに置き換えることもできます(ソリューション3)。

public int calculateSomething() {
    calculateSomething(null, null);
}

public int calculateSomething(String p1) {
    calculateSomething(p1, null);
}

public int calculateSomething(BigDecimal p2) {
    calculateSomething(null, p2);
}

public int calculateSomething(String p1, BigDecimal p2) {
    // my logic
}

次に、各アプローチのこのロジックを呼び出すクラスのコードを記述してみます。最初に、Optionals を返す別のオブジェクトから2つの入力パラメーターを取得し、次にを呼び出しcalculateSomethingます。したがって、ソリューション1を使用する場合、呼び出しコードは次のようになります。

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1, p2);

ソリューション2を使用する場合、呼び出しコードは次のようになります。

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1.orElse(null), p2.orElse(null));

ソリューション3が適用されている場合、上記のコードを使用するか、次のコードを使用できます(ただし、コードが大幅に増えます)。

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result;
if (p1.isPresent()) {
    if (p2.isPresent()) {
        result = myObject.calculateSomething(p1, p2);
    } else {
        result = myObject.calculateSomething(p1);
    }
} else {
    if (p2.isPresent()) {
        result = myObject.calculateSomething(p2);
    } else {
        result = myObject.calculateSomething();
    }
}

だから私の質問です:Optionalsをメソッドの引数として使用するのはなぜ悪い習慣と考えられているのですか(解決策1を参照)? それは私にとって最も読みやすいソリューションのように見え、将来のメンテナーにとってパラメーターが空/ nullである可能性があることが最も明白になります。(私は設計者がOptionalそれを戻り値の型としてのみ使用することを意図していたことを知っていますが、このシナリオでそれを使用しない論理的な理由を見つけることができません)。


16
オプションを使用した場合、パラメーターとして渡されたオプションがそうでないことを確認する必要はありませんnullか?
biziclop 2015

17
はい。ただし、将来コードを維持している他の人には、パラメータが空/ nullになる可能性があることが明らかになるため、将来的にはnullポインタ例外を回避できる可能性があります
Neil Stevens

1
ワオ。メソッドに渡されるnull引数?それはとてもVisual Basicです。それはどの原則に違反していますか?SRP(たぶん)。また、メソッドまたは関数がその仕事を行うために必要な情報のみを渡すという流れに沿って名前が変更されるという別の原則にも違反しています。
ルミナス

20
理論的にはnullになる可能性のあるすべてのものは、System.exit(0)を呼び出す可能性のあるライブラリ内のすべてのメソッドと同じです。tisに対してチェックすることはできません。これをチェックするべきではありません。あなたが実際にやらなければならないすべての時間にあなたがしなければならないすべては(ほとんど)決してやるべきではありません。すべてのパラメータを最終的にするように。あなたのツールを使って、パラメーター値の変更やフィールドの初期化を忘れずに、1,000回のファイナルや多くのnullチェックでコードを読み取れなくすることができます。
ヨーマン2017

6
実際には、NonNull / Nullableアノテーションを使用するだけです。これは、この状況で探しているものであり、オプションではありません。
ビルK

回答:


202

ああ、それらのコーディングスタイルは少しの塩で取られるべきです。

  1. (+)セマンティック分析なしで、オプションの結果を別のメソッドに渡す。それをメソッドに任せても大丈夫です。
  2. (-)メソッド内で条件付きロジックを引き起こすオプションのパラメーターを使用すると、文字通り生産性が低下します。
  3. (-)オプションに引数をパックする必要があることはコンパイラにとって最適ではなく、不要な折り返しを行います。
  4. (-)null許容パラメーターと比較して、オプションの方がコストが高くなります。

一般に、オプションは2つの状態を統合しますが、それらは解明する必要があります。したがって、データフローの複雑さのために、入力より結果に適しています。


38
実際、を有するOptional:パラメータは、3つの状態の1つを表すnullオプション、非ヌルOptionalisPresent() == false非ヌルOptional実際の値をラップします。
biziclop

16
@biziclopはい、避けられない点はすでに批判されています。ただし、その目的は、null以外の式のみを持つことです。オプショナルを避けるためのアドバイスを聞くのに時間がかからなかったことも、かなり皮肉なことです。A @NotNull Optional
Joop Eggen、2015

80
@biziclopまったく使用Optionalしている場合、状態1(nullオプション)は通常プログラミングエラーを示しているため、処理できない場合もあります(単にスローするだけですNullPointerException
user253751

50
「コンパイラーにとっては最適ではない」、「null許容パラメーターと比較して、オプションの方がコストがかかる」-これらの引数は、Java言語ではなくC言語に対して有効である可能性があります。Javaプログラマーは、クリーンなコード、移植性、テスト容易性、優れたアーキテクチャー、モジュール性などに焦点を当てる必要があり、「オプションはそのnull参照の方がコストがかかる」ことに焦点を当てるべきではありません。そして、マイクロ最適化に集中する必要があるとわかった場合は、オブジェクト、リスト、ジェネリックスをスキップして、配列とプリミティブに切り替えることをお勧めします(ここでは不快になりたくないので、自分の意見を共有しています) 。
Kacper86 2016年

15
「コンパイラーにとって最適ではない」:時期尚早な最適化はすべての悪の根源です...パフォーマンスが重要なコードを記述していない場合(クリーンなインターフェイスを指定しようとする場合によくあることです)、これは問題になりません。
Mohan

165

このトピックについて私が見た中で最高の投稿は、Daniel Olszewskiによって書かれました。

必須ではないメソッドパラメータに対してオプションを検討するのは魅力的かもしれませんが、そのような解決策は他の可能な代替案と比較すると見劣りします。問題を説明するために、次のコンストラクタ宣言を調べます。

public SystemMessage(String title, String content, Optional<Attachment> attachment) {
    // assigning field values
}

一見すると、それは正しい設計上の決定に見えるかもしれません。結局、添付パラメーターを明示的にオプションとしてマークしました。ただし、コンストラクターの呼び出しに関しては、クライアントコードが少し不格好になる可能性があります。

SystemMessage withoutAttachment = new SystemMessage("title", "content", Optional.empty());
Attachment attachment = new Attachment();
SystemMessage withAttachment = new SystemMessage("title", "content", Optional.ofNullable(attachment));

明確さを提供する代わりに、Optionalクラスのファクトリメソッドは、読者の注意をそらすだけです。オプションのパラメーターは1つしかありませんが、2つまたは3つあることを想像してください。ボブおじさんは間違いなくそのようなコードを誇りに思っていません😉

メソッドがオプションのパラメーターを受け入れることができる場合、実績のあるアプローチを採用し、メソッドのオーバーロードを使用してそのようなケースを設計することをお勧めします。SystemMessageクラスの例では、2つの別個のコンストラクターを宣言する方が、Optionalを使用するよりも優れています。

public SystemMessage(String title, String content) {
    this(title, content, null);
}

public SystemMessage(String title, String content, Attachment attachment) {
    // assigning field values
}

この変更により、クライアントコードがよりシンプルで読みやすくなります。

SystemMessage withoutAttachment = new SystemMessage("title", "content");
Attachment attachment = new Attachment();
SystemMessage withAttachment = new SystemMessage("title", "content", attachment);

10
1つまたは2つの段落のみが関連している場合、これは多くのコピー+貼り付けです。
Garret Wilson

47
残念ながら、この説明は、発信者がいつ解析するかなどの懸念に対処していません。メソッドのオーバーロード(上記で推奨)を使用する場合、呼び出しコードは「Xが存在するか?存在する場合、オーバーロードされたメソッドAを呼び出します。Yが存在するか?オーバーロードされたメソッドBを呼び出す必要があります。XとYの場合存在する場合は、オーバーロードされたメソッドCを呼び出す必要があります。」等々。これには良い答えがあるかもしれませんが、この「なぜ」の説明はそれをカバーしていません。
Garret Wilson

9
また、コレクションに関しては、空のコレクションとコレクションがない場合との間には明確な違いがあります。たとえば、キャッシュ。キャッシュミスでしたか?空のオプション/ null。空のコレクションであるキャッシュヒットはありましたか?完全オプション/コレクション。
Ajax

1
@Ajax私はあなたが記事を誤解していると思います。彼らは、Effective Javaの本が提唱しているポイントを引用しています。これは、メソッドの戻り値の型がコレクションである場合(キャッシュが返す任意のオブジェクトではない)、nullまたはの代わりに空のコレクションを返すことを支持するべきだと述べていますOptional
Gili

4
もちろん、あなたはそれを支持すべきですが、常にいくつかのコードを制御できるわけではありません。そして、非常に現実的な意味で、「値があり、空のコレクションです」と「ありません」を区別したい場合があります。値は(まだ)定義されています。」「マジックヌル」も推奨されない方法であるため、最も悪いオプションを選択するのは開発者であるあなた次第です。実際のキャッシュ値は空のコレクションである可能性あるため、空のコレクションではなく、キャッシュミスを表すために空のオプションを選択します。
Ajax

86

Optionalパラメータとして使用しない理由はほとんどありません。これに反対する議論は、権威からの議論に依存している(Brian Goetzを参照-彼の議論はnull以外のオプションを強制できない)か、またはOptional引数がnullである可能性がある(本質的に同じ引数)。もちろん、Javaでの参照はすべてnullにすることができます。プログラマーのメモリーではなく、コンパイラーによってルールが適用されるようにする必要があります(これは問題があり、スケーリングされません)。

関数型プログラミング言語はOptionalパラメーターを推奨します。これを使用する最良の方法の1つは、複数のオプションパラメータを使用liftM2し、パラメータが空ではなく、オプションを返すことを前提として関数を使用することです(http://www.functionaljava.org/javadoc/4.4/functionaljava/fj/を参照)。 data / Option.html#liftM2-fj.F-)。残念ながら、Java 8はオプションをサポートする非常に限られたライブラリを実装しています。

Javaプログラマーとしては、レガシーライブラリとのやり取りにnullのみを使用する必要があります。


3
代わりにjavax.annotation を使用し@Nonnullたり@Nullable、それを使用したりすることはどうですか?私が開発したライブラリでそれらを幅広く使用しており、IDE(IntelliJ)によるサポートは非​​常に優れています。
ホジェリオ

1
それは結構ですが、あなたはどこでも、このアノテーションを使用する必要があり、あなたがなどマップ、flatMap /バインド、liftM2、配列、支援方法にライブラリを必要とする
マーク・ペリー

14
関数型プログラミング言語は、オプションのパラメーターを推奨します。引用が必要です。ほとんどの関数はオプションを取るべきではありません。代わりに、(適切な高階関数を使用して)値の有無を処理する責任は、問題の関数の呼び出し元にあります。
jub0bs

5
この。実際、どの説得も十分説得力がなく、この特定の質問に答えるものもありません。「メソッドパラメーターとしてオプションを使用することは悪い習慣と見なされますが、メソッドパラメーターに注釈を付ける@NonNullと、異なる方法で同じ目的を果たす場合はまったく問題ありません。」私にとって、少なくともある程度の意味を持つ引数は1つしかありません。「戻り値の型が明確な、より良いAPIを提供するには、オプションを使用する必要があります。ただし、メソッド引数には、オーバーロードされた関数を使用できます。-それでも、これは十分に強力な議論ではないと思います。
UtkuÖzdemir2016

1
もちろん、nullにpreferrableが、何でもよりpreferrableのは良いデザインので、最初の場所で、オプションの値の多くを必要としないことである:D
ヨーマン

12

このアドバイスは、「入力に関してはできるだけ具体的でなく、出力に関してはできるだけ具体的」という経験則の変形です。

通常、null以外のプレーンな値を取得するメソッドがある場合は、それをにマッピングできるOptionalため、プレーンバージョンは入力に関して厳密に不特定です。しかしOptionalそれでも議論を必要とする理由はたくさんあります。

  • 関数を、別のAPIと組み合わせて使用​​して、 Optional
  • Optional指定された値が空の場合、関数は空以外の何かを返す必要があります
  • あなたOptionalはあなたのAPIを使う人は誰でもそれについて学ぶために要求されるべきであるほど素晴らしいと思います;-)

10

とのパターンOptionalは、戻り を回避するためのものnullです。nullメソッドに渡すことは完全に可能です。

これらはまだ正式ではありませんが、JSR-308スタイルのアノテーションを使用nullして、関数に値を受け入れるかどうかを示すことができます。実際にそれを識別するための適切なツールが必要であり、強制可能なランタイムポリシーよりも静的チェックを提供することに注意してください。

public int calculateSomething(@NotNull final String p1, @NotNull final String p2) {}

ここでの問題は、@ NotNullがデフォルトのケースではなく、明示的に注釈を付ける必要があるということです。したがって、怠惰のために人々がやらない定型文やその他のものです。
dwegener

1
@dwegenerはい、しかしOptional問題も修正しないので、注釈に対する私の提案。

2
ドキュメント/ソースを読んだり、ツールがそれをキャッチできる場合にのみ気づくであろうアノテーションを無視するよりも、オプションを無視するほうがはるかに難しいです(静的分析では常にnull可能性を正しく判断できない場合があります)。
Ajax

@Nullableは、nullを有効な値として「受け入れる」ことを意味しないことに注意してください。つまり、例外をスローしません。これは、このケースを防ぐことを意味するだけかもしれませんが、それでも例外をスローします(これはFindbugsセマンティクスです)。そのため、明快さの代わりに、そのような注釈で曖昧さを導入できます。
tkruse 2017年

@ user2986984のあいまいさはわかりません。「nullを処理しない」というのは、現実的には例外がスローされることを意味するだけです。

7

これは私には少しばかげているように見えますが、私が考えることができる唯一の理由は、メソッドパラメータのオブジェクト引数がすでにオプションであるということです-それらはnullになる可能性があります。したがって、誰かに既存のオブジェクトを取り、それをオプションでラップすることを強制することは、一種の無意味です。

そうは言っても、オプションを受け取る/返すメソッドを連鎖させることは、たぶんモナドのようにするのが合理的です。


7
値とフィールドもnullを返すことはできませんか?それで、Optional完全に無意味ですか?
Samuel Edwin Ward、

6

JDK10のJavaDoc、https: //docs.oracle.com/javase/10/docs/api/java/util/Optional.htmlを確認してください。APIノートが追加されています。

API注:Optionalは主に、「結果なし」を表す必要が明確にあり、nullを使用するとエラーが発生する可能性があるメソッドの戻り値の型として使用することを目的としています。


4

私の見解では、オプションはモナドでなければならず、これらはJavaでは考えられません。

関数型プログラミングでは、「ビジネスドメインタイプ」のみに基づいて引数を取り、構成する純粋で高次の関数を扱います。実世界をフィードする、またはその計算を報告する必要がある関数(いわゆる副作用)を作成するには、外界を表すモナドから値を自動的にアンパックする関数(State、Configuration、先物、たぶん、どちらか、作家など...); これはリフティングと呼ばれます。一種の懸念の分離と考えることができます。

これらの2つのレベルの抽象化を混在させることは読みやすさを向上させないので、単にそれを回避する方がよいでしょう。


3

Optionalasパラメータを渡すときに注意するもう1つの理由は、メソッドが1つのことを行う必要があるということです... Optionalparamを渡すと、複数のことを行うことができ、ブールparamを渡すのに似ている場合があります。

public void method(Optional<MyClass> param) {
     if(param.isPresent()) {
         //do something
     } else {
         //do some other
     }
 }

それは正当な理由ではないと思います。オプションが使用されていない場合、paramがnullかどうかをチェックするために同じロジックを適用できます。実際には、if(param.isPresent())オプションを使用するための最良のアプローチではなく、代わりにあなたが使用することができます:param.forEach(() -> {...})
hdkrus

null許容パラメーターを渡さないという考えも好きではありません。とにかく、私はあなたが支持することができると言いました、もちろん、あなたがそれを使うかもしれない例外があります、それはあなた次第です、それを慎重に使ってください、それだけです。すべてのシナリオに適用されるルールはありません。
ポー

2

Optionalをパラメーターとして受け入れると、呼び出し元レベルで不要な折り返しが発生します。

たとえば次の場合:

public int calculateSomething(Optional<String> p1, Optional<BigDecimal> p2 {}

nullでない2つの文字列があると仮定します(つまり、他のメソッドから返されます)。

String p1 = "p1"; 
String p2 = "p2";

それらが空でないことがわかっている場合でも、それらをオプションでラップする必要があります。

これは、他の「マップ可能な」構造で構成する必要がある場合、さらに悪化します。どちらか

Either<Error, String> value = compute().right().map((s) -> calculateSomething(
< here you have to wrap the parameter in a Optional even if you know it's a 
  string >));

ref:

メソッドはパラメータとしてオプションを期待すべきではありません。これはほとんどの場合、呼び出し元から呼び出し先への制御フローのリークを示すコードの臭いです。オプションの内容を確認するのは呼び出し元の責任です

ref。https://github.com/teamdigitale/digital-citizenship-functions/pull/148#discussion_r170862749


1

それは、通常、データを操作するための関数を記述してから、それをOptional使用mapして同様の関数に引き上げるためです。これにより、デフォルトのOptional動作が追加されます。もちろん、で動作する独自の補助関数を作成する必要がある場合もありますOptional


1

私が存在する理由は、最初にOptional自体がnullであるかどうかを確認してから、それがラップする値を評価する必要があるということです。不要な検証が多すぎます。


2
nullのOptional参照を渡すことは、プログラミングエラーと見なすことができます(Optionalは、「空の」値を渡す明示的な方法を提供するため)。
pvgoran

1

Brian Goetzがうまく説明したように、オプションはこの目的のために設計されていません。

@Nullableを常に使用して、メソッド引数をnullにすることができることを示すことができます。オプションを使用しても、メソッドロジックをより適切に記述できるわけではありません。


5
申し訳ありませんが、「設計されていません」または「だれかがそれを推奨していない」という主張には同意できません。具体的にはエンジニアでなければなりません。@Nullableの使用は、Optionalを使用すると、APIの観点から見るとはるかに冗長になるため、はるかに悪くなります。引数としてOptionalsを使用することに対する正当な理由はありません(メソッドのオーバーロードを使用したくない場合)
Kacper86

0

もう一つのアプローチは、あなたができることは

// get your optionals first
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();

// bind values to a function
Supplier<Integer> calculatedValueSupplier = () -> { // your logic here using both optional as state}

関数(この場合はサプライヤ)を構築したら、これを他の変数として渡すことができ、次のようにして呼び出すことができます。

calculatedValueSupplier.apply();

ここでのアイデアは、オプションの値を取得しているかどうかであり、関数の内部詳細であり、パラメーターには含まれません。オプションをパラメーターとして考えるときに関数を考えることは、実際に私が見つけた非常に便利な手法です。

あなたが実際にそれを行うべきかどうかの質問については、あなたの好みに基づいていますが、他の人が言ったように、それはあなたのAPIを控えめに言っても醜いものにします。


0

最初は、オプションとしてパラメーターを渡すこともお勧めしましたが、API-DesignerパースペクティブからAPI-Userパースペクティブに切り替えると、デメリットがわかります。

あなたの例では、各パラメーターはオプションですが、次のように計算方法を独自のクラスに変更することをお勧めします。

Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();

MyCalculator mc = new MyCalculator();
p1.map(mc::setP1);
p2.map(mc::setP2);
int result = mc.calculate();

0

この質問は、難しい事実というよりは意見に関するものであることを知っています。しかし、私は最近、.net開発者からJava開発者に移行したため、最近、オプションパーティに参加しました。また、コメントとしてお伝えしたいのですが、私のポイントレベルではコメントできないので、答えにならざるを得ません。

私が行っていることは、経験則として私に役立っています。戻り値の型にオプションを使用し、オプションの値と天気の両方が必要であるか、オプションにメソッド内の値が含まれていない場合にのみ、パラメーターとしてオプションを使用します。

値のみを気にする場合は、メソッドを呼び出す前にisPresentを確認します。値が存在するかどうかに依存する何らかのロギングまたは異なるロジックがメソッド内にある場合は、オプションで喜んで渡します。


0

これは、APIユーザーとAPI開発者に異なる要件があるためです。

開発者は、正確な仕様と正しい実装を提供する責任があります。したがって、開発者が引数がオプションであることをすでに認識している場合、実装はそれがnullかオプションかに関係なく、正しく処理する必要があります。APIはユーザーにとって可能な限りシンプルである必要があり、nullが最もシンプルです。

一方、結果はAPI開発者からユーザーに渡されます。ただし、仕様は完全で冗長なため、ユーザーがそれに気付かないか、それに対処するのが面倒な可能性があります。この場合、オプションの結果により、ユーザーは空の結果の可能性に対処するための追加のコードを作成する必要があります。


0

まず、方法3を使用している場合、最後の14行のコードを次のように置き換えることができます。

int result = myObject.calculateSomething(p1.orElse(null), p2.orElse(null));

あなたが書いた4つのバリエーションは、便利なメソッドです。それらはより便利な場合にのみ使用してください。それも最良のアプローチです。このようにして、APIはどのメンバーが必要でどれが必要でないかを非常に明確にします。4つのメソッドを記述したくない場合は、パラメーターに名前を付ける方法で明確にすることができます。

public int calculateSomething(String p1OrNull, BigDecimal p2OrNull)

このように、null値が許可されていることは明らかです。

の使用はp1.orElse(null)、Optionalを使用したときにコードがどのように冗長になるかを示しています。これは、私がそれを回避する理由の一部です。オプションは関数型プログラミング用に書かれました。ストリームにはそれが必要です。関数型プログラミングで使用する必要がない限り、メソッドはおそらくOptionalを返さないはずです。メソッドのようにOptional.flatMap()、Optionalを返す関数への参照を必要とするメソッドがあります。ここにその署名があります:

public <U> Optional<U> flatMap(Function<? super T, ? extends Optional<? extends U>> mapper)

そのため、通常は、Optionalを返すメソッドを記述する唯一の正当な理由です。しかし、それでも回避できます。Optionalを返さないゲッターを、関数を適切な型に変換する別のメソッドでラップすることにより、flatMap()などのメソッドに渡すことができます。ラッパーメソッドは次のようになります。

public static <T, U> Function<? super T, Optional<U>> optFun(Function<T, U> function) {
    return t -> Optional.ofNullable(function.apply(t));
}

したがって、次のようなゲッターがあるとします。 String getName()

次のように、flatMapに渡すことはできません。

opt.flatMap(Widget::getName) // Won't work!

ただし、次のように渡すことができます。

opt.flatMap(optFun(Widget::getName)) // Works great!

関数型プログラミング以外では、オプションは避けてください。

ブライアンゲッツは、次のように言ったときに最もよく言った。

OptionalがJavaに追加された理由は次のとおりです。

return Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .findFirst()
    .getOrThrow(() -> new InternalError(...));

これよりもきれいです:

Method matching =
    Arrays.asList(enclosingInfo.getEnclosingClass().getDeclaredMethods())
    .stream()
    .filter(m -> Objects.equals(m.getName(), enclosingInfo.getName())
    .filter(m ->  Arrays.equals(m.getParameterTypes(), parameterClasses))
    .filter(m -> Objects.equals(m.getReturnType(), returnType))
    .getFirst();
if (matching == null)
  throw new InternalError("Enclosing method not found");
return matching;

1
それがJavaに追加された理由の1つです。他にもたくさんあります。データ構造にトラバースするネストされた「if」ステートメントの長いチェーンを、Optional.mapへのチェーンされた呼び出しの単一のシーケンスで置き換えることが私の個人的なお気に入りです。関数型言語のプログラミングの世界では、このように単にnullチェックを置き換えるだけでなく、オプションの多くの興味深い用途があります。
ガイ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.