如何解决航空公司预订系统 UML 问题 - 这些方法属于哪里？
我正在准备软件工程面试，并发现在面试中了解面向对象设计是件好事。在我查看的所有 UML 图示例中，我无法弄清楚这些方法所属的位置。例如，以下是航空公司预订系统面向对象设计课程中的 UML 图之一。
我对这张图的主要问题是：
在这方面做了一些工作后，我总是有一个具有 addFlightSchedule() 方法的服务类（如 FlightScheduler 类），而 Flight 对象只是包含适用于航班的属性/方法的对象。那么，在面试时这样设计课程是否正确？为什么所有在线 UML 图都将服务（操作）方法作为类本身的一部分？
解决方法
这是一个域模型，它讲述了一些关于域逻辑的信息。这不是系统应该如何工作的实现模型：
1.飞行
在此模型中，战斗代表两个机场之间的航线。和飞行公司一样，火车公司喜欢规律性。因此，同一航线（航班）可以定期运行（这里是一周中的一天或几天。或者，它可以是仅在特定日期运营的包机，因此航班可以没有，一个或多个自定义日期。
因此在这样的模型中，在战斗中找到 addSchedule() 是合乎逻辑的，因为这样可以更详细地描述飞行。所以这绝对是预期飞行行为的一部分。如果任何其他类会这样做，您将创建一个依赖项和一个特定实现的耦合。
这里唯一令人惊讶的是，CustomeSchedule 和 WeekSchedule 不是 FlightSchedule 的特化。
2.机场
了解哪些飞机应该到达和离开机场以及何时离开是机场的明确职责。在每个机场，我都可以查看预计到达和离开的列表，以及有关航班的一些信息。
这就是 getFilghts() 的意义所在：由机场将这些信息传递给只知道机场的其他班级。如果这个模型不提供这种机场方法，每个乘客就必须知道全世界所有的飞机，并找出从机场起飞的飞机。这会破坏封装，因为乘客将不得不了解关于世界的太多细节。
话虽如此，在现实世界中，您可能希望此方法将特定数据作为参数：同样，不能过滤航班并找到适合给定日期的航班。
最少知识原则
该模型旨在充分封装对象，使每个对象不必知道如何关联所有其他对象。
遵守 principle of the least knowledge 会很累，所以每个类都必须知道尽可能少的类。特别是，乘客了解机场和飞机。他们原则上不必了解日程安排的工作原理。
这个模型显然是一种简化，也是不完美的。例如，不清楚如何创建航班实例。但也许你的书在一个专门的章节中解决了这个问题和不同的选择；-)
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
