Java 8およびJava 9のケースまたはオプションのオブジェクト：パート5：贈り物としての未発表とポスター

これは、動的構造を持つオブジェクトを処理するときのOptionalクラスの使用に関するシリーズの5番目と最後の記事です。 最初の記事では、Optionalを使用できない、または使用したくない状況でNullPointerExceptionを回避する方法について説明しました。 2番目の記事では、Java 8で登場したOptionalクラスのメソッドについて説明します。3番目の 記事では、Java 9でクラスに追加されるメソッドについて説明します。4 番目の記事では、データの処理中に失敗した場合にOptionalクラスの機能を拡張するクラスを紹介しましたメソッドでは、この失敗に関する情報を処理する必要があります。



この記事では、ゼロ値が表示される可能性のあるすべての場所でOptionalを使用する必要があるかどうかの問題を調べます。 また、このクラスに関するJava v Oracle言語のアーキテクトであるBrian Goetzの意見も述べます。もちろん、前回の記事で述べた約束を果たします。シリーズのすべての記事を読むすべての読者に貴重な贈り物をお勧めします。

しかし、すべてが間違っている可能性があります

クラス内のさまざまな役割でOptionalを使用することに関する実際的な質問を検討する前に、1つを小さくしたいのですが、私の観点からすると、必要な歴史的余談です。



FP（関数型プログラミング）のJava要素を拡張する問題が頭に浮かんだとき、可能な解決策の範囲は非常に広いように見えました。 最大バージョンでは、LISP、ML、Haskell、OCaml、F＃、Erlang、Clojure、Scalaなどのプログラミング言語でテストされた、最も重要なFPパラダイムの実装でJavaを拡張しようとすることができます。

マキシマリストアプローチの批評家は、一部のFPパラダイムの実装は、以前に言語の実装で行われたアーキテクチャ上の決定によって妨げられる可能性があると警告しました。 さらに、彼らはマスターするには複雑すぎるパラダイムを導入すると、それらの不適切な使用につながることを恐れました。 そして、これは、ほとんどのJavaユーザーが技術革新の全範囲を無視するだろうと脅しました。



いずれにせよ、最終的に、「実用的」と宣言されたアプローチが普及しました。 Java 8では、FPの主要な要素のみがスレッド、関数、ラムダ、およびオプションの形式で表示されました。



受賞アプローチの一部として、公式ドキュメントのOptionalはFPからのモナドパラダイムの実装の1つであると主張していませんでした。 （役割を主張しないということは、役割を果たさないということではありません。詳細はこちらをご覧ください。

そして、それを適用する他の場所は？

その場合、一部のユーザーは自然な質問をしました。クラスのどこにnullが表示される場合でも、オプションを使用する必要があります。



言及された「明確化」オラクルの記事には、明確に「いいえ！



すなわち（私の翻訳では）：

「Optionalクラスの目的は、潜在的にnullオブジェクトへのすべての参照を置き換えることではありません。 目標は、 より理解しやすいAPIを開発して、メソッドの署名によってOptionalが返されることを判断できるようにすることです。 これにより、オプションを積極的に分析してその意味を把握する必要があります。

だからそれ。 しかし、どこで、クラスのどの「場所」または「役割」にOptionalを使用できますか？

フィールド値としてオプション？

具体的に見て、クラス変数（フィールド）から始めましょう。 言及された記事を見てみましょう。 このようなコードは次のとおりです。

public class Computer { private Optional<Soundcard> soundcard; public Optional<Soundcard> getSoundcard() { ... } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

うん！ クラス変数としてOptionalを使用できますか？



可能ですが、ここで覚えておく必要があります。

1. OptionalクラスはSerializebleインターフェイスを実装しません。 これは、このプロパティで使用されるフレームワークを使用して、変数がメディアから正しく保存または読み取られないことを意味します。
2. オプションは、いわゆる値ベースのオブジェクトです。 これは、特に、オブジェクトのインスタンスを相互に比較するための特別なルールを意味します。詳細については、 こちらをご覧ください 。 これは、内部でReflectionメカニズムを使用する一部のフレームワークがそのようなフィールドを誤って処理する可能性があることを意味します。

したがって、クラスのフィールド値の管理者としてOptionalを使用する前に、クラスの潜在的なユーザーが、この準備が整っていないフレームワークを使用してシリアル化または処理する必要がないことを確認してください。



したがって、一部の著者は、これらの潜在的な頭痛に巻き込まれず、オプションではなくフィールドにオブジェクト自体を保存し、クラスをプログラミングするときにゼロになる可能性があることを思い出してください。 そして、オブジェクトを戻り値として外部に「解放」することによってのみ、「case」オプションに入れます。

セッターでオプションを使用する

しかし、潜在的にゼロのクラスフィールドを指定する方法についてはどうでしょうか。 APIでsetSomeObject（オプションの<SomeObject> opt）のようなシグネチャを持つメソッドを提案する価値があるのはいつですか？

明らかなケースは、setSomeObject（SomeObject obj）メソッドを持つ既存のクラスの周りにファサードを構築し、objがnullになる場合です。 この場合、少なくともカバーする「ファサード」メソッドでは、nullオブジェクトを使用する可能性についてユーザーに明示的に通知されます。



残りのケースでは、渡されたパラメーターがnullでないという制限（および場合によっては検証）を使用して、通常のセッターメソッドを作成することをお勧めします。 設計段階で、この制限はassertで確認できます。 本番環境で確認するかどうか、もしそうなら、議論の範囲を超えた別の興味深い質問はどうでしょうか。



したがって、多くの著者に従って、セッターでのヌル転送を想定せず、許可しないことをお勧めします。



どのように、注意深い読者は叫ぶでしょう。 シリーズの2番目の記事では、著者自身がこのインターフェイスの使用を提案しました。

 public interface IBoilerInput2 { void setAvailability(@Nullable CupOfWater water, boolean powerAvailable); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nullの可能性があるwaterパラメーターを使用して、今では悪いと言いますか？ はい そうです。 主な側面に注意を集中するために、ケーススタディに参加しました。 しかし、他の開発者が使用できる実際のAPIを開発するときは、これを避ける必要があります。 しかし、どのように？



状況を詳しく見てみましょう。 パラメータ値としてnullを渡すと、通常、オブジェクトの構成を変更したり、機能の一部を無効にしたり、動作を新しいモードに切り替えたりすることを意味します。 このスイッチを説明する適切な用語を選択します。



上記のインターフェイスは、次のように変換されます。

 public interface IBoilerInputX { void setWater(@Nonnull CupOfWater water); void setWaterDisabled(); void setPowerAvailable( boolean powerAvailable); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいsetWaterDisabledメソッドは、デバイスの動作の今後の変更を明確に示します。これは、以前のバージョンのIBoilerInput2とは異なり、値がゼロのパラメーターを呼び出すことで達成されました。

パラメータグループでオプションを使用する

ただし、場合によっては、概念的または技術的な理由により、特定のパラメーターのグループをセッターとスイッチから個別のペアに分割することはできず、パラメーターのグループ全体を1回の呼び出しで渡す必要があります。 これはクラスコンストラクターで頻繁に発生します。 ただし、グループの一部のパラメーターは存在しない、準備ができていないなどです。 -つまり nullになります。 この場合、オプションのケースを使用することは、潜在的にヌルのパラメーターを直接渡すよりもはるかに優れています。 以前の計算で誤って麻痺していた一部のパラメーターがクラス内に収まり、NPEまたは不適切な動作を引き起こす可能性（この場合は大幅に減少）。

最終的な推奨事項

予備的な結果を実用的な推奨事項の形式で要約するには：

1. nullの可能性があるパラメーターを明示的に渡す必要があるメソッドのファサードを構築する場合は、セッターまたは1つのパラメーターを持つメソッド（のみ）でOptionalを使用します。
2. ほとんどの場合、パラメーターがnull値をとることができる場合、null以外の値と関連するオブジェクトの動作モードの切り替え方法を制限して、セッターに渡します。 スイッチ内で、対応するフィールドの値をリセットします。
3. メソッドに多くのパラメーターが必要な場合、その一部はゼロ値をとることができるため、そのようなパラメーターをOptionalケース内に渡します。 これにより、メソッドを呼び出すクライアントは、ケースにオブジェクトを「埋め込む」前に状況を明示的に処理します。

劣った戻り値

このシリーズの第1回と第2回の記事で、潜在的にゼロの戻り値をケースにパッケージ化する必要があることを読者に長い間確信させてきました。 いつも良いですか？ 残念ながら、光があるところには影があります。



特にエンタープライズシステムでの複雑なオブジェクトは、多くの場合、ゲッターメソッドを呼び出すことで外部からアクセスできる単純なオブジェクトの集合体または階層です。 オブジェクトが「空の」オブジェクトを返すという事実（それがケースに詰められているかどうか）は、多くの場合、そのようなオブジェクトが集合体または階層内に存在しないことを意味しません。 実際のシステムでは、これは多くの場合、オブジェクトが何らかの意味で「劣っている」こと、またはそれを含む集約オブジェクトの構成が外界での使用を許可しないことを意味します。 この観点から、Optional.empty（）を返すことは正当化されます。 ただし、外部フレームワークを使用して（Reflectionを使用したり、bycodeを操作したりせずに）オブジェクトを外部メディアに保存したり、ネットワーク経由で送信したりする場合、オブジェクトの「劣等性」またはそれを含むユニットの不適切な構成が障害になることはありません。 Optionalケースを返すゲッターは、この場合使用できないことがわかります。 どうして？ 何のために戦っていましたか？



実際、すべてが良くなりました。 はい、大きな集合体の一部を永続化するための特別なメソッドを実装する必要があります。 ただし、同時に1つの個別のインターフェイスで収集し、別のインターフェイスでビジネスロジックを実装する方法を収集することをお勧めします。 したがって、同じオブジェクトを使用するビジネス面と技術面を分離できます。

マジックナンバーの代わりにオプション

数字の世界におけるオブジェクトの世界からのヌルアナログは、「魔法の」数字です。 つまり 「通常の」数値よりも根本的に異なるセマンティクスが関連付けられるようなパラメーター値。



標準のJavaライブラリでさえこれを行います。 Java.net.Socketクラスコンストラクターのドキュメント：

 public Socket(String host, int port, InetAddress localAddr, int localPort) throws IOException
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

localPortパラメータについて、ゼロ以外に設定するとシステムが使用することを示しています。 パラメータ値が0の場合、空いているポートを探します。



パラメータ値がゼロでない場合とゼロの場合のメソッドの動作は根本的に異なります。



将来そのような状況を避けるために、Java 8ではOptionalIntクラスとOptionalDoubleクラスが導入されました。 メソッドが成功した場合に特定の数を返す必要がある場合にこれらのクラスを使用しますが、失敗することも可能です。

結論の代わりに、自分で考えてください！

Optionalクラスのメソッドを使用するためのオプションを説明するために5つの記事を捧げました。 Javaには、それほど多くの質問や論争を引き起こすクラスは多くないと思います。



ところで、親愛なる読者の皆さん、このクラスには何行のコード（コメントは含まれず、コメントも含まれません）がありますか？





このシリーズの記事のいくつかは、非常にシャープで興味深い議論を引き起こしました。 しかし、それは海洋の低下でさえありませんが、Java 8のOptionalの登場後に寄宿学校の英語部門で登場した議論や質問と比較して、低下分子です。Optionalに関する最もホットで最も興味深い議論の1つは、これです： ？



この議論には、Oracleの「Java Language Architect」の地位を占めるBrian Goetzも参加しました。 Javaプログラマーがどのように彼の頭脳を使っているかを見て、ここに彼がフォーラムで書いたものがあります（私の翻訳）：

もちろん、人々は自分が望むことをするでしょう。 ただし、この機能を追加する際には明確な意図があり、他の言語でMaybeやSomeなどのメカニズムを作成するという目標は設定していませんでした。 多くの人がこれを望んでいたかもしれませんが。 私たちの目標は、ほとんどの場合エラーを引き起こす可能性のあるゼロ値を使用する代わりに、「結果なし」状況を明確に強調して、戻り値のタイプを決定するコンパクトなメカニズムを提供することでした。



たとえば、おそらく結果の配列または結果のリストを返すものには使用しないでください。 代わりに、空の配列またはリストを返します。 何かのフィールドやメソッドのパラメーターとして使用することはほとんどありません。



getterの戻り値としての通常の使用は間違いなく過剰になると思います。



Optionalは避けるべき悪いことではありません。 これは、多くの人が代わりに見たいものではありません。 そして、私たちは使いすぎのリスクを非常に心配していました。



処理：（このコンテキストで）常にゼロでないことを証明できない限り、Optional.getを呼び出さないでください。 代わりに、orElseやifPresentなどの安全なメソッドのいずれかを使用してください。 振り返ってみると、getの代わりにgetOrElseThrowNoSuchElementExceptionのようなものを提供する必要があり、その使用がより明確になります。 しかし、これは学んだ教訓です。

言い換えれば、言語の作成者は、一部の（上級）ユーザーが望むように、言語を常に拡張するとは限りません。 ユーザーは、作成者が考案した言語の新しい機能を常に使用するとは限りません。 また、作成者は、修正できないエラーを後悔することがあります。



だから、親愛なる読者は、あなた自身のために考え、あなたのプロジェクトでオプションを使用する方法を自分で決めてください。 そして、この一連の記事と約束された贈り物-Optionalに関するポスターがこれに役立つことを願うばかりです。