【问题标题】:Java's "Scanner" Method vs. Facade GoF Design PatternJava 的“扫描仪”方法与门面 GoF 设计模式
【发布时间】:2019-09-01 06:18:01
【问题描述】:

我正在研究设计模式以提高我的编程技能。现在,我正在探索外观设计模式。

我自己可能会感到困惑,但是,举个例子:Scanner 不是门面吗? 请注意,我不是在问什么是 Facade,而是试图确定 Scanner 是否是。

好吧,我声明它是为了让我可以使用某些功能而无需接触复杂和更深层次的功能,对吧?

我声明

Scanner sc = new Scanner(System.in);

所以我可以:

String x = sc.nextLine();

【问题讨论】:

标签: java oop design-patterns facade


【解决方案1】:

这是一个很好的类示例,它简化了 API 并使其更清晰、更接近用途。当我们想从控制台应用程序中的用户读取数据时,InputStream 将很难使用。让我们看一下Facade 模式的一些定义并与Scanner 类匹配:

意图

  • 为子系统中的一组接口提供统一接口。 Facade 定义了一个更高级别的接口,使子系统 更易于使用。
  • 用更简单的接口封装复杂的子系统。

Scanner 类匹配以上两点。

检查清单

  1. 为子系统确定一个更简单、统一的接口或 组件。
  2. 设计一个封装子系统的“包装器”类。
  3. 外观/包装器捕获了复杂性和协作性 组件,并委托给适当的方法。
  4. 客户端仅使用(耦合到)外观。
  5. 考虑额外的外墙是否会增加价值。

Scanner 类匹配以上所有点。因此,我们可以将Scanner 视为InputStream 的外观。

【讨论】:

  • 完美!谢谢你。我认为我在正确的道路上前进
  • Scanner 没有统一任何一组接口,也没有简化它封装的Readable 接口。 Scanner API 远比 Readable 复杂。
  • @jaco0646, Facade 也可以将API 简化为一个interface。当然,当我们有不止一个但一个就足够时,这一点就很清楚了。也许它的APIReadable 复杂得多,但是当我们从控制台读取数据时它更容易使用。 parseIntnextLinehasNextLineread 下一个字节更易于理解和使用。此外,我们可以在Scanner 之上创建其他Facade,从而简化控制台的使用以满足我们的要求。例如,如果我们只需要从控制台读取几个数字,我们可以将 Scanner API 限制为仅需要的方法。
【解决方案2】:

Facade 将一对多的关系整合为客户的一对一关系。它们变得更简单,因为它们依赖于一个(高级)Facade,而不是许多(低级)单独的组件。 Facade 本身接管了许多低级依赖项(并委托给它们)。

Scanner 与其Readable source 的关系是普通的旧对象组合。没有合并依赖项。虽然Scanner 确实提供了新功能并且是比Readable 更高级别的抽象,但对于许多或大多数组合关系来说都是如此。

Facade 既减少了依赖关系(耦合),又增加了对其客户端的抽象。请注意,Facade 模式的图表总是显示来自 Facade 对象的多个外向箭头。

【讨论】: