Oop 采访中的面向对象设计问题

我是一个有两年经验的软件开发人员。我参与了几个“小”模块的设计和开发

我最近一直在接受技术采访。我被要求对各种问题进行模型设计（例如Apple Genius推荐系统等）。到目前为止，我的专长是开发相对较小的模块。我想提及我如何处理手头的设计问题：

（1） 识别最基本的用例

（2） 根据行为对系统进行动态建模（如协作图）

（3） 根据步骤2中完成的动态建模绘制类图

（4） 找出更多用例并迭代此过程

（5） 当我感到满意时，我会让我的同龄人对它进行回顾

虽然到目前为止，我的项目做得很公平，但面试官对这种方法不太满意。当我为一个大问题建模时，我是否遗漏了什么

如果有人给我指点，我将不胜感激

---

注：我不从类图开始，因为我发现这样做非常集中的架构，而动态建模帮助我分散设计。

从您的问题中我得到的信息是，您要求的是一个“模型”，而不是“方法论”或“过程””正如你所概述的那样

因此，他们所要做的就是设计（可能使用UML）一个场景，让Apple Genius推荐系统能够处理各种问题。提示：如果是这种情况，那么设计的主要部分就是要有一个名为问题的接口，其中包含与问题相关的核心接口方法。例如，getSeverity、getDescription、GetDateReport、getDateSolved等。当然，他们需要与此接口协作的其他类来完成设计

---

我希望以上内容对您有所帮助。

我认为您的方法可能会失败。我还想提到如何捕捉这些信息。

我想说的是，也许你应该给出一个总体的观点/概述，然后再深入了解。就像您给出的“Apple Genius推荐系统”的例子一样，我认为您应该从总体设计（系统的总体情况）开始，以确定系统的适当架构，例如确定需要哪些组件、哪些协议等。您需要识别组件、连接器、，以及论文的结构。然后，您可以通过建议模式和工具开始深入研究。最后，使用场景、用户案例等验证架构。

是否要求您进行高级模型（模块）设计或低级模型设计？解决高级模型设计的大问题或领域是一个好主意，因为低级模型设计通常需要较小的问题或领域

通常需求/问题来自询问者（用户/面试官），因此我们不再需要定义业务需求。但我们仍然需要设计系统

高级模型

我不太熟悉“Apple Genius推荐系统”，所以我将使用不同的问题类比，即常见的

销售点问题。对于高级模型，您将定义整个系统。通常是关于：


订购
委托单
首期付款
货物交付
返回

这些都是高级模型/模块。如果有人问我如何实现该模型，我将采取以下步骤：

定义用户和系统之间的标准用例
将用例注入到一些协作图中，如rich picture（或任何熟悉的东西）
定义异常用例。如果可以轻松定义异常，请立即将其放到模型中。如果没有，则在模型上标记案例例外，以便与业务团队进一步讨论

一些用例异常可以是更改提交订单、更改预付款后的提交订单、取消已付款订单、货物缺货等

迭代该过程。通常步骤3可以变成步骤1（例外情况可以/将成为另一个用例）

例如，更改提交顺序可以是一个用例，因为发生的更改很高

当第三个用例在没有其他用例异常的情况下完成时（所有用例都已处理），通常我会添加
值附加操作

这些操作可以是通知（电子邮件/屏幕上）、历史数据维护、提醒、错误处理等。一些操作也可以是另一个用例，因此您可能需要迭代到第1位

例如，当您在首期付款结算过程中出现错误时，您可能需要另一个用例来手动输入首期付款数据。或者，您可能需要在另一个系统中维护提醒系统

移到低级模型

对于其他信息，我通常使用状态图来表示用例/功能，例如订单状态

低级车型

低层次模型将从高层次解决较小的问题。简单地说，您从高层（可能是订购）获取一个用例，然后从中开始设计底层。我通常使用某种形式的。以下是一些原因：

sequence为您提供了关于获取输入、获取数据和给出响应的并发视图
它很好地描述了与其他系统（如数据库和Web服务）的关系
它可以为您提供有关入口点或界面的图片，这些图片对于应用程序的基本架构非常有用
您可以从中创建类图，并在序列设计过程中而不是在类图中轻松找到陷阱
然后我将继续系统状态图（可编辑、可查看等）

最后，我将继续