問題タブ [null-object-pattern]

(C++/Qt) QObject へのスマート ポインターがあります。QWeakPointer としましょう。なんらかの外部的な理由 (別のオブジェクトで発生する可能性があるもの、またはイベントが原因で発生する可能性があるもの) により、指定されたオブジェクトが破棄される可能性があります。私はスマート ポインターを持っているので、ダングリング リファレンスはないので問題ありません。しかし、ポインターが null かどうかを常に確認する必要があります。

これを常にチェックしないようにするためにヌルパターンを使用することを考えていますが、QObjectでこれが可能かどうか、または便利かどうかはわかりません。ポインタがオブジェクトを指し、それが破壊された場合、スマートポインタはその指し示したオブジェクトをnullオブジェクトに変更するという考え方です。これは良い考えですか、それとも忘れて、ポインターが常に NULL かどうかを確認する必要がありますか?

例を示しましょう。ツールを使用して作業を行うワーカーがいます。

この場合、ツールはライブラリのパブリック ドメイン オブジェクトであり、ワーカーによって使用されます。私はそのようなライブラリを開発しています。そのため、作業員はドライバーを使用していますが、壊れて破損します。問題ない：

m_tool は 0 なので、単に何もしません。ただし、毎回 null ではないことを確認する必要があります。

NullTool オブジェクトがあるとします。

ツールが破棄されると、ポインターはスマートになり、NullTool インスタンスを指す必要があることを認識します。したがって、Worker::work() は次のように実装できます。

m_tool->use() は何もしない NullTool で呼び出されるため、ポインタが null でないことを確認する必要はありません。

これは良い考えですか？Qtが提供するスマートポインタクラスで可能ですか、それともQWeakPointerをサブクラス化する必要がありますか?

最近、Null Object デザイン パターンに出会いました。同僚は、コード全体で発生する null ポインター チェックをなくすために使用できると言っています。

たとえば、DAO クラスが Customer に関する情報を (CustomerVO という値オブジェクトで) 返すとします。私のメイン クラスは、firstName と emailId を抽出し、顧客に電子メールを送信することになっています。

これは非常に単純な例ですが、このような null チェックは、値オブジェクトの複雑さに基づいてコード全体に急速に広がる可能性があります。

null チェックには 2 つの問題があります。コードが醜く読みにくくなる傾向があります。経験の浅い開発者は、実際には例外をスローするはずなのに、不必要な null チェックを行います。たとえば、上記のコードでは、getCustomer() 自体から例外をスローする方が適切です。これは、指定された CustID の顧客情報が見つからない場合、CustID が無効であることを示しているためです。

さて、null オブジェクト パターンに戻りますが、「null」CustomerVO オブジェクトを使用して null チェックを非表示にすることはできますか?

それは理にかなっていますか？どう思いますか？

また、アプリでの null チェックを最小限に抑えるために従うことは何ですか。

slf4j からダミーのロガーを取得できますか? (null オブジェクトの設計パターンを考えてみてください。) もしそうなら、誰かが例を提供できますか? または、それを行いたい場合、カスタムロガーを実装する必要がありますか?

私は次の行に沿って関数を書きたいと思っています

NullPointerExceptionロガーが設定されていない場合、その最後の行でa を取得しません。

私はあなたのフィードバックを聞くことに興味があります。最近、次の方法で実装されたJavaコードをいくつか見ました。

コンテキストなしでnullが返されるときはいつでも、私は常に心配しています。むしろ、SomeMethodからの応答をより明確にし、リファクタリングを検討していました。SomeMethodから例外をスローすると、これを行う方法が提供される可能性があります。それは状況に応じて発生し、障害が発生した時点で発生します。

nullが常に「見つからない」と等しいと仮定する代わりに、SomeMethodがAnotherMethodに「データベースに何も見つかりませんでした」と通知できる別の方法があるかどうか疑問に思っています。NullObjectを使用できると思いましたが、データが見つからなかった場合に、AnotherMethodが「作業を継続する」ことを回避する方法がわかりません。

コードをどのようにリファクタリングしますか？

編集 | または、同じオブジェクトの件名に関する別の質問。次のすべてを機能させる独自のクラス定義を作成できますか?

nil?それは単なる方法なので、簡単にできます。しかし、ブール式（最も基本的な式「o」のみを含む）で真ではない値として評価する方法がわかりません。

元の質問は次のとおりです...

Ruby (1.9.2) でどれだけ楽しめるかという好奇心から...

ユーザーがログインしていないときは、with unless @useror until@user.nil?などで検出できるようにしたいのですが、同時に、このオブジェクトのメソッドを呼び出してUser同じものを返してもらいたいです(ala Objective-C)。ほとんどの場合、これによりボイラープレートコードNilClassが不要になるため、ブール式のように動作します。if @usernil

NilClassメソッドがないため、サブクラス化できないことがわかりました#new。メソッドをインスタンスに直接追加できますが、これはシングルトンであるため、この動作を確認したい場所がログインしていないユーザーだけである場合、問題が発生します。

出来ますか？

つまり、次のようなものです。

これは基本的に Objective-C が nil を処理する方法であり、状況によっては便利です。

NilClass をサブクラス化できず、ブール式で false になるメソッドを実装できなかったと思いますか?

編集 | ははは、トップレベルを再定義すると、本当にRubyがかなり壊れてしまいますNilClass...メソッド呼び出しにまったく応答しなくなります。

この複合ツリーでは、柔軟なツリートラバーサルのために親ノードへの参照を保持しています。親のnull参照を常にチェックする必要はありませんが、NullNodeクラスを作成し、各ノードの親をこれに初期化すると、NullNodeにはNullNodeがあり、NullNodeには。があるため、スタックオーバーフローが発生します。 .. ad infinitum NullNodeの親をnullに設定しようとしましたが、それでも、目的を無効にしているように見える親に対してnull参照チェックを実行する必要があります。誰かがこれに遭遇しますか？何かできるとしたら？

ありがとう！

特定のインスタンスに対して、StructureMap が「なし」という特殊なケースを返すようにしたいと考えています。

MyUserHttpContext としてスコープされているこのクラスがあるとします。ネストされた、ドライブされたクラスNone（つまりMyUser.None、型MyUserがない場合に返される）が必要ですHttpContext（たとえば、ブートストラップApplication_Start()など）。

これは、特定の呼び出しが null (より読みやすい) の代わりに Special Case 型をチェックできることを意味します。

これを実現するには、どの SM 設定が必要ですか? 私はその方法を試しましたが、ConditionallyUseあまり成功しませんでした。NullReferenceExceptionSSM自体からどんどん投げてきます。

null オブジェクト パターンを使用するように、null のチェックがあちこちにある大きなクラスをリファクタリングしています。これまでのところ、ほぼスムーズに変更されていますが、最終結果にいくつか問題があります。より良い、または別のアプローチがあるかどうか、または以前の方法に戻るかどうかを知りたい.

最大の問題は、次のコードがあることです。

ご覧のとおり、おそらくこの条件から null チェックを削除できますが、デフォルト値に設定するとコードを実行するブール値のプロパティがあります。常に true を返すと、見つけて排除するのが困難な微妙なバグが発生する可能性があります。

もう 1 つの問題は、次のようにチェックを null から変更しなければならなかったことです。

nullをチェックするだけでなく、型をチェックする必要があるため、これは単純に醜いです。オブジェクトのプロパティの 1 つを返したり、そのメソッドの 1 つを実行したりしていないため、このような状況がクラスで 3 回発生します。このチェックを行う必要があります。

そして最後に、オブジェクトには null 許容ではない DateTime プロパティがいくつかあり、設計者はそれらを null 許容にすることを望んでいません。ここでも、MinDate 値をデフォルトとして使用すると、厄介なバグがコードに侵入する可能性があります。

それで、あなたはそれを持っています。これは、スパゲッティ ヌル チェックがあちこちに散らばっているよりも、ヌル オブジェクト パターンの方が悪いだけの場合ですか? これを達成するためのより良い方法はありますか？

回答ありがとうございます。

私たちのプロジェクトでは、いくつかのオブジェクト (User など) を格納する必要があり、User クラスにも検証フラグ (setOutdated や isOutdated などのメソッド) が必要です。

ときどき、User オブジェクトが null になることがありますが、この場合、検証フラグに到達できる必要があります。これらのメソッドを User クラスから抽出することは可能ですが、セマンティクスのために、そのフィールドとメソッドはそのクラス内にある必要があります。

Null オブジェクト パターン (このような)に関する記事をいくつか見つけました。 null ではない 時代遅れではありません。

PS: クラスに「古い」フィールドを導入すると、オブジェクトを null に設定するのではなく、オブジェクトをクリアするのが非常に難しくなります。

ビューをよりシンプルにするために、NHibernate を NullObject パターンと共に使用しています。ここでJames Gregoryが見つけた解決策を使用します

Person には Address プロパティなどがあります。

住所のない人の Person オブジェクトを保存しようとするまで、これは非常にうまく機能しています。NullPerson オブジェクトの新しいインスタンスを作成したので、NHibernate はそれを保存しようとします。そして私にこれを与えます：

NHibernate に NullObject を保存させないようにする方法はありますか? または、これを攻撃する他の方法はありますか？