我需要描述一个系统的通用设计，该系统将处理不同类型的收费站及其组件，用于作业问题：
你是一家在高速收费站上垄断市场的公司的首席开发商。您的公司生产简单的展位，车辆开着，司机将钱交给记录交易的收费员并提供更改。但收费站的行业还有很多。一些收费站有自动打开和关闭的门，或者由收费员手动打开和关闭。有不同类型的门控制器;一些带有自动打开和关闭的门（带或不带定时器 - 有些使用运动传感器和阻塞传感器来确定何时关闭门）。一些门控制器允许连接不同类型的门。除此之外，没有关于门的软件或系统中任何其他组件如何工作的标准。也就是说，它们没有标准接口。为您的客户提供的道路系统有自己的收费方式。有些人会允许使用现金并将其插入硬币收藏家。有些人允许信用卡。有些人在您进入道路系统时发出票，然后在退出时支付通行费。今天，大多数收费公路都采用了像E-Z Pass这样的自动支付系统，但并非全部。该公司认为收费站的销售正在蓬勃发展，并希望有一个软件系统可以处理当前和未来存在的所有可能的变化，而无需大量的重写代码。这是作为公司的首席开发人员/架构师给您的。
我知道有不同类型的门，支付机制，一些传感器和上面提到的其他东西。我还试图说明客户在从“这家公司”订购收费站时可以做出的变化。
我正在创建一个UML类图，它显示了关键组件以及它们之间的关系，但我不确定要使用的设计。我认为适配器模式是一个很好的选择吗？听起来不错吗？
我已经创建了基本的起始类，如Client，Tollbooth和Gate。我知道Client知道Tollbooth和Tollbooth知道Gate，但我是如何进行接口和具体方法？
您将设计的软件将操作工具台，该工具台由许多非常不同类型的互连组件组成，例如门，门控制器，传感器，“手动”控制器，票务系统，信用卡读卡器，硬币收集器。
在这方面，Customer与此设计无关，因为该软件将与收费站设备配合使用，并不关心不同的客户。
叙述很好地解释了它：
（...）没有关于门的软件或系统中任何其他组件如何工作的标准。也就是说，它们没有标准接口。
我们知道展位的配置可能会有很大差异：
因此关键是构建一个系统，让不同的组件使用众所周知的界面协同工作。
首先，您必须了解在设计师的现实生活中，您不会查看问题并浏览模式目录以选择正确的模式。设计模式仅在存在常见问题且提出的解决方案符合其他设计约束时才有用。
幸运的是，在这里，我想到了两种设计模式：
我不知道你的作业设计有多现实，也不知道你的专业水平是多少：
Sensor），这允许专门化具体类（例如MotionSensor）。如果您处于初级水平，请选择此项。以下是找到合适的技术解决方案（具有设计模式）而不是尝试为给定要求设计完整解决方案的示例。
该方法的高概述是重新制定要求以强调技术方面。
首先跳过像There are different types of gate controllers; some that come with gates that open and close automatically...这样的细节并注意共同点
两者都可以被视为行为
第二步，逐步添加细节
从第二步开始很容易注意到，这可能是第一步中确定的行为的不同实现。在第二步中，可以注意到其他一些行为
继续添加详细信息并检查新行为，直到所有细节都用完为止
第3步确定系统中涉及的模型（包含详细信息）
第四步确定行动
第五步将模型和动作放在一起
Payment对象TransactionProcessorTransactionProcessor使用Payment对象中的详细信息处理事务并返回事务的详细信息（状态ok / nok）Signal打开大门GateControllerGateController打开了GateSignalSensor产生密切的SignalGateController关闭了Gate请注意，在第5步中没有关于如何处理事务以及如何生成信号的详细信息，因为这些是实现细节。在这一步骤中，应该细化抽象（例如在Java中的接口）
第6步添加实现细节（第5步中定义的抽象的实现）
行为
需要建模检查behavioral design patterns列表。
其他有用的设计豹（非行为）可能是Observer用于实现传感器门（观察传感器和处理门）
这种解决方案可以在需要时通过现有行为的新实现（处理门的不同方式或处理支付的不同方式或要使用的新传感器）轻松扩展，而不会影响现有的