把东西变成物体我应该有多疯狂？答案

【问题标题】：How crazy should I get with turning things into objects?把东西变成物体我应该有多疯狂？
【发布时间】：2011-04-04 16:48:04
【问题描述】：

我还是 OOP 的新手，我最初认为它是在对象内部抛出大量程序化的代码，并认为我已经完成了我的工作。但由于过去几周我花了很多时间思考、阅读和编码（以及查看好的代码，这是一个被严重低估的资源），我相信我开始掌握不同的前景。一旦你开始着手，这实际上只是一个清晰、简单和组织的问题。

但现在我开始将事物视为对象，而不是黑白分明的对象。例如，我有一个解析器，通常解析器会返回一些我必须处理的字符串。但是它有一个特殊的情况，它必须返回一个数组，该数组中的内容以及它的格式设置有专门的规则。这仅相当于两行代码加上一种代码方法，但这段代码在我看来并不完全适合 Parser 类，我想把它变成它自己的“ActionArray”对象。

但它会走得很远吗？ OOP 是否已成为让我像钉子一样看待一切的锤子？将事物变成对象是否可能走得太远？

【问题讨论】：

标签： ruby-on-rails ruby oop

【解决方案1】：

这是你的决定，但是你应该把对象看作是现实生活中的对象。

以汽车为例。你可以用不同的物体来描述一辆汽车：

引擎
轮子
机箱

或者你可以用一个物体来描述一辆汽车：

引擎

你可以keep it simple and stupid或者你可以将依赖分散到不同的对象。

【讨论】：

火花塞是物体吗？就可读性而言，看到对象是非常小的对象并且不是 100% 必要的对象，是否会令其他人烦恼？
发动机可以有火花塞，火花塞可以有单一方法giveSpark()。你不会给引擎一个方法giveSpark()，是吗？这是我的意见。对象通常应该只有一个任务。
是的，我想我不会走得太远。发动机可以计算火花塞点火的频率，但它不应该。谢谢。
在 OOP 系统中有很多与“现实生活对象”不同构的对象示例。这是一个有漏洞的（如果经常有用的话）抽象。

【解决方案2】：

作为一般准则，我认为芝麻街说得最好：当“其中一个与其他不同”时，您需要一个新对象。

聆听您的代码。如果它告诉您您的对象正在受到非必要状态和行为的污染（因此违反了“单一责任原则”），或者您的对象的一部分具有与其他部分不同的变化率，并且以此类推，它告诉您您缺少一个对象。

尽可能做最简单的事情。当这不再有效时，做下一个最简单的事情。等等。一般来说，这意味着系统倾向于从更少、更大的对象转移到更多、更小的对象；但并非总是如此。

有很多很好的面向对象设计的资源。除了已经提到的那些，我强烈推荐 Kent Beck 的 Smalltalk Best Practice Patterns 和 Implementation Patterns。他们分别使用 Smalltalk 和 Java 示例，但我发现这些原则可以很好地转化为其他 OO 语言。

【讨论】：

我同意。 Smalltalk Best Practice Patterns 确实是用词不当。是的，它使用 Smalltalk 作为示例，但它确实是编程最佳实践模式。 Implementation Patterns 或多或少是 Smalltalk Best Practice Patterns 的第 2 版，因此，尽管它使用 Java，但它确实与语言无关。 Kent Beck 的 Java 代码最终看起来像带有花括号的 Smalltalk，这很容易转换成 Ruby。
顺便说一句：我隐约记得你在一次演讲中提到你正在考虑做一个 Ruby 版本的 SBPP。不管结果如何？它是否被 Gregory Brown 的 Ruby 最佳实践 淘汰了？
@Jörg 当我离开 Hashrocket 时，该项目基本上停滞了。不过我喜欢格雷格的书。

【解决方案3】：

设计模式是你的朋友。一个类很少存在于真空中。它与其他类交互，并且类耦合在一起的机制将直接影响您将来修改代码的能力。由于类设计不佳，您在一个类中所做的更改可能会波及其他类并强制更改其他类，从而导致您不得不更改其他类等。

设计模式迫使您思考类之间的关系。例如，您的 Parser 类可能会选择实现 Strategy 设计模式来抽象出解析机制。您可能决定将 Parser 创建为模板设计模式，然后让 Parser 的每个实际实例完成模板。

关于设计模式的原书（Design Patterns: Elements of Reusable Object-Oriented Software 非常出色，但如果您是 OOP 新手，阅读内容可能会很密集且令人生畏。一本更易于阅读的书（专门针对 Ruby）可能是Design Patterns in Ruby，它有一个不错的介绍设计模式，并讨论 Ruby 实现这些模式的方式。

【讨论】：

【解决方案4】：

面向对象编程是一个非常棘手的工具。今天很多人都陷入了同样的冲突，忘记了 OOP 的基本目的，即提高代码的可维护性。

您始终可以就您未来的 OO 代码可重用性和可维护性集思广益，并自行决定这是否是最佳方式。看看这个有趣的研究：

Potok, Thomas; Mladen Vouk, Andy Rindos (1999). "Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment"

【讨论】：