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

【问题标题】："Client" concept in OOP Design Patterns?OOP 设计模式中的“客户端”概念？
【发布时间】：2013-03-28 16:30:18
【问题描述】：

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

【问题讨论】：

标签： oop design-patterns client concept

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

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

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

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

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

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

【讨论】：

你能用观察者模式举例吗
我添加了一个抽象工厂模式的例子。
非常感谢。我在 GoF Design Pattern : Elements of Reusable Object-Oriented Software 中读到它。

【解决方案3】：

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

因此，客户端接口的意义在于使任意代码能够方便或有可能制定请求并吸引服务器的注意。由于请求消息可能通过多种媒体（例如不同的内存空间）传送，因此通常会涉及某种透明传输，隐藏在此请求接口后面。

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

【讨论】：

感谢您的快速提问，但也许我仍然无法在 OOP 软件设计模式中理解这一点。