面试中的OOP设计问题 [英] OOP Design Problems in Interviews

问题描述

我是一名拥有 2 年经验的软件开发人员.我参与了几个小"模块的设计和开发.

I am a software developer with an experience of 2 years. I have been involved in design and development of several "small" modules.

我最近一直在接受技术面试.我被要求对各种问题进行建模(例如 Apple Genius 推荐系统等).到目前为止，我的专长是开发相对较小的模块.我想提一下我如何处理手头的设计问题:

I have been giving technical interviews lately. I have been asked to model design of various problems (for example Apple Genius Recommendation System etc). My expertise so far has been in developing relatively small modules. I want to mention how I approach design problems in hand :

(1) 识别最重要的用例.

(1) Recognize most essential use case.

(2) 进行动态建模(如协作图)以基于行为对系统进行建模

(2) Do dynamic modelling (like collaboration diagram) to model system on basis of behavior

(3) 根据步骤 2 中的动态建模绘制类图.

(3) Draw class diagram based on dynamic modelling done in step 2.

(4) 找出更多用例并迭代此过程.

(4) Find out more use cases and iterate this process.

(5) 当我满意时，我会请我的同事们来评价一下.

(5) When I am satisfied, I ask my peers to have a review it.

尽管到目前为止我在我的项目中做得足够公平，但面试官对这种方法并不满意.我在为一个大问题建模时是否遗漏了什么?

Though I've done fair enough in my projects so far, but interviewers are not pretty happy with this approach. Am I missing something as I am modelling for a big problem?

感谢您的指点.

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

P.S. : I don't start with class diagram because I find very centralized architecture by doing so, while dynamic modelling helps me to decentralize the design.

推荐答案

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

Did you have been asked for high level model (module) design or low level model design? Tackling into a big problem or domain for high level model design is a good idea, since for low level model design usually takes smaller problem or domain.

通常需求/问题来自提问者(用户/采访者)，因此我们不再需要定义业务需求.但是我们仍然需要设计系统.

Usually the requirement / problem comes from the asker (user / interviewer) so we don't need to define the business requirement anymore. But we still need to design the system.

高级模型

我对Apple Genius Recommendation System"不太熟悉，所以我将使用不同的问题类比，即常见的销售点问题.对于高级模型，您将定义整个系统.通常大约:

I'm not quite familiar with "Apple Genius Recommendation System" so I will use different problem analogy, that is the common Point Of Sales problem. For the high level model, you will define the entire system. Usually about:

• 订购
• 提交订单
• 首付
• 货物交付
• 返回

那是所有高级模型/模块.如果有人问我如何实现模型，我将执行以下步骤:

That is all high level model / module. If i'm being asked by how I can achieve the model, here is the steps that I will do:

1. 定义用户和系统之间的标准用例
2. 将用例倒入一些协作图表中，例如丰富的图片(或任何熟悉的东西)

3. 定义异常用例.如果可以轻松定义异常，请立即将其放入模型.如果不是，请用案例例外标记模型，以便与业务团队进一步讨论

1. Define the standard use case between user and systems
2. Pour the use cases to some collaborated diagram such as rich picture (or anything familiar)

3. Define the exceptions use cases. If the exceptions can be defined easily, put it immediaetly to model. If not, mark the model with the case exceptions to be further discussed with business teams

一些用例例外可能是更改承诺订单、预付款后更改承诺订单、取消已付款订单、商品缺货等.

some use case exceptions can be changing committed order, changing committed order after down payment, cancelling payed order, goods out of stock, etc.

重复这个过程.通常第 3 步可以变成第 1 步(例外可以/将是另一个用例)

Iterate the process. Usually step 3 can become step 1 (the exception can / will be another use case)

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

for example the changing committed order can be a use case, since the change of occuring is high.

当第三个完成没有额外用例异常(所有用例已经处理)时，通常我添加值附加操作.

When the 3rd is completed without additional use case exceptions (all use case has been handled), usually I add value-additional operations.

这些操作可以是通知(电子邮件/屏幕)、历史数据维护、提醒、错误处理等.有些操作也可以是另一个用例，所以也许你需要迭代到第一.

Those operations can be notification (email / on-screen), historical data maintenance, reminder, error-handling, etc. Some operations can be another use case as well, so maybe you will need to iterate over to no.1.

一些例子也许当您在首付结算过程中出错时，您可能需要另一个用例来手动输入首付数据.或者您可能需要在另一个系统中维护提醒系统.

Some example maybe when you get error during down payment settlement, maybe you will need another use case to input the down payment data manually. Or maybe you will need to maintain reminder system in another system.

转向低级模型

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

For additional information, I usually use state diagram for use cases / functionality, such as order state.

低级模型

低层模型将从高层解决较小的问题.简单地说，您从高层(可能是排序)获取一个用例，然后开始从中设计低层.我通常不会先定义类图，而是使用某种形式的序列图.以下是一些原因:

Low level model will tackle smaller problem from high level. Easily said, you take one use case from high level (maybe ordering) and begin designing low level from it. Rather than defining class diagram first, I usually tackle with some form of sequence diagram. Here is some reasons why:

1. sequence 为您提供有关获取输入、获取数据和提供响应的并发视图
2. 它很好地描述了与其他系统(如数据库和网络服务)的关系
3. 它可以为您提供有关入口点或界面的图片，其中对于您的应用程序的基本架构非常有用
4. 您可以以此为基础构建您的类图，并在序列设计而不是类图期间轻松找到陷阱

然后我会继续系统状态图(可编辑、可查看等).

Then I will continue to system state diagram (editable, viewable, etc).

最后继续数据库设计和类图.

为什么最后一步是类图?

类图(和数据库设计)非常依赖于你的整个过程.并发如何发生、通知、外部系统交互等都会影响接口和类图的设计.它也是与您的代码库最接近的设计.

Class diagram (and database design) is very dependent on your entire process. How concurrency occurs, notifications, outer system interactions, etc can affect the design of interfaces and class diagram. It is also the nearest design with your codebase.

希望对您有所帮助，这完全是我的经验和意见.

Hope this help and this is entirely my experience and opinion.

这篇关于面试中的OOP设计问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！