您如何在OOP中进行班级设计？

当我尝试设计OO解决方案时，通常使用CRC建模，其中列出了类名（名词），它们的作用（动词）以及它们与其他类的协作方式。

关于此名词-动词方法，此博客有以下要说的话

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

我的问题是，使用OO方法是否存在更好的建模技术？

公平地说，他确实在该声明中添加了“有趣”。

时至今日，我的确倾向于使用“名词和动词”方法对系统进行建模，但是多年来，我发现TDD教会了我们这种方法将您的注意力吸引到了错误的事物上。从这个意义上说，博客作者是有观点的。但是，我不确定这是错误的方法，而不是我们的思维方式。

如果您想在这里尝试一些挑战，请停止阅读并尝试使用英语为Monopoly游戏建模，然后回到此处。

我怀疑这种诱惑将是立即查看我们经常互动的对象-棋盘，空间，卡片，骰子，棋子-但这并不是逻辑的主要内容。这些对象大多数都是愚蠢的。数据，如果您愿意。

但是，一旦开始编写测试，您就会意识到哪个对象是迄今为止任何游戏中最重要的：规则。

还记得您刚开始玩游戏时曾阅读过的一小张纸，直到有争议时才与之互动？电脑版本不能以这种方式运行。玩家尝试做的每件事，计算机都会参考规则，看看是否允许他们这样做。

考虑一下时，您会执行相同的操作，但是由于阅读基于纸质的规则需要花费时间，并且您的大脑具有合理的缓存系统，因此您必须脑海中查阅这些规则。计算机可能会发现再次读取规则同样容易-除非将规则存储在数据库中，在这种情况下，它也可能会缓存它们。

这就是TDD在实际驾驶设计中如此受欢迎的原因。因为它倾向于将您的思考过程迅速带到正确的位置：

当我认为自己要为《大富翁》游戏编写一些测试时。我可能会看一下我的场景并尝试找到对象。所以，我们有这些作品。我将为此编写一些测试。

也许我会有一个基类MonopolyPiece，每种类型的作品都将从中衍生出来。我将从DogPiece开始。第一次测试...啊。实际上，这里没有逻辑。是的，每个部分的绘制方式都不同，所以我可能需要一个DogDrawer，但是在充实游戏时，我只想在屏幕上写“ D”。最后，我将为UI增添趣味。

让我们找到一些实际的逻辑进行测试。这些房屋和酒店很多，但它们不需要测试。钱，没有 财产卡，不。等等。即使板子不过是一个状态机，它也不包含任何逻辑。

您会很快发现自己手上还有三样东西。机会和公益金卡，一对骰子和一套规则。这些将是设计和测试的重要部分。

当您写出名词和动词时，您看到了吗？

实际上，在罗伯特·马丁（Robert Martin）的《敏捷原则模式和实践》中有一个很好的例子，他们尝试使用TDD充实保龄球计分卡应用程序，并发现他们认为是显而易见的类的所有东西，根本不值得去理会。

我从未发现这样的方法对我有用。实际上，我发现使用它们只会使我更加困惑。查看Robert C. Martin的Coffee Maker，我也不认为他也使用这种方法。

立即困扰我的一件事是该人在您链接到的CRC文章中所采用的解决方案。无论如何，客户/订单协作并不是我认为值得的事情。在该模型中，没有什么特别值得关注的客户值得获得阶级地位的。成为“客户”的唯一有趣的事情是，有一个或多个与该Person相关的订单。

大学模式也。学生和教授之间可以做很多事情，应该分享。此外，当您要教授某个课程时，会发生什么情况（大学校园通常免费提供此课程）？

我想这可能是值得的实践，是设计工具包中的一个元素。我认为这至少不是您设计方法的唯一方法。坦率地说，我发现通用性/差异分析方法更有用。在我看来，非常紧密地建模了我们在日常生活中对抽象进行分类的工作。

编辑：只读了第二个博客的一半，我不得不说我非常同意。我将不得不阅读其余内容，看看它在学习方面提供了什么。

我的意见是，在编写代码时应添加（和删除）类以分离关注点并减少依赖关系。流利的设计模式可能是一个很好的选择，可以看到重构和简化的可能性。

根据我的经验，类通常不会整齐地归入名词/动词类别，而是最终会混合使用名词/动词类以及不同的模式类（工厂，单例，策略模式等）和其他管理器类解决您的应用程序的一个方面。

关键是您的目标应该是能够查看一个类并推断出它的作用，并仅通过更改该类来对其进行修改。您的应用程序方面的代码越多，在各个类中分布的越多，则变得难以遵循，管理和扩展它。