使用Facade设计模式|缺点/解决方案/建议

时间:2013-10-14 06:42:52

标签: java design-patterns

Facade Object中的每个方法都是在多个接口中公开的其他几种方法的组合。在此期间,随着我们将了解通过组合复杂系统及其方法中可用的不同接口可以实现的不同操作,该对象也将增长。

我的问题很简单:

1)继续使用Facade是一个更好的选择还是我们还有其他选择?因为随着我们增加容纳Facade对象中每个新操作的方法数量,它也变得复杂。 我能想到的一个可能的解决方案是创建一个Facade

2)此外,当我们说它变得复杂时,是否存在外观暴露的限制方法? Update我的分析说如果难以理解并重新考虑您的设计,请停止向Facade添加更多方法; is that it

1 个答案:

答案 0 :(得分:3)

由于您的问题非常抽象,因此很难以保证对您所撰写的内容有所帮助的方式回答它。

据我所知,你问的问题确实是,如果你有

interface A {  public void a(); }
interface B {  public void b(); }

class ABFacade {
   private final A a = ...
   private final B b = ...
   public void ab() {  a.a(); b.b(); }
}

然后是否有用?

答案将取决于

  • 问题域 - 它的定义有多好?
  • 你如何命名 - 人们会理解吗?
  • 代码重用 - 是否需要调用一个Facade方法?

我认为没有一个正确的答案 - 至少没有具体的例子。它还取决于使用此模式的目的是什么 - 更好的代码重用?执行复杂操作的重复代码集更少?创建阻塞点所有X必须通过的代码?其他开发人员的清晰度?该问题的答案深刻地影响了代码的外观。

我可以提出一些可能有助于产生有用效果的一般性事项:

  • 如果一个facade方法只在一个地方使用,它可能不值得在外观 - 如果代码只有一个客户端,那么内联所有步骤可能更有意义
  • 门面上的某些操作是否可以明确命名?结果会比写出立面所做的一切更直观吗?如果是这样,那么可能应该在立面上

最后,这只是一种模式。如果它允许您编写更小,更好或更可靠的软件,请使用它;如果没有,请不要打扰。