在规划架构时，应该使对象尽可能通用吗？

Question

我正在努力提高我的技能，在规划干净，模块化项目与最低限度的耦合。最好保持对象尽可能的泛化吗？

如果是这样的话，在设计架构时，我是否应该尝试避免任何陷阱呢？

Answer 1

使每一个事物都是通用的是愚蠢的。

把每一件事都说清楚是愚蠢的。

每个对象都应该有一个名称，以确保在里面发现的东西不会令人惊讶。它应该明确什么属于它，什么属于外部。否则会有人把它弄得乱七八糟。里面应该看起来像你的银器抽屉。不是你的垃圾抽屉。它可以接受多条消息(有很多方法)，但是它的工作应该集中在一个想法上。它应该有一个单一的责任。当您更改它所处理的一个设计决策时，它应该是您需要进行更改的唯一地方。

它的共性或具体程度取决于它离投入或产出有多远。任何类型的IO (文件、DB、GUI、web、控件等)都必须是特定的，并且经常发生变化。任何远离IO和接近高级别的策略都将更加通用和稳定。

通过忽略可以被推入不同兄弟对象的特定情况来保持特定，而不是过度设计当前的对象来处理每一种情况。

愿意保持共性，负责地处理各种情况，完全脱离对象，交给协作者来处理，而不必让这个对象处理他们的细节。

那怎么知道什么时候太多了？

当对象的职责变得不明确时。对象的使用应该是显而易见的。如果一半的对象在抽象的一个层次上，另一半在另一个抽象的层次上，那么就会有一种倾向，用额外的逻辑来包围它的使用，让它维持生命。当对象设计得很好时，使用代码将是简单而干净的。

始终关注如何使用对象。我通常是通过先编写使用代码来设计的。这样做，并控制它是多么抽象，将自然脱落。

Answer 2

这取决于你所说的泛型是什么意思。

如果你的意思是泛型的“可以处理任何事情”，那就不是。特别是在设计阶段，你不知道事情会如何改变。这很好，只是现在不要试图解决所有这些问题。

如果你的意思是泛指“做一件事，忽略上下文”，那么是的(适度)。如果您在文件中使用文本，可能不要将其绑定到特定的文件路径。如果所有真正需要的东西都是文本，也许根本不要把它绑定到文件上。

这一切都是关于预测可能发生的变化并对其进行解释。你不需要解决那些还不存在的问题，但是现在花点时间是值得的，这样当你终于发现事情需要改变的时候，你就不会束手无策了。