OOP：在哪里停止抽象答案

【问题标题】：OOP: Where to stop AbstractingOOP：在哪里停止抽象
【发布时间】：2008-10-19 07:46:44
【问题描述】：

您在哪里划定界限以停止进行抽象并开始编写理智的代码？有大量“企业代码”示例，例如十几个文件的“FizzBuzz”程序……即使是诸如 RTS 游戏之类的简单程序也可能具有以下内容：

class Player {} ;/// contains Weapons
class Weapons{} ;/// contains BulletTypes
class BulletType{} ;///contains descriptions of Bullets 
class Bullet{} ;///extends PlaceableObject and RenderableObject which can be placed/drawn respectively
class PlaceableObject{} ;///has x,y,z, coords
class RenderableObject{} ;///an object with a draw() command
class MovingObject{}; ///an object with a move() function

等等......它可能会变成一场噩梦。这可以被拉到它的逻辑极端，就像函数式编程可以被拉到一个极端，你可以创建一种只有变量、函数应用程序和匿名函数定义的语言（尽管我必须承认这稍微更优雅）......

关于这个话题有什么明智的建议吗？

【问题讨论】：

标签： language-agnostic oop

【解决方案1】：

YAGNI（你不需要它）。不要创建你看不到立即使用或没有合理理由的抽象。这样一来，您就拥有了一件可能变得更复杂的简单事物，而不是您努力使之变得更简单却失败了的复杂事物。
确保抽象有意义。如果它们离现实太远，太难以证明……算了吧。
让解决方案感觉自然。工作直到它完成。那么对于一个不熟悉的人来说，解决方案应该看起来如此明显，以至于他尖叫“你怎么能做得不同？”。
不要试图预测未来。你不能。如果你尝试覆盖所有 10 种可能的情况，你很快就会发现第 11 种甚至更多，而且由于之前的 10 种，实践中没有遇到过，因此实施起来会更加困难。 让它变得简单且易于适应。软件需要改变，但易于适应（敏捷性）通常比尝试预先涵盖所有可能的情况要好得多。

【讨论】：

“让解决方案感觉自然。继续努力直到成功”——完美的规则！ +1

【解决方案2】：

也许这个问题应该是从哪里开始抽象。

你引用的例子是一个典型的例子，没有充分考虑对象实际上是什么，因为它们都几乎相同 - 并且可能会更好地表示为单个“游戏对象”。

我也避免按对象属性进行子分类。对于 StaticGameObject 和 DynamicGameObject 可能看起来很合逻辑，但可能通过容器放置更好地表示 - 即两个列表，一个用于静态对象，一个用于动态对象，因此允许其他逻辑定义动作，而不是对象本身负责控制它之外的东西范围。

有时很难计算出您想在一个对象中表示的一组事物所共享的内容 - 但值得一试。

【讨论】：

【解决方案3】：

我相信标准可以从抽象是什么的明确定义中推导出来。

您指的是面向对象编程范式中的抽象，您可以在其中使用三个原则：'abstraction' - 'encapsulation' - 'information hiding or visibility'。

抽象是选择对象的哪些属性与您的系统相关并且必须完全忽略的过程。

这意味着，抽象限制与您定义的概念（玩家、武器、子弹……）的数量无关，而是您选择放入的内容 /em> 那些概念。

它基本上是分类，您将只从一个概念考虑什么对您需要定义的服务有用。

所以 API 可能是开始编写健全代码的一个好标准，正如 Eclipse 程序所建议的那样：API first。 p>

确实，“好的 API 需要设计迭代”，这意味着您在问题中提到的对象列表将随着所需 API 本身的完善而完善。

另外，API 意味着具有明确定义的组件边界和依赖关系（如“核心 - 播放器 - 与 UI - RenderableObject - ”），这意味着您提到的非常详细的列表不能被视为一个冗长的列表概念，但必须从应用架构明确地分组到不同的功能范围（或功能组件）。

由于 API 的存在是为了满足客户的需求，因此您保留这些对象只是因为它们对客户有意义。其他对象应该在“内部”包中，并且永远不要被应用程序的任何其他部分直接引用。

考虑到这一点，@phjr advices 非常有意义；）

【讨论】：