尝试创建由UML类图表示的系统设计。可能使用适配器模式？

Posted 2021-05-06

我需要描述一个系统的通用设计，该系统将处理不同类型的收费站及其组件，用于作业问题：

你是一家在高速收费站上垄断市场的公司的首席开发商。您的公司生产简单的展位，车辆开着，司机将钱交给记录交易的收费员并提供更改。但收费站的行业还有很多。一些收费站有自动打开和关闭的门，或者由收费员手动打开和关闭。有不同类型的门控制器;一些带有自动打开和关闭的门（带或不带定时器 - 有些使用运动传感器和阻塞传感器来确定何时关闭门）。一些门控制器允许连接不同类型的门。除此之外，没有关于门的软件或系统中任何其他组件如何工作的标准。也就是说，它们没有标准接口。为您的客户提供的道路系统有自己的收费方式。有些人会允许使用现金并将其插入硬币收藏家。有些人允许信用卡。有些人在您进入道路系统时发出票，然后在退出时支付通行费。今天，大多数收费公路都采用了像E-Z Pass这样的自动支付系统，但并非全部。该公司认为收费站的销售正在蓬勃发展，并希望有一个软件系统可以处理当前和未来存在的所有可能的变化，而无需大量的重写代码。这是作为公司的首席开发人员/架构师给您的。

我知道有不同类型的门，支付机制，一些传感器和上面提到的其他东西。我还试图说明客户在从“这家公司”订购收费站时可以做出的变化。

我正在创建一个UML类图，它显示了关键组件以及它们之间的关系，但我不确定要使用的设计。我认为适配器模式是一个很好的选择吗？听起来不错吗？

我已经创建了基本的起始类，如Client，Tollbooth和Gate。我知道Client知道Tollbooth和Tollbooth知道Gate，但我是如何进行接口和具体方法？

答案

What is the goal ?

您将设计的软件将操作工具台，该工具台由许多非常不同类型的互连组件组成，例如门，门控制器，传感器，“手动”控制器，票务系统，信用卡读卡器，硬币收集器。

在这方面，Customer与此设计无关，因为该软件将与收费站设备配合使用，并不关心不同的客户。

What is the key for the expected design ?

叙述很好地解释了它：

（...）没有关于门的软件或系统中任何其他组件如何工作的标准。也就是说，它们没有标准接口。

我们知道展位的配置可能会有很大差异：

• 至少有一个门控制器可以控制一个或两个门，一个支付系统和一个传感器。
• 支付系统可以是操作手动控制的人，或者是全自动支付系统（或两者，如果信用卡在读卡器中被阻止的话）。
• 门控制器可以与一个或多个传感器和定时器交互。
• 当存在时，自动支付系统可以与不同的票务和支付设备交互。它还可以与传感器交互。

因此关键是构建一个系统，让不同的组件使用众所周知的界面协同工作。

Design patterns ?

首先，您必须了解在设计师的现实生活中，您不会查看问题并浏览模式目录以选择正确的模式。设计模式仅在存在常见问题且提出的解决方案符合其他设计约束时才有用。

幸运的是，在这里，我想到了两种设计模式：

• mediator设计模式通过支付系统，门控制器以及具有相同同事界面的不同计时器和传感器之间的协调来提供帮助。
• composite设计模式有助于使组件可以由可变数量的子组件组成。

Is there a best choice ?

我不知道你的作业设计有多现实，也不知道你的专业水平是多少：

• 您可以选择简化设计，以识别配置的主要组件，每个组件提供特定于其类型的假设接口（抽象类）（例如Sensor），这允许专门化具体类（例如MotionSensor）。如果您处于初级水平，请选择此项。
• 您可以仅使用介体选择非常扁平的结构。这是软件总线的原理。每个组件都必须满足公共接口，但是eery组件必须通过介体进行通信，理解为可以有不同的适配器来使不同类型的组件适应介体的要求。如果你处于中级水平，这是一个候选人。
• 您可以选择混合方法，介体确保主要组件之间的通信，每个组件都可以是可配置的组合。这是一种非常务实但可扩展的方法。如果你处于中级水平，这也是一个候选人。
• 您可以选择复合，其中每个组件都可以充当其子组件的专用中介。这非常复杂。但是在20年后，这种设计仍然可以满足需求（例如，当您连接智能面部识别系统时）。只有在您达到高级水平时才选择此项。

另一答案

以下是找到合适的技术解决方案（具有设计模式）而不是尝试为给定要求设计完整解决方案的示例。

该方法的高概述是重新制定要求以强调技术方面。

首先跳过像There are different types of gate controllers; some that come with gates that open and close automatically...这样的细节并注意共同点

• 处理付款
• 处理（打开/关闭）门

两者都可以被视为行为

第二步，逐步添加细节

• 处理付款 手动：操作员拿钱，记录交易，返回更改 自动：系统读取信用卡，收取金额，记录交易 票证：系统发出票证，一段时间后（当驱动程序到达存在时）处理事务
• 处理大门 手动闸门控制器：操作员无需操作，操作闸门 自动门控制器：在一个信号打开门，在第二个信号关闭门。第一信号应来自交易处理器，第二信号可来自定时器或运动传感器或障碍物传感器

从第二步开始很容易注意到，这可能是第一步中确定的行为的不同实现。在第二步中，可以注意到其他一些行为

• 发出信号
• 发出信号 使用计时器 使用运动传感器 使用障碍物传感器

继续添加详细信息并检查新行为，直到所有细节都用完为止

第3步确定系统中涉及的模型（包含详细信息）

• 付款方式：保留金额和付款日期
• 门：保持门的状态（打开/关闭）
• 信号：打开/关闭
• ...

第四步确定行动

• TransactionProcessor：接收付款的详细信息并处理它们
• 传感器：产生关闭门信号的信号
• GateController：处理来自支付处理器或传感器的信号
• ...

第五步将模型和动作放在一起

• 开始（由结账机或信用卡终端的操作员触发或......）
• 建立Payment对象
• 并将其发送到TransactionProcessor
• 并且TransactionProcessor使用Payment对象中的详细信息处理事务并返回事务的详细信息（状态ok / nok）
• 如果交易正常，建立Signal打开大门
• 并将其发送到GateController
• 而GateController打开了Gate
• 并等待关闭Signal
• 和Sensor产生密切的Signal
• 而GateController关闭了Gate

请注意，在第5步中没有关于如何处理事务以及如何生成信号的详细信息，因为这些是实现细节。在这一步骤中，应该细化抽象（例如在Java中的接口）

第6步添加实现细节（第5步中定义的抽象的实现）

• 如何处理人工付款
• 如何处理信用卡付款
• 如何产生近距离信号（基于传感器或定时器或...）
• ...

行为

• 处理付款（具有不同实施的策略） 用结账机手动 自动使用信用卡 通过门票
• 处理门（具有不同实现的策略） 手动 自动运动传感器 自动带阻塞传感器 自动超时

需要建模检查behavioral design patterns列表。

• Strategy可用于实施上述行为
• Command可用于实现开/关门

其他有用的设计豹（非行为）可能是Observer用于实现传感器门（观察传感器和处理门）

这种解决方案可以在需要时通过现有行为的新实现（处理门的不同方式或处理支付的不同方式或要使用的新传感器）轻松扩展，而不会影响现有的