您将如何评估面向对象的设计技能？[关闭]

什么样的见解或问题会引导您确定一个人的OOAD技能。

您可以展示一些简单问题的OO设计，并讨论它的作用，优缺点，是否足够灵活，可以改进什么以及如何进行。

如果您需要继续进行讨论，请询问此人对代码某些方面的看法，而不要提出主要问题。

重要的是要记住讨论是重要的，而不是您事先知道答案。任何体面的开发人员都应该能够指出一些您之前从未想到的代码。

与人讨论开放式设计问题。查看他/她如何建立系统模型，提出什么样的问题，设计如何响应新信息而变化。

史蒂夫·耶格（Steve Yegge）在他的一篇博客文章中提到的一个很好的例子是，要求人们提出XML的对象模型。

对所有最流行的设计模式都有很好的了解，可以证明候选人实际上正在寻找解决其设计问题的方法。

能够讨论它们并知道何时应用它们，这很好地表明了他理解它们。

询问他过去的经历中的用法也可能会有所帮助。

不要进行词汇测验。“定义继承”或“面向对象设计的3个特征”是一个问题，不会告诉您有关个人技能的任何信息，而只是告诉您自从上次阅读教科书以来的时间。我遇到了几位伟大的程序员，他们每天都使用这些技能，但是如果要求给出正式定义，他们会感到窒息。

将要求他写下房间或任何其他虚拟实体的业务对象，类和接口/方法

如果可能，请索取示例代码。

否则，找到一些过程代码作为示例（或一些设计欠佳的OO代码），然后询问他们如何重新设计，推广和改进它。确保程序具有额外的上下文，以便重新设计可以有意义。

最终，您要测试的内容-设计-是主观的。因此，您的评估应该是开放式的，以便提供多种可能的好的解决方案，而不仅仅是一个解决方案。然后，考虑对需求的可能更改，这些更改将迫使接口发生更改：它们如何处理？

阅读《 Head First设计模式》一书。本书中的所有示例均始于面向对象的问题，而最终以“设计”模式结束。他们还说明了为什么某些OOP的概念会取得有限的结果，以及为什么某些比其他的要好。

即使是《设计模式》这本书，也充满了OOP的问题:-)

从简单开始：OOP到底是什么？

您可以从询问OOP的基本前提开始：抽象，多态性，继承和封装。深思熟虑的好食物，可以使他们热身。

给他们一个问题

接下来，向他们提出可能涉及模式的问题。不必命名或使用模式，但是如果他们在该领域有经验，他们的方法可能会产生一些效果。

也许是动态文本输入验证。您希望能够逐个字符地验证输入的字符，以查看它是有效的日期，时间还是ISO8601格式的日期和时间。每次按键，您都会获得输入字符串的副本，并且可以返回布尔值以指示文本是否至少以一种格式保持良好。请他们讨论并使用OO设计原则草绘设计。

等你聊完了

1. 控制器（触发变更事件并评估响应的东西），
2. 观察者（验证者响应变更事件），
3. 策略（每个验证器代表确定输入是否有效的另一种方式），

如果他们了解OOD，那么您将有一个很好的主意。

再次给他们同样的问题，但是这次要求不同的设计

现在，要求他们在不使用观察者模式的情况下重新设计系统（如果他们提到过）-他们可能选择采用责任链方法或命令模式。您并不在乎哪个，您知道他们对所涉及的原理有合理的了解。

即使他们不采用基于模式的方法，只是聆听他们试图将问题分解为相关功能的方法，也会产生您所追求的结果。

我倾向于选择一个现实世界的场景，这是任何人都熟悉的†，并要求他们标识实体；所涉及的演员；它们之间有什么相互作用；可以抽象出通用特征的地方；需要考虑哪些属性。

是的，您可以要求他们坐下来绘制UML，是的，您可以要求他们在一些OOP实施细节上搜索问题，以查看他们是否可以“开始运作”。

但是，雇主在团队中真正需要的是一种能够理解所涉及概念并可以将其应用到任何情况的思想。嵌入概念后，即可快速了解具体信息。

†熟悉度高，没有与代码帮助的联系：一家人早上使用浴室；做晚饭; 上班的公交路线; 汽车的组装。

似乎工作得很好，实际上只需要几秒钟：请他们设计对象模型。没关系的。这绝对是微不足道的。实际上，不要不必要地拖出测试，这可能是微不足道的。

如果他们写的第一件事是对象，那么他们对OO的理解已经领先于99％的同行。如果他们写的第一件事是一堂课，请请他们外出并派遣下一个候选人，然后考虑为什么将其称为OOP而不是COP。