質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
オブジェクト指向

オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

デザインパターン

デザインパターンは、ソフトウェアのデザインでよく起きる問題に対して、解決策をノウハウとして蓄積し再利用出来るようにした設計パターンを指します。

Q&A

解決済

2回答

7456閲覧

Facadeパターンの考え方について

i50

総合スコア227

オブジェクト指向

オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

デザインパターン

デザインパターンは、ソフトウェアのデザインでよく起きる問題に対して、解決策をノウハウとして蓄積し再利用出来るようにした設計パターンを指します。

0グッド

0クリップ

投稿2015/08/27 05:31

Facadeパターンの考え方について悩んでおります。

いわゆるFacadeパターンは、
こういう感じになっていると理解しています。

PHP

1//すみません、等幅にしたい為だけにPHPを選んでいます 2 +-->処理パターンA<---+ 3 | (使う) 4処理まとめ役--(使う)--+-->処理パターンB<---+ 5 | 6 +-->処理パターンC

ここで、いくつかサイトを見てみますと
https://ja.wikipedia.org/wiki/Facade_%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3

Facadeクラスをサブシステム自体が利用する事はない。

http://d.hatena.ne.jp/asakichy/20090314/1237030727

つまり、サブシステム内のクラスは Facade オブジェクトへの参照を保持しない。

と書いてあります。

つまり、こういう実装はしないものだ、と理解しています。

PHP

1 +-----(使う)----------+ 2 | | 3 | +-->処理パターンA 4 v | 5処理まとめ役--(使う)--+-->処理パターンB 6 | 7 +-->処理パターンC

しかし、「処理パターンA」が他の処理パターンの結果を必要とする場合、
どの処理パターンを使うかを含めて「処理まとめ役」に再帰的に処理を委ねたい、
という事もあるかと思っています。
(数式の構文解析で言うところの、()の処理みたいなイメージでしょうか…?)

処理まとめ役は、全ての処理パターンの内容を知っているけれど、
各処理パターンは、全ての互いの内容を知っている必要はない、と考えています。

そこで疑問なのですが、なぜ

Facadeクラスをサブシステム自体が利用する事はない。

と、あえて明言しているのでしょうか。

「処理まとめ役」と「処理パターンA」の関係が密になりすぎる(?)ためNG、なのでしょうか。
NGであるならば、

しかし、「処理パターンA」が他の処理パターンの結果を必要とする場合、
どの処理パターンを使うかを含めて「処理まとめ役」に処理を委ねたい、

というような事がある場合、なにか他に良い考え方がある、という事なのでしょうか。

どうか、よろしくお願い致します。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

Facadeの定義としてどうこうではなく、単純に循環依存が発生するからでしょう。

まとめ役はサブシステムAやサブシステムBに論理的にも実装的にも依存してよいです。しかしサブシステムAがまとめ役に依存すると、その結果は「お互いに依存する」ことになりますよね。これを循環依存といいます。循環依存を防ぐ方法はいろいろありますから、調べてみてはいかがでしょう。

非循環依存関係の原則(ADP) - Strategic Choice

投稿2015/08/27 05:49

sharow

総合スコア1149

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

i50

2015/08/27 06:22

ご回答ありがとうございます! リンク先拝見いたしました。 (しかも例で示したサイトから、ありがとうございます!) > DIP適用 これは目から鱗です。 まとめ役の機能をインターフェースとして分離し、 サブシステムAがそのインターフェースに依存するならば、 問題はないと理解しました。 > 依存吸収新パッケージ追加 この発想もありませんでした。 サブシステムAが必要としている機能そのものを、 新たなサブシステムとして実装すればよい、 と理解しました。 循環依存は思いっきりやらかしてしまっている所があるので、 さっそく見直してきます!
guest

0

ベストアンサー

Facadeクラスは窓口です。いきなりFacadeクラスを追加すると混乱するので、なしで考えます。
質問中のクラス図のなかで、システムとなっているのは下記の3つです。
・処理パターンA
・処理パターンB
・処理パターンC
上記は各自が様々な機能を外部に公開し、互いに連携しシステムXを実現しています。

このシステムXを利用してシステムYを作ることになりました。ここでやっとFacadeクラスの登場です。FacadeクラスはシステムYから与えられた要求を解釈し、システムXの特定の機能を呼び出します。そして、その結果をシステムYに返します。

上の話をまとめると。
・Facadeが使うクラス群はシステムとして独立している。
・Facadeを利用するシステムは別のシステムの一部機能を利用したい。

ここで、質問に答えると

Facadeクラスをサブシステム自体が利用する事はない。

→なぜならサブシステムが独立して存在しているからこそ、Facadeが存在するからです。利用してしまうと、サブシステムの中にFacadeが組み込まれてしまい、それはFacadeの意味をなくしてしまいます。

しかし、「処理パターンA」が他の処理パターンの結果を必要とする場合、

どの処理パターンを使うかを含めて「処理まとめ役」に処理を委ねたい、
→サブシステム内で完結するはずの処理がはみ出ているため、上の独立したサブシステムを満たしていないように思います。

投稿2015/08/27 06:12

yona

総合スコア18155

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

i50

2015/08/27 06:38

ご回答ありがとうございます! >サブシステムの中にFacadeが組み込まれてしまい、それはFacadeの意味をなくしてしまいます。 なるほど!! つまり、今回の私の例で言うと、 「処理パターンA」が必要としている「処理まとめ役」の振り分けの機能は、 そもそも「処理パターンA」がその機能を必要としている時点で、それはサブシステムの一部であって、 Facadeとは関係がない、という事と理解しました。 Facadeの事は一旦忘れて、 依存吸収新パッケージ追加で、サブシステムの一部として実装するのがよさそうですね。 ありがとうございます!
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問