アプリケーション開発のある時点でファサード パターンが必要であることをどのように知ることができますか?
Facade パターンと Template パターンの間に線を引くにはどうすればよいですか?
例: [この]記事ではint placeOrder(int CustomerID, List<BasketItem> Products)
、アルゴリズムにいくつかの事前定義されたステップがあることがわかります。では、著者はここで Template Pattern を使用しないのはなぜですか?
アプリケーション開発のある時点でファサード パターンが必要であることをどのように知ることができますか?
Facade パターンと Template パターンの間に線を引くにはどうすればよいですか?
例: [この]記事ではint placeOrder(int CustomerID, List<BasketItem> Products)
、アルゴリズムにいくつかの事前定義されたステップがあることがわかります。では、著者はここで Template Pattern を使用しないのはなぜですか?
ファサードは、実装ではなくインターフェースを扱います。その目的は、外見は単純に見える単一のインターフェースの背後にある内部の複雑さを隠すことです。あなたの質問の例では、ファサードは 4 つのクラス (Order、OrderLine、Address、BasketItem) を単一のメソッドの背後に隠しています。
テンプレートメソッドは実装を扱います。その目的は、「空白を埋める」方法のみが異なるいくつかのアルゴリズムから共通のアルゴリズムを抽出することです。スーパークラスのテンプレート メソッドは共通のアルゴリズムを実装し、各サブクラスは独自の方法で「空白を埋めます」。
では、著者はここで Template Pattern を使用しないのはなぜですか?
placeOrder
操作の類似したバージョンがいくつかある場合、テンプレート メソッドを作成することは理にかなっています。、、のようないくつかのメソッドは、placePhoneOrder
{ phone,internet,manual} 固有の違いのみを実装するいくつかのサブクラスを持つ1 つのテンプレートにリファクタリングされる可能性があります。placeInternetOrder
placeManuallyEnteredOrder
placeOrder
ファサードパターンは、単純化された方法でクライアントに公開する複雑なシステムがある場合、またはシステムと互換性のない既存のシステム上に外部通信レイヤーを作成する場合に適しています。構造模様です。ここを参照してください:http://en.wikipedia.org/wiki/Facade_pattern
一方、テンプレートパターンは、コンポーネントの内部実装を処理するときに役立つ動作パターンです。ここを参照してください:http://en.wikipedia.org/wiki/Template_method_pattern
いくつかのサービスやライブラリなどがあるとします。これらのライブラリは、いくつかのより高いレベルのサービスを実行するために相互運用が必要です。次に、通常は一緒に実行されるこれらの呼び出しと初期化コードをラップして、それらの詳細を非表示にし、特定のシナリオでこれらのサービスを簡単に使用できるようにする一連の関数を提供することをお勧めします。次に、ファサードパターンの良い使用法です。
更新:前述の記事で、PlaceOrderメソッドには、すべての注文に対して機能する単一の実装があります。テンプレートパターンは、従う必要のある一連のステップを規定することを目的としていますが、サブクラスがそれらの固定ステップのカスタム実装を提供できるようにします。たとえば、テレビの注文を電子レンジの注文とは異なる方法で処理する必要がある場合は、テンプレートパターンを使用して、架空のDispatchParcelメソッドを再定義できます(電子レンジを単純なパッケージとして送信しますが、重いデバイスを上の階)。この場合、ProcessOrderステップを再実装する必要がないため、1つの実装がすべてのタイプの注文に適合するため、テンプレートパターンは必要ありません。