Faceted Builder
Dmitri Nesterukからの無料ビデオチュートリアル
Software/Hardware Engineering • Quant Finance • Algotrading
22のコース
340,439人の受講生
レクチャーの説明
We look at a more complicated builder facade that exposes several sub-builders (builder facets) for building up parts of an object in a fluent manner.
コース全体からもっと学ぶ
Design Patterns in C# and .NET
Discover the modern implementation of design patterns with C# and .NET
20:40:51のオンデマンドビデオ • 更新日: 8月 2025
Recognize and apply design patterns
Refactor existing designs to use design patterns
Reason about applicability and usability of design patterns
日本語 [自動]
これまでの例では、 特定のオブジェクトを構築するためにひとつのビルダーだけを使用してきた。 そして、 このビルダーを実装し、 さらに流暢にする方法を検討した。 しかし、 ビルダー1社では十分でないこともある。 そして、 特定のオブジェクトのさまざまな側面を構築する役割を担う複数のビルダーと、 ある種のファサードが必要だ。 ファサードはもうひとつのデザイン・パターンで、 後ほど紹介する予定だが、 今回のデモではそれに遭遇することになる。 では、 なぜ今これが必要なのかを説明しよう。 ちょっと合成的な例を使うつもりだが、 この例は理解するのに十分簡単だ。 例えば、 ある人が2つの異なる情報を持っているとしよう。 住所に関する情報もあるので、 もう一度、 公開フィールドをいくつか作ろうかな。 そこで、 番地を公開し、 郵便番号と都市名を追加する。 これが住所に関する情報だ。 また、 アドレスを流暢に構築するためにビルダーを雇うのもいいだろう。 そしてもちろん、 雇用情報もある。 そこで、 publicな文字列の会社名と役職を用意し、 たとえばpublicなint型の年収というフィールドをもうひとつ追加する。 だから、 これはその人に関するかなり多くの情報であり、 まず第一に、 私たちはこの情報を出力したいと思うかもしれない。 だから、 フォーマット・メンバーを追加する。 そこで、 大きな2つの文字列を実装して、 人物が実際にどのように初期化されるかを確認できるようにした。 今、 私が欲しいのは、 実際に人物を構築するビルダーのようなものだ。 しかし、 実際には、 複数のビルダーがそのプロセスを担当して欲しい。 そのためにビルダー・ファセット、 つまり住所用のファセットと雇用用のファセットの2つのビルダー・ファセットを用意する。 では、 その実装方法を見てみよう。 さて、 これから始めるのは、 人物ビルダーによる普通のアプローチのように見えるかもしれないが、 人物ビルダーは本当の意味でのビルダーではない。 ファサードだ。 歌姫がここにいなければならないが、 気にしないでくれ。 つまり、 パーソン・ビルダーは他のビルダーのためのファサードであり、 実際にはそれ自体で人物を構築することはないが、 構築される人物への参照を保持する。 それも一つだ。 そしてもうひとつは、 サブ・ビルダーにアクセスできることだ。 こんな感じだ。 私たちには保護されている人がいる。 人は新しい人に等しい。 これはあくまで参考資料であることを強調しておく。 これは参照オブジェクトだ。 これは非常に重要なことで、 もしあなたが構造体を作り上げるのであれば、 このアプローチでは多くの問題を軽減することができるからだ。 ただ、 それを知ってもらうために出しただけだ。 つまり、 構築中のオブジェクトへのリファレンスがあるわけだ。 この場合は人であり、 ここで初期化される。 さて、 それに加えて、 他のビルダーを公開するのだが、 どんなビルダーがあるかというと、 まだ何もない。 だから、 ジョブビルダーを作ろうと思う。 そのため、 人物ジョブビルダーは、 人物オブジェクトのジョブ情報を構築するために設計されている。 しかし、 単にスタンドアローンであるだけでなく、 パーソン・ビルダーを継承している。 さて、 これは本当に奇妙なことだ。 なぜ我々はそれを受け継ぐのか? その理由はすぐにわかるだろう。 しばらくすればすべてが明らかになる。 しかし今は、 このオブジェクトに集中しよう。 だから、 コンストラクターの引数として、 実際に構築する人物への参照を取る必要がある。 だから、 ここで参考にさせてもらうよ。 実際に、 generateメニューに入り、 コンストラクタを作ってみよう。 ここでは、 人personを受け取り、 このperson equals personのように代入する。 ここまでは順調だ。 そして今、 私は流暢なAPIを構築することができる。 だから、 その人がある特定の場所で働いていると言いたい場合は、 一般人、 ジョブビルダーと言う。 ここに会社名を引数として入れて、 あとはperson dot, company name equals company nameと言ってこれを返す。 それから、 ポジションについても同じことが言える。 つまり、 その人はこの会社でストリング・ポジションとして働いているわけだ。 だから、 ここにストリングの位置を入れておこう。 そこでもう一度、 単純にフィールドを代入して、 これを返す。 つまり、 人物のドットの位置はポジションに等しく、 そしてこれを返す。 そして最後に年収だ。 だから、 intの金額を稼ぐ公共の人の仕事ビルダー、 そして私達はちょうど人ドット年収が金額に等しいと言い、 これをもう一度返します。 さて、 なぜこんなことをするのか? 何が言いたいんだ? まあ、 要はこのAPIを使い始められるということだ。 私たちは今、 人物ビルダーを作ることができる。 だから、 私はvar PBイコール新人ビルダーと言うつもりだ。 そしてもちろん、 人を育てようとすることもできる。 そこで、 var person equalsとし、 person builderとし、 次の行に進み、 ここに点を入れることにする。 今のところ、 不思議なことに、 あまり収穫はない。 パーソン・ビルダーにはAPIすらないようだ。 だからAPIを作ろう。 ここで、 人物ビルダーから人物ジョブビルダーを公開したい。 これは実に簡単だ。 というのも、 新しいインスタンスを、 作り上げた引数で返せばいいだけだからだ。 こんな感じだ。 一般人、 ジョブ・ビルダーは働く。 これはWorksというパブリック・プロパティで、 personという引数を取る新しいperson job builderを返す。 オリジナルの人間、 作り上げられる人間。 だから、 私はここで人と言うつもりだ。 つまり、 Worksというプロパティができたので、 これを使い始めれば、 person builder、 dot works、 dot addと言えるようになる。 また、 例えばファブリカムという会社名を記入することもできる。 そして、 次の行に進み、 それをきれいにインデントして、 例えば、 彼はエンジニアとして働いていて、 12万3000ルーブルの収入を得ていると言うことができる。 セミコロンを入れるとすぐに、 レシャーパーは全体をリフォーマットする。 だから、 プレゼンテーションが台無しになってしまうんだ。 とりあえず、 元に戻すつもりだ。 雇用情報はファセットであり、 もう一つのファセットはその人の住所である。 そのために別のビルダーを作るだけだ。 そのプロセスを理解していただければ幸いだ。 だから、 これからすることは、 アドレスビルダーを貼り付けることだ。 それでは、 どうぞ。 人物住所ビルダー 非常にシンプル。 また、 その人のリファレンスも必要で、 この、 リファレンスのあるものは便利だということをもう一度強調しておかなければならない。 私たちは、 その同じ言及を土台にしているんだ。 私たちは、 これらすべてのサブビルダーを経由して渡される人への単一の参照を持っている。 しかし、 もしあなたがバリュー型を持っているなら、 言ってみれば困ったことになるかもしれない。 明らかに我々のケースとは違う。 つまり、 public person address builderが生きていて、 その人をもう一度渡して新しいperson address builderを返すことができるのだ。 さて、 これで何がわかる? またしても流暢なインターフェイスを手に入れたことがおわかりいただけるだろう。 Addというメソッドがある。 つまり、 その人は、 郵便番号のある住所に住んでいるわけだ。 そしてこの情報は、 パーソン・ビルダーのどこにでも追加することができる。 例えば、 ここに入って、 Lives dot addと言い、 123 London Roadと言うことができる。 そして、 ここを手動でインデントして、 例えば、 郵便番号をWからCにして、 in Londonと言うことができる。 住所の構築から雇用情報の構築にジャンプできるのは、 住所ビルダーも雇用ビルダーも、 人物ビルダーから受け継いだ通知を継承しているからだ。 つまり、 両者とも他のすべてのビルダーを暴露しているのだ。 その結果、 そう、 人の命のようなものを書くことができる。 生活している。 永遠に生きる。 全然構わないよ。 でもね、 それは便利なものを使おうとしていることの副次的な効果なんだ。 そこで私たちが行ったのは、 2つのサブビルダーを使い、 人物を作り上げるための流暢なインターフェイスを提示することだ。 しかし、 興味深いことに、 今、 この右の行にpersonと書くと、 personは実際にはperson job builderなので、 最後にpersonが来ないのは明らかだ。 それが最後の決断だ。 つまり、 別のAPIを導入することなく、 実際に人を獲得するにはどうすればいいかということだ。 そして、 それが今回のケーキの上のアイシングなのだろう。 人物ビルダーに行く場合、 私がよくやるのは、 それほど正しいプログラミング・アプローチではないが、 こうする。 PBと私は単にPBをドットパーソンに返すだけだ。 オーケー。 明らかにスモールPだ。 これでよし。 そこで私がやっているのは、 personへの暗黙の変換演算子を導入して、 次のように書くことだ。 だからvarを使い続けることはできないが、 person, personと書けばうまくいく。 では、 実際にこれをコンパイルして実行してみよう。 そして見ての通り、 私たちは作り上げられた人間を手に入れている。 住所は正しく初期化され、 雇用情報も正しく初期化された。 だからこれはもっと複雑な例だ。 実際にこのコードをダウンロードして、 何が起こっているのか調べてみることをお勧めする。 つまりファサードとは、 その背後に多くの情報を隠すコンポーネントのことである。 ここでは、 サブビルダーのクラスをパブリックにしているが、 想像できるように、 それらを個人ビルダーの内部クラスにして、 その内部をコンシューマーから隠すこともできる。 それも十分に可能だ。 これがファセット・ビルダーのアプローチだ。