OOP设计模式中的“客户”概念？

Question

我阅读了许多关于GoF的OOP设计模式的主题，但我不确定“客户端”的概念。那是什么？我们如何在我们的应用程序中实现它。谢谢！

Answer 1

在gof书中，客户端是使用模式中的类的代码或类。

例如，来自动机下的抽象工厂模式：

考虑支持多种外观标准的用户界面工具包，例如Motif和Presentation Manager。不同的外观定义了用户界面“小部件”（如滚动条，窗口和按钮）的不同外观和行为。为了在外观标准之间移植，应用程序不应该为其特定的外观和内容硬编码其小部件。在整个应用程序中实例化特定于外观的小部件类使得以后很难改变外观。

我们可以通过定义一个抽象的WidgetFactory类来解决这个问题，该类声明了一个用于创建每种基本类型的小部件的接口。每种窗口小部件都有一个抽象类，具体的子类为特定的外观标准实现窗口小部件。 WidgetFactory的接口有一个操作，它为每个抽象窗口小部件类返回一个新的窗口小部件对象。客户端调用这些操作来获取小部件实例，但客户端不知道他们正在使用的具体类。因此，客户可以保持独立于流行的外观和感觉。

每个外观标准都有一个WidgetFactory的具体子类。每个子类都实现了为外观创建适当小部件的操作。例如，MotifWidgetFactory上的CreateScrollBar操作实例化并返回Motif滚动条，而PMWidgetFactory上的相应操作返回Presentation Manager的滚动条。客户端仅通过WidgetFactory接口创建窗口小部件，并且不了解为特定外观实现窗口小部件的类。换句话说，客户端只需要提交由抽象类定义的接口，而不是特定的具体类。

WidgetFactory还强制执行具体小部件类之间的依赖关系。 Motif滚动条应该与Motif按钮和Motif文本编辑器一起使用，并且由于使用MotifWidgetFactory而自动强制执行该约束。

Answer 2

作为一种模式，客户端是一个发起与服务器交互的角色，服务器是一个功能性但通常是被动的角色。代表客户端执行请求所述，服务器执行某些操作并以响应的形式返回报告。

因此，客户端接口的目的是使任意代码方便或可能形成请求并吸引服务器的注意。由于请求消息可能通过各种媒体（例如，不同的存储空间）传送，因此通常涉及某种透明传输，隐藏在此请求接口之后。

这几乎是它作为一个概念的长短不一之处。非常灵活的模式（当然适用于客户端/服务器）的缺点之一是需要进入特定的示例，框架或库来具体说明。

Answer 3

客户端只是另一个模块或类，从系统中使用具体模式（全部或部分组件构造模式）