public フィールドをBook含むクラスがあるとします。year_publishedNullObject デザイン パターンを実装する場合は、とNullBook同じように動作するBookが何もしないクラスを定義する必要があります。
NullBook質問は、フィールドが割り当てられているときの動作はどうあるべきですか?
Book book = find_book(id_value); //this method returns a NullBook instance because it cannot find the book
book.year_published = 2016; //What should we do here?!
つまり、パターンはバランスを取ることです。はい、null を返さないことは一般的に良い習慣ですが、他に返さなければなりません。しかしまあ: 返されたものは意味のあるものでなければなりません!
また、ある程度、「NullBook」を使用することが実際にアプリケーションの設計にどのように役立つかわかりません。特に、さまざまな内部フィールドへのアクセスを許可するためです。あなたは正確に正しい質問をしました: 出版された年、または著者、または...そのような「NullBook」は何ですか?! たとえば、コードの一部がさまざまな「ソース」からの本を「検索」するとどうなりますか。次に、それらの本を出版年で並べ替えようとします。NullBook をそのようなデータの一部にしたくないはずです。
したがって、逆に、このクラスを持つことの価値を理解できません。「興味深い」バグが発生する可能性があることがわかります。したがって、私の答えは次のとおりです。一歩下がって、そのクラスが本当に必要かどうかを再検討してください。
オブジェクトを null に置き換える代替手段があります。言語で Optionalsが許可されている可能性があります。または、null を返す可能性のあるメソッドを作り直して、本のコレクション/配列を返すようにします。そして疑わしい：そのリスト/配列は単に空です。
簡単に言えば、他のクラスにプライベート フィールドへの直接アクセスを許可することは、インポートデザインの臭いです。そのため、NullObjects に集中しすぎないようにする一方で、 Information Hidingなどの重要なことを簡単にあきらめてはなりません。