JavaScript設計モードの外観モード紹介
3219 ワード
外観モードの説明
説明:外観モードは、サブシステムまたはプログラムの構成が複雑であるために提供される高レベルのインタフェースであり、クライアントを使用して最下位のプログラムまたはシステムインタフェースにアクセスしやすい.
外観モードは、いくつかのサブインタフェースまたはサブシステムに関連する機能が必要になる可能性がありますが、私たちのある機能は、複数のサブインタフェースのうちの1つまたは複数の構成の順序にカプセル化するだけである可能性があります.ビジネス機能がサブインタフェースやサブシステムに直接対応している場合は、開発者に内部の理解が必要になる可能性があります.ビジネスプロセスがどのように行われているのか、彼の順番が何なのかなどを知る必要があります.これは、開発者がビジネスを理解し、クライアントのプログラミングをかなり複雑にする必要があります.
ここで、もし1階層、あるいは1つのクラスがあれば、私たちが使用する方法をパッケージ化することができます.クライアント機能はこの中間層クラスと対話するだけで、中間層クラスの対応する方法は業務の関連開発者の組織パッケージを理解しているので、プログラムは非常に簡単になります.プログラマーは彼のこの機能に必要な対応方法がどれなのかを知るだけでいいです.内部の論理も知らなくてもいい.
この中間層類は私たちが言った外観類であり、これが外観モードの思想である.
シーンインスタンス:
1>. 例えば、総スイッチの例では、この総スイッチは、家のドアの明かりを制御することができ、ホールのいくつかの明かりを制御することができ、家のテレビ、冷蔵庫などの電力供給を制御しています.どうせ直接押すと電話がかかってくる.
これらの電灯、テレビなどは私たちが使うインタフェース、小さなシステムです.この総スイッチは私たちの外観類で、私たちは直接それに直面して操作すればいいです.
2>. また、会社のように、いくつかの職能部門があります.ボスはいつ各方面の仕事の実行状況が必要ですか.彼は部門の内部に走って、従業員にこの○○のことがどうなっているかを聞いて、もし人に聞いたら、直接ボスに答えて、この人が責任を持っているかどうかを聞いて、彼はまたボスに言います.ああ、このことは誰が責任を持っているのか、社長はまたあの人に聞いてみなければなりません.面倒ですね.
もし各職能部門に主管責任者を設置すれば、ボスは直接それを探して状況を知ることができて、ボスもこの責任者がどのようにこれらを知っているかに関心を持つ必要はありません.彼はこのような1、2、3件のことの状況と進展を知りたいだけです.
インスタンスソース
2番目のインスタンスシーンでソースコードを実装します.
1.いくつかの部門職能類:
部門1(業務部門):
部門2(研究開発部門):
以上は各部門の主管がボスの質問に答えることです.
次に、ボスが聞きたい質問を組織するための外観クラスを作成します.
それから社長は二人のマネージャーを前に呼んで、話を聞き始めました.
その他の説明
外観モードを使用すると、インタフェースまたはクラス間をデカップリングして、クラス間で依存を生じる必要がなく、使用する必要がない場合はAがBを含むか、Bが必ずAを含むようにすることができます.これは、クローズ修正の原則に反し、中間層の外観クラスパッケージを使用して、インタフェース呼び出しを簡略化し、サブインタフェースまたはサブシステムオブジェクト呼び出しを使用してより自由に組織することができます.
外観モードはよく私たちのプログラミングの中で現れて、外観モードはよくアーキテクチャシステムのモード定義の中で現れて、私たちのシステムは第三者のインタフェースサービスを使って、よく外観層を加えて利用可能な業務インタフェースを組織するために使います;
説明:外観モードは、サブシステムまたはプログラムの構成が複雑であるために提供される高レベルのインタフェースであり、クライアントを使用して最下位のプログラムまたはシステムインタフェースにアクセスしやすい.
外観モードは、いくつかのサブインタフェースまたはサブシステムに関連する機能が必要になる可能性がありますが、私たちのある機能は、複数のサブインタフェースのうちの1つまたは複数の構成の順序にカプセル化するだけである可能性があります.ビジネス機能がサブインタフェースやサブシステムに直接対応している場合は、開発者に内部の理解が必要になる可能性があります.ビジネスプロセスがどのように行われているのか、彼の順番が何なのかなどを知る必要があります.これは、開発者がビジネスを理解し、クライアントのプログラミングをかなり複雑にする必要があります.
ここで、もし1階層、あるいは1つのクラスがあれば、私たちが使用する方法をパッケージ化することができます.クライアント機能はこの中間層クラスと対話するだけで、中間層クラスの対応する方法は業務の関連開発者の組織パッケージを理解しているので、プログラムは非常に簡単になります.プログラマーは彼のこの機能に必要な対応方法がどれなのかを知るだけでいいです.内部の論理も知らなくてもいい.
この中間層類は私たちが言った外観類であり、これが外観モードの思想である.
シーンインスタンス:
1>. 例えば、総スイッチの例では、この総スイッチは、家のドアの明かりを制御することができ、ホールのいくつかの明かりを制御することができ、家のテレビ、冷蔵庫などの電力供給を制御しています.どうせ直接押すと電話がかかってくる.
これらの電灯、テレビなどは私たちが使うインタフェース、小さなシステムです.この総スイッチは私たちの外観類で、私たちは直接それに直面して操作すればいいです.
2>. また、会社のように、いくつかの職能部門があります.ボスはいつ各方面の仕事の実行状況が必要ですか.彼は部門の内部に走って、従業員にこの○○のことがどうなっているかを聞いて、もし人に聞いたら、直接ボスに答えて、この人が責任を持っているかどうかを聞いて、彼はまたボスに言います.ああ、このことは誰が責任を持っているのか、社長はまたあの人に聞いてみなければなりません.面倒ですね.
もし各職能部門に主管責任者を設置すれば、ボスは直接それを探して状況を知ることができて、ボスもこの責任者がどのようにこれらを知っているかに関心を持つ必要はありません.彼はこのような1、2、3件のことの状況と進展を知りたいだけです.
インスタンスソース
2番目のインスタンスシーンでソースコードを実装します.
1.いくつかの部門職能類:
部門1(業務部門):
function BusinessDept() {
this.manager = ' '; //
}
BusinessDept.prototype = {
MonthSales: function() {
console.log(this.manager + ' ： xxx');
},
NextPlan: function() {
console.log(this.manager + ' ： ,xxxx');
}
}
部門2(研究開発部門):
function RDdept() {
this.manager = ' ';
}
RDdept.prototype = {
progress: function() {
console.log(this.manager + ' ： xxx');
},
deptPlan: function() {
console.log(this.manager + ' ： xxx');
}
}
以上は各部門の主管がボスの質問に答えることです.
次に、ボスが聞きたい質問を組織するための外観クラスを作成します.
function Facade() {
this.business = new BusinessDept() ;
this.rddept = new RDdept();
}
Facade.prototype = {
DeptSituation: function() {
this.business.MonthSales(); // ;
this.rddept.progress();
},
deptPlan: function() {
this.business.NextPlan(); // ;
this.rddept.deptPlan();
}
}
それから社長は二人のマネージャーを前に呼んで、話を聞き始めました.
var facade = new Facade();
console.log(' ： ?');
facade.DeptSituation();
console.log(' ： ?');
facade.deptPlan();
その他の説明
外観モードを使用すると、インタフェースまたはクラス間をデカップリングして、クラス間で依存を生じる必要がなく、使用する必要がない場合はAがBを含むか、Bが必ずAを含むようにすることができます.これは、クローズ修正の原則に反し、中間層の外観クラスパッケージを使用して、インタフェース呼び出しを簡略化し、サブインタフェースまたはサブシステムオブジェクト呼び出しを使用してより自由に組織することができます.
外観モードはよく私たちのプログラミングの中で現れて、外観モードはよくアーキテクチャシステムのモード定義の中で現れて、私たちのシステムは第三者のインタフェースサービスを使って、よく外観層を加えて利用可能な業務インタフェースを組織するために使います;