nullが悪である場合、値が有意に欠落する可能性がある場合は何を使用する必要がありますか？

これは、繰り返し繰り返されている規則の1つであり、私を困惑させます。

ヌルは悪であり、可能な限り避けるべきです。

しかし、しかし-私の素朴さから、私に悲鳴を上げさせてください-時には価値が意味なく欠けていることがあります！

私が今取り組んでいるこのアンチパターンに乗った恐ろしいコードから来る例でこれを聞かせてください。これは、中核となるマルチプレイヤーウェブターンベースのゲームであり、両方のプレイヤーのターンが同時に実行されます（ポケモンのように、チェスとは逆に）。

各ターンの後に、サーバーは更新のリストをクライアント側のJSコードにブロードキャストします。更新クラス：

public class GameUpdate
{
    public Player player;
    // other stuff
}

このクラスはJSONにシリアル化され、接続されているプレーヤーに送信されます。

ほとんどのアップデートには当然プレイヤーが関連付けられています-結局のところ、どのプレイヤーがこのターンにどのプレイヤーを動かしたかを知る必要があります。ただし、一部の更新プログラムでは、意味のあるPlayerを関連付けることができません。例：アクションなしのターン制限を超えたため、ゲームは強制的に結び付けられました。このような更新では、プレーヤーを無効にすることは有意義だと思います。

もちろん、継承を利用することでこのコードを「修正」できます。

public class GameUpdate
{
    // stuff
}

public class GamePlayerUpdate : GameUpdate
{
    public Player player;
    // other stuff
}

ただし、次の2つの理由から、これがどのように改善されるかはわかりません。

• JSコードは、定義されたプロパティとしてPlayerのないオブジェクトを受け取るだけです。これは、値が存在するかどうかを確認する必要があるため、nullの場合と同じです。
• 別のnull可能フィールドをGameUpdateクラスに追加する場合、この設計を続行するには多重継承を使用できる必要がありますが、MIはそれ自体が悪であり（経験豊富なプログラマーによると）、さらに重要なことには、C＃はそうではありません持っているので使用できません。

このコードのこの部分は、経験豊富で優秀なプログラマーが恐怖で叫ぶことになる非常に多くのコードの1つであるという感想があります。同時に、この場所でこのヌルがどのように何かを傷つけているか、代わりに何をすべきかを見ることができません。

この問題について説明してもらえますか？

多くのものは、nullよりも返した方が良いです。

• 空の文字列（ ""）
• 空のコレクション
• 「オプション」または「多分」モナド
• 静かに何もしない機能
• 静かに何もしないメソッドでいっぱいのオブジェクト
• 誤った質問の前提を拒否する意味のある値_{（そもそもnullとみなした}理由
  _です）

秘whenは、これをいつ行うかを実現することです。Nullは顔を爆破するのに非常に優れていますが、それを確認せずにドットを消した場合のみです。理由を説明するのは得意ではありません。

爆破する必要がなく、nullをチェックしたくない場合は、これらの選択肢のいずれかを使用してください。コレクションに0個または1個の要素しか含まれていない場合、コレクションを返すのは奇妙に思えるかもしれませんが、欠損値を静かに処理できる点で優れています。

モナドは派手に聞こえますが、ここで行っているのは、コレクションの有効なサイズが0と1であることを明確にすることです。

これらのいずれも、nullよりも意図を明確にするのに適しています。それが最も重要な違いです。

単に例外をスローするのではなく、なぜ戻ってくるのかを理解することが役立つ場合があります。例外は、本質的に仮定を拒否する方法です（唯一の方法ではありません）。2本の線が交差する点を求めるとき、それらは交差すると仮定します。それらは平行かもしれません。「平行線」例外をスローする必要がありますか？さてあなたはできましたが、今ではその例外を他の場所で処理するか、システムを停止させなければなりません。

自分がいる場所に留まる場合は、その仮定の拒否を、結果または拒否のいずれかを表すことができる一種の値に焼き付けることができます。そんなに変ではありません。私たちは常に代数でそれを行います。トリックは、その値を意味のあるものにして、何が起こったのかを理解できるようにすることです。

返された値が結果と拒否を表すことができる場合、両方を処理できるコードに送信する必要があります。多態性は、ここで使用するのに本当に強力です。nullチェックを単純にチェックと交換するのisPresent()ではなく、どちらの場合でも適切に動作するコードを作成できます。空の値をデフォルト値に置き換えるか、何もせずに実行します。

nullの問題は、意味が多すぎることです。そのため、情報が破壊されるだけです。

私のお気に入りのヌル思考実験では、コンベヤーベルトから色付きの電球を取り出し、ソケットにねじ込んで電源を入れることにより、色付きの光を使用してエンコードされたメッセージを送信する複雑なRube Goldbergianマシンを想像してください。信号は、コンベアベルトに配置された電球のさまざまな色によって制御されます。

あなたは、この恐ろしく高価なものをRFC3.14159に準拠させるように頼まれました。RFC3.14159は、メッセージ間にマーカーがあるべきだと述べています。マーカーはまったく点灯しないようにします。正確に1パルス続く必要があります。単一の色の光が通常輝くのと同じ時間。

メッセージの間にスペースを空けることはできません。これは、ソケットに入れる電球が見つからない場合に、仕掛けがアラームをオフにして停止するためです。

このプロジェクトに精通している人は誰でも、機械や制御コードに触れることに震えています。変更するのは簡単ではありません。職業はなんですか？さて、あなたは飛び込み、物を壊し始めることができます。この恐ろしいデザインを更新するかもしれません。うん、もっと良くすることができます。または、管理人と話をして、燃え尽きた電球を集め始めることもできます。

それがポリモーフィックソリューションです。システムは、変更されたことを知る必要さえありません。

あなたがそれをやってのけることができれば、それは本当に素晴らしいです。仮定の意味のある拒否を値にエンコードすることにより、質問を強制的に変更する必要がなくなります。

リンゴを1個あげたら、何個のリンゴを借りますか？-1。昨日からリンゴを2個借りたからです。ここで、「あなたは私に借りる」という質問の仮定は、負の数で拒否されます。質問が間違っていたとしても、この回答には意味のある情報がエンコードされています。意味のある方法でそれを拒否することにより、質問は変更を余儀なくされません。

ただし、質問を実際に変更することが実際の方法です。仮定をより信頼性の高いものにすることができ、それでも有用な場合は、それを行うことを検討してください。

あなたの問題は、通常、アップデートがプレイヤーから来るということです。しかし、プレーヤー1またはプレーヤー2からのものではない更新の必要性を発見しました。時間が経過したことを示す更新が必要です。どちらのプレイヤーもこれを言っていないので、あなたは何をすべきですか？プレーヤーをヌルのままにしておくのは魅力的です。しかし、それは情報を破壊します。ブラックホールの知識をエンコードしようとしています。

プレーヤーフィールドには、誰が移動したかがわかりません。そうだと思うが、この問題はそれが嘘であることを証明している。プレーヤーフィールドには、更新元が表示されます。時間切れの更新はゲームの時計から来ています。私の推薦は、時計に値するクレジットを与えて、player分野の名前をのようなものに変えることですsource。

これにより、サーバーがシャットダウンしてゲームを中断する必要がある場合、何が起きているかを報告し、更新元として自分自身をリストする更新を送信できます。

これは、単に何かを除外するべきではないということですか？いいえ。ただし、よく知られた1つの適切なデフォルト値を実際に意味するものと見なすことができるものがどれほどないかを考慮する必要があります。使いすぎるのは本当に簡単なことではありません。したがって、使用するときは注意してください。何も好まないことを受け入れる思考の学校があります。それは、設定より規約と呼ばれます。

私自身はそれが好きですが、コンベンションが何らかの形で明確に伝えられているときだけです。それは初心者を曇らせる方法であってはなりません。ただし、それを使用している場合でも、nullを使用するのが最善の方法ではありません。Nullは危険なものではありません。Nullは、使用するまで使用できるもののふりをして、宇宙に穴を開けます（セマンティックモデルを破壊します）。宇宙に穴を開けるのがあなたが必要とする振る舞いでない限り、なぜあなたはこれをいじっているのですか？他のものを使用してください。

nullここでは本当に問題ではありません。問題は、現在のほとんどのプログラミング言語が欠落情報をどのように処理するかです。彼らはこの問題を真剣に受け止めていません（あるいは少なくとも、ほとんどの地球人が落とし穴を避けるために必要なサポートと安全を提供してはいけません）。これは、私たちが恐れることを学んだすべての問題（Javas NullPointerException、Segfaults、...）につながります。

より適切な方法でその問題に対処する方法を見てみましょう。

他の人はNull-Object Patternを提案しました。私はそれが時々適用可能であると思いますが、万能なデフォルト値がないだけのシナリオがたくさんあります。これらの場合、存在しない可能性のある情報の消費者は、その情報が欠落している場合の対処方法を自分で決定できる必要があります。

コンパイル時にnullポインターに対する安全性（いわゆるvoid安全性）を提供するプログラミング言語があります。いくつかの現代的な例を挙げると：Kotlin、Rust、Swift。これらの言語では、情報の欠落の問題が深刻に受け止められており、nullを使用してもまったく問題はありません。コンパイラはnullポインターの逆参照を防ぎます。
Javaでは、同じ効果を得るために、コンパイラ+ IDEプラグインとともに@ Nullable / @ NotNullアノテーションを確立する努力がなされています。それは実際には成功しませんでしたが、この答えの範囲外です。

不在の可能性を示す明示的で一般的なタイプは、それに対処する別の方法です。たとえば、Javaにはがありjava.util.Optionalます。機能します：
プロジェクトまたは会社レベルで、ルール/ガイドラインを確立できます

• 高品質のサードパーティライブラリのみを使用する
• java.util.Optional代わりに常に使用するnull

あなたの言語コミュニティ/エコシステムは、コンパイラ/インタプリタよりもこの問題をうまく解決する他の方法を考え出したかもしれません。

私は、nullが悪いという声明には何のメリットもありません。私はそれについての議論をチェックしましたが、彼らは私をイライラさせ、イライラさせました。

Nullは、実際には何かを意味する場合、「魔法の価値」として間違って使用される可能性があります。しかし、そこにたどり着くにはかなりひねったプログラミングを行う必要があります。

ヌルは、「存在しない」ことを意味する必要があります。これは、（まだ）作成されていないか、（すでに）存在しないか、引数の場合は提供されません。状態ではなく、すべてが欠落しています。オブジェクトが常に作成および破棄されるOO設定では、それはどの状態とも異なる有効で意味のある条件です。

nullを使用すると、実行時にスマッキングされますが、コンパイル時に何らかのタイプセーフなnullの代替手段が使用されます。

完全に真実ではありませんが、変数を使用する前にnullをチェックしないという警告を受け取ることができます。そして、それは同じではありません。目的のないオブジェクトのリソースを節約したくない場合があります。さらに重要なことは、希望する動作を得るために、まったく同じ選択肢をチェックする必要があることです。それを忘れると、未定義/意図しない動作よりも、実行時にNullReferenceExceptionが発生します。

留意すべき問題が1つあります。マルチスレッドコンテキストでは、nullのチェックを実行する前にまずローカル変数に割り当てることにより、競合状態から保護する必要があります。

nullの問題は、それが多くのことを意味する場合があることです。そのため、情報が破壊されるだけです。

いいえ、それは何も意味しないので、破壊するものは何もありません。変数/引数の名前と型は、何が欠けているかを常に伝えます。それがすべてです。

編集：

関数型プログラミングに関する彼の他の回答の1つでリンクされているビデオ candied_orangeの途中で、非常に興味深いものです。特定のシナリオでその有用性を確認できます。これまでに見てきた機能的なアプローチは、コードの断片が飛び回っているので、通常、OO設定で使用されると気が散ります。しかし、その場所があると思います。どこかに。そして、C＃で遭遇するたびに混乱を招く混乱を隠してくれる、良い仕事をする言語、つまり、クリーンで実行可能なモデルを提供する言語があると思います。

その機能モデルがあなたのマインドセット/フレームワークである場合、文書化されたエラーの説明として事故を押し進め、最終的に発信者に開始点までドラッグされた蓄積されたガベージを処理させる方法はありません。どうやらこれは関数型プログラミングの仕組みです。それを制限と呼び、新しいパラダイムと呼びます。あなたはそれを機能的な弟子のためのハックであるとみなすかもしれません。それは彼らが不浄な道をもう少し続けることを可能にします。いずれにせよ、その世界に足を踏み入れ、物事を行う従来のオブジェクト指向の方法に戻って（そう、例外を投げることができます、ごめんなさい）、そこからいくつかの概念を選び、

どのような概念も間違った方法で使用できます。私の立場からすると、提示された「解決策」は、nullを適切に使用するための代替手段ではありません。それらは別の世界からの概念です。

あなたの質問。

しかし、しかし-私の素朴さから、私に悲鳴を上げさせてください-時には価値が意味なく欠けていることがあります！

そこに完全に搭乗します。ただし、すぐに説明するいくつかの注意事項があります。でもまず：

ヌルは悪であり、可能な限り避けるべきです。

これは意図的だが一般化された声明だと思う。

ヌルは悪ではありません。それらはアンチパターンではありません。それらは、どんな犠牲を払っても避けるべきものではありません。ただし、nullはエラーになりやすい（nullのチェックに失敗するため）。

しかし、nullのチェックに失敗することは、nullが本質的に使用するのが間違っているという証拠です。

nullが悪なら、配列インデックスとC ++ポインターも同様です。そうではありません。彼らは自分の足で自分を撃つのは簡単ですが、決して避けられないはずです。

この回答の残りの部分では、「nullは悪」という意図をより微妙な「nullは責任を持って処理する必要があります」に適合させます。

あなたのソリューション。

nullをグローバルルールとして使用するというあなたの意見に同意しますが、この特定のケースでnullを使用することに同意しません。

以下のフィードバックを要約すると、継承とポリモーフィズムの目的を誤解していることになります。nullを使用するという議論には妥当性がありますが、他の方法が悪い理由のさらなる「証拠」は継承の誤用に基づいており、null問題とは無関係な点を示しています。

ほとんどのアップデートには当然プレイヤーが関連付けられています-結局のところ、どのプレイヤーがこのターンにどのプレイヤーを動かしたかを知る必要があります。ただし、一部の更新プログラムでは、意味のあるPlayerを関連付けることができません。

これらの更新が有意に異なる場合（異なる場合）、2つの個別の更新タイプが必要です。

たとえば、メッセージを検討してください。エラーメッセージとIMチャットメッセージがあります。ただし、非常によく似たデータ（文字列メッセージと送信者）が含まれている場合がありますが、同じようには動作しません。異なるクラスとして、別々に使用する必要があります。

あなたが今していることは、Playerプロパティのnull-nessに基づいて、2種類の更新を効果的に区別することです。これは、エラーコードの存在に基づいてIMメッセージとエラーメッセージを決定することと同じです。動作しますが、最良のアプローチではありません。

• JSコードは、定義されたプロパティとしてPlayerのないオブジェクトを受け取るだけです。これは、値が存在するかどうかを確認する必要があるため、nullの場合と同じです。

あなたの議論は、多型のミスに依存しています。あなたは返すメソッドがある場合はGameUpdate、オブジェクトを、それは一般的に、これまでの間で区別する気にはならないGameUpdate、PlayerGameUpdateまたはNewlyDevelopedGameUpdate。

基本クラスには完全に機能するコントラクトが必要です。つまり、そのプロパティは派生クラスではなく基本クラスで定義されます（つまり、これらの基本プロパティの値はもちろん派生クラスでオーバーライドできます）。

これにより、議論が議論の余地がなくなります。良い習慣では、GameUpdateオブジェクトにプレイヤーがいるかどうかは気にしないでください。aのPlayerプロパティにアクセスしようとしGameUpdateている場合は、何か非論理的なことをしています。

C＃などの型付き言語では、単にプロパティがないため、a のプロパティにアクセスしてアクセスすることさえできません。Javascriptはアプローチがかなり緩い（そしてプリコンパイルを必要としない）ので、あなたを修正することを気にせず、代わりに実行時に爆発する。PlayerGameUpdateGameUpdate

• 別のnull可能フィールドをGameUpdateクラスに追加する場合、この設計を続行するには多重継承を使用できる必要がありますが、MIはそれ自体が悪であり（経験豊富なプログラマーによると）、さらに重要なことには、C＃はそうではありません持っているので使用できません。

nullableプロパティの追加に基づいてクラスを作成するべきではありません。機能的にユニークなタイプのゲーム更新に基づいてクラスを作成する必要があります。

一般にnullの問題を回避するにはどうすればよいですか？

価値の欠如を有意義に表現する方法について詳しく説明することは重要だと思います。これは、特定の順序でのソリューション（または不適切なアプローチ）のコレクションです。

1.とにかくnullを使用します。

これが最も簡単なアプローチです。ただし、大量のnullチェックにサインアップし、（失敗すると）null参照例外のトラブルシューティングを行います。

2. null以外の無意味な値を使用する

以下に簡単な例を示しますindexOf()。

"abcde".indexOf("b"); // 1
"abcde".indexOf("f"); // -1

代わりにnull、あなたは得る-1。技術レベルでは、これは有効な整数値です。ただし、インデックスは正の整数であると予想されるため、負の値は無意味な答えです。

論理的には、これは、戻り値の型が意味のある戻り値よりも多くの可能な値を許可する場合にのみ使用できます（indexOf =正の整数; int =負および正の整数）

参照タイプの場合でも、この原則を適用できます。たとえば、整数IDを持つエンティティがある場合、nullではなく-1に設定されたIDを持つダミーオブジェクトを返すことができます。
オブジェクトが実際に使用可能かどうかを測定できる「ダミー状態」を定義する必要があります。

文字列値を制御しない場合は、事前に決められた文字列値に依存しないことに注意してください。空のオブジェクトを返したい場合は、ユーザーの名前を「null」に設定することを検討できますが、Christopher Nullがサービスにサインアップすると問題が発生します。

3.代わりに例外をスローします。

いいえ、ただ。論理フローでは例外を処理しないでください。

そうは言っても、（nullreference）例外を非表示にするのではなく、適切な例外を表示したい場合があります。例えば：

var existingPerson = personRepository.GetById(123);

これはPersonNotFoundException、ID 123の人がいないときに（または同様の）をスローする可能性があります。

やや明らかに、これは、アイテムが見つからないためにそれ以上の処理ができない場合にのみ許容されます。アイテムが見つからない可能性があり、アプリケーションを続行できる場合は、例外をスローしないでください。これを十分に強調することはできません。

ヌルが悪い理由のポイントは、欠損値がヌルとしてエンコードされることではなく、参照値がヌルになる可能性があることです。C＃をお持ちの場合は、とにかく失われる可能性があります。参照タイプはすでにオプションであるため、ポイントROがオプションを使用することはありません。しかし、Javaには@Notnullアノテーションがあり、これはパッケージレベルで設定できるように思われますが、見落とされる可能性のある値には@Nullableアノテーションを使用できます。

ヌルは悪ではありません。ヌルのように見えるものを何らかの時点で処理せずに、現実的に代替を実装する方法はありません。

ただし、ヌルは危険です。他の低レベルの構成要素と同じように、間違えた場合は、以下に示すものはありません。

nullに対する有効な引数はたくさんあると思います。

• すでに高レベルドメインにいる場合、低レベルモデルを使用するよりも安全なパターンがあります。

• 低レベルのシステムの利点が必要で、適切に注意する準備ができていない限り、低レベルの言語を使うべきではないでしょう。

• など ...

これらはすべて有効であり、さらにゲッターやセッターなどを書く努力をする必要がないことは、そのアドバイスに従わない一般的な理由と見なされます。多くのプログラマーがヌルは危険で怠zyであるという結論に達したのは驚くべきことではありません（悪い組み合わせです！）。

言語を書いた善良な人々は、彼らが誰かに役立つと思った。異議を理解し、それでも自分にふさわしいと思うのであれば、他の誰もそれ以上は知りません。

Javaには OptionalifPresent任意の値に安全にアクセスするための明示的な+ラムダを持つクラスがあります。これもJSで行うことができます：

見る このStackOverflowの質問を。

ちなみに、多くの純粋主義者はこの使用法を疑っていますが、私はそうは思いません。オプション機能が存在します。

CARホアはヌルを「10億ドルの間違い」と呼んだ。ただし、ソリューションは「どこにもnullがない」のではなく、「デフォルトとしてnull不可のポインタであり、意味的に必要な場合にのみnullになる」と考えたことに注意することが重要です。

彼の間違いを繰り返す言語におけるヌルの問題は、関数がヌル不可データを期待しているとは言えないことです。言語では基本的に表現できない。これにより、関数に無用な無関係なヌル処理ボイラープレートが多数含まれることになり、ヌルチェックを忘れるとバグがよく発生します。

表現力の根本的な欠如を回避するために、一部のコミュニティ（たとえばScalaコミュニティ）はnullを使用しません。Scalaでは、typeのnull値を許可する値が必要な場合は、type Tの引数を使用します。null値をOption[T]許可しない値が必要な場合は、を使用しTます。誰かがあなたのコードにヌルを渡すと、あなたのコードは爆発します。ただし、呼び出し元のコードはバグのあるコードであると見なされます。 Option一般的なヌルハンドリングパターンのようなライブラリ関数の中に抽出されているので、しかし、ヌルのためにかなりいいの交換です.map(f)か.getOrElse(someDefault)。