对于家庭作业问题，我需要描述一个系统的总体设计，该系统将处理不同类型的收费站及其组件：
您是一家垄断市场的公司的首席开发人员 在高速公路收费站。贵公司生产简单的展位，其中 车辆开上来，司机把钱交给收费员，收费员 记录交易并给出零钱。但还有更多的事情要做 收费站行业。一些收费站的闸门可以打开和关闭 自动，或由收费员手动打开和关闭。 有不同类型的门控器;一些附带的 自动打开和关闭的门(带或不带计时器 - 一些 使用运动传感器和障碍物传感器确定何时关闭 大门)。一些门控制器允许不同类型的门 连接。最重要的是，软件没有标准 用于门，或系统中的任何其他组件工作。那是 它们没有标准接口。适合您的道路系统 客户有自己的收费方式。有些会允许现金 使用并插入硬币收集器中。有些允许信贷 卡。有些人在进入道路系统时发出罚单，然后你 退出时支付通行费。今天，像E-Z这样的自动支付系统 大多数收费公路都使用通票，但不是全部。该公司看到 收费站的销售蓬勃发展，并希望有一个可以 处理当前和 未来无需大量重写代码。这已经给了你作为 公司的首席开发人员/架构师。
我知道有不同类型的门，支付机制，一些传感器以及上面提到的其他东西。我还试图解释客户在从"这家公司"订购收费站时可以做出的变化。
我正在创建一个UML类图，该图显示了关键组件以及它们之间的关系，但我不确定要使用的设计。我认为适配器模式会是一个不错的选择吗？听起来对吗？
我已经创建了基本的起始类，如Client、Tollbooth和Gate。我知道Client知道Tollbooth，Tollbooth知道Gate，但是当涉及到接口和具体方法时，我该如何进行？
下面是一个寻找合适的技术解决方案(具有设计模式)的方法示例，而不是尝试为给定需求设计完整的解决方案。
该方法的高度概述是重新制定要求以强调技术方面。
首先跳过There are different types of gate controllers; some that come with gates that open and close automatically...等细节并注意共同点
- 处理付款
- 把手(打开/关闭)门
两者都可以被视为行为
第二步，增量添加详细信息
-
处理付款
- 手动：操作员取钱，记录交易，返回零钱
- 自动：系统读取信用卡，收取金额，记录交易
- 票证：系统发出票证，一段时间后(当驱动程序到达存在时)处理交易
-
处理闸门
- 手动门控制器：无需任何操作，由操作员处理闸门
- 自动门控器：在一个信号上打开闸门，在第二个信号上关闭闸门。第一个信号应来自事务处理器，第二个信号可能来自计时器或运动传感器或障碍物传感器
从第二步很容易注意到，这可能是第一步中确定的行为的不同实现。在第二步中，可以注意到一些其他行为
- 发出打开信号
- 发出收盘信号
- 使用计时器
- 使用运动传感器
- 使用障碍物传感器
继续添加详细信息并检查新行为，直到用尽所有详细信息
第三步确定系统中涉及的模型(包含详细信息)
付款- ：保留金额和付款日期 门
- ：保持门的状态(打开/关闭)
- 信号：打开/关闭
- 。
第四步确定操作
- 交易处理器：接收付款的详细信息并处理它们
- 传感器：产生像关闭门信号一样的信号
- 门控器：处理来自支付处理器或传感器的信号
- 。
第五步将模型和动作放在一起
- 启动(由操作员从结账机或信用卡终端触发，或...
- 生成
Payment对象 - 并将其发送到
TransactionProcessor TransactionProcessor使用来自Payment对象的详细信息处理事务，并返回事务的详细信息(状态 OK/NOK)- 如果交易正常，则建立
Signal以打开大门 - 并将其发送到
GateController GateController打开Gate- 并等待关闭
Signal Sensor生成收盘SignalGateController关闭Gate
请注意，在第 5 步中，没有关于如何处理事务或如何生成信号的详细信息，因为这些是实现细节。在此步骤中，应该优化抽象(例如在Java中的接口)
第6 步添加实现详细信息(第 5 步中定义的抽象的实现)
- 人工付款的处理方式
- 如何处理信用卡付款
- 产生多近的信号(基于传感器或计时器或...
- 。
由于行为
- 处理付款(具有不同实现的策略)
- 使用结账机手动
- 使用信用卡自动
- 通过门票
- 处理门(具有不同实现的策略)
- 手动地
- 自动带运动传感器
- 自动带障碍物传感器
- 自动超时
需要建模检查行为设计模式列表。
- 策略对于实现上述行为可能很有用
- 命令对于实现打开/关闭门很有用
其他有用的设计豹(非行为)可能是 使用传感器实现门的观察者(观察传感器并处理门)
当需要时，可以通过现有行为的新实现(处理门的不同方式或处理付款的不同方式或使用的新传感器)轻松扩展这样的解决方案，而不会影响现有的