1

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?!
4

2 に答える 2

1

つまり、パターンはバランスを取ることです。はい、null を返さないことは一般的に良い習慣ですが、他に返さなければなりません。しかしまあ: 返されたものは意味のあるものでなければなりません!

また、ある程度、「NullBook」を使用することが実際にアプリケーションの設計にどのように役立つかわかりません。特に、さまざまな内部フィールドへのアクセスを許可するためです。あなたは正確に正しい質問をしました: 出版された年、または著者、または...そのような「NullBook」は何ですか?! たとえば、コードの一部がさまざまな「ソース」からの本を「検索」するとどうなりますか。次に、それらの本を出版年で並べ替えようとします。NullBook をそのようなデータの一部にしたくないはずです。

したがって、逆に、このクラスを持つことの価値を理解できません。「興味深い」バグが発生する可能性があることがわかります。したがって、私の答えは次のとおりです。一歩下がって、そのクラスが本当に必要かどうかを再検討してください。

オブジェクトを null に置き換える代替手段があります。言語で Optionalsが許可されている可能性があります。または、null を返す可能性のあるメソッドを作り直して、本のコレクション/配列を返すようにします。そして疑わしい:そのリスト/配列は単に空です。

簡単に言えば、他のクラスにプライベート フィールドへの直接アクセスを許可することは、インポートデザインの臭いです。そのため、NullObjects に集中しすぎないようにする一方で、 Information Hidingなどの重要なことを簡単にあきらめてはなりません。

于 2016-09-13T04:02:03.397 に答える