OO软件设计原则答案

【问题标题】：OO Software Design PrinciplesOO软件设计原则
【发布时间】：2009-07-06 22:29:10
【问题描述】：

我非常喜欢 SOLID 和 DRY 等软件设计原则。面向对象软件设计还有哪些其他原则？

注意。我不是在寻找“评论你的代码”之类的答案，而是寻找像 Uncle Bob 讨论的 OO 设计原则。

【问题讨论】：

需要标记为社区wiki。
这是一个：stackoverflow.com/questions/813534/…。看起来它实际上可能是重复的。有很多这样的。刚刚点击了“ooo”标签。
@John 在写这个问题之前，我读了一大堆 SO 答案。大多数其他问题都想了解有关使用特定原则的信息，但我找不到关于“存在哪些软件原则”的问题，这就是我问它的原因。
@Jon 我怎样才能把这个问题变成一个社区维基？
@hasen 单击 Bob 大叔 (butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod) 的链接或阅读此处的 PDF lostechies.com/blogs/chad_myers/archive/2008/03/07/…

【解决方案1】：

来自维基百科的相当全面的列表：

【讨论】：

【解决方案2】：

High Cohesion - 您正在设计的模块的职责有多集中。

Low Coupling - 模块依赖其他模块的程度。

【讨论】：

@Jason 我原以为高内聚和低耦合是由 SOLID 原理推断出来的
@Kane - 是的，你可能是对的。 S 和 D. 可能是同一事物的不同名称。（直到现在我才听说过 SOLID 并且学习了内聚和耦合，这就是我发布它的原因。）感谢您指出这一点。

【解决方案3】：

KISS

【讨论】：

【解决方案4】：

选择组合而不是继承，是一个。

许多人，尤其是那些刚接触 OO 的人，会在他们真正需要的是使用组合时开始扩展类。真的，如果您应该问自己，新的B级是A级吗？如果没有，那么你不应该延长。

例如，假设我有一个Person 类，一个Car 类，我想创建一个名为DrivenCar 的新类。一个天真的实现会说（假设我们有多重继承）

class DrivenCar extends Person, Car  { ... }

DrivenCar 是 Person 的一种吗？不，所以它不应该扩展 Person。 DrivenCar 是汽车吗？是的，所以扩展是有意义的

使用组合，实现看起来像

class DrivenCar extends Car {
    private Person driver;
}

【讨论】：

【解决方案5】：

GRASP 模式。是的，它们看起来相当微不足道。更像是提炼出其他更复杂的模式所展示的核心品质。

【讨论】：

【解决方案6】：

YAGNI

【讨论】：

【解决方案7】：

界面。大多数设计模式都基于接口和实现的分离。

【讨论】：

【解决方案8】：

当您的 API 预计会增长时，请使用抽象类而不是接口。在接口中添加新方法需要更改所有实现它的类。

【讨论】：