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