いくつかの複雑なサブシステムを隠すために Facade を実装すると、最終的にクライアント用のクラスが 1 つになります。しかし問題は、この 1 つのクラスにまだ 100 を超える API があることです。これは、結合原理に反しているように見えます。また、ファサード クラスは、サブシステム間で使用されるオブジェクトを非表示にできるように状態を管理します。システムは、サブシステム (プロジェクト、ポリシー、ユーザー、パーミッションなど) で構成されており、ファサードをよりモジュラーな方法で設計できると思います。この場合、ファサードでうまく機能するデザインパターンはありますか?
2 に答える
1
すでに述べたように、1 つのクラスに 100 を超える API を含めることはお勧めできません。これらは、異なるファサード クラスに分割できます。一般的な機能は基本クラスに移動できます。これはデザインパターンではなく、オブジェクト指向のコアです。状態はまだ維持できます。状態を保存するためのストアとしてセッションを既に使用しているかどうかはわかりません。もしそうなら、あなたはまだそうし続けることができます。
キャッシュを使用して状態を保存したり、データベースを使用したりすることもできます。EJB を使用している場合は、SFSB がこの機能を提供します。
于 2013-04-20T02:30:13.520 に答える
1
ドメイン駆動設計の原則に従えば、システムをステートレス サービスとステートフル エンティティに分離できます。サービスとステート マシンを 1 つのファサードに組み合わせることは、必ずしも良い考えではありません。
ところで、私の意見では、ファサードを使用することは、オブジェクト指向言語に手続き型プログラミングを強制するようなものです。ファサードは、非 OOP 言語のモジュールのような単なる関数のセットです。そのため、一般的に、OOP を使用するときはファサードを避けるようにしていますが、実用的であることは良いことです。
于 2013-04-20T02:31:49.233 に答える