OOP 有什么规则吗？答案

【问题标题】：Are there any rules for OOP?OOP 有什么规则吗？
【发布时间】：2010-09-28 19:37:33
【问题描述】：

最近听说OOP(Java)有9条规则。我只知道抽象、多态、继承和封装四个。 OOP 还有其他规则吗？

【问题讨论】：

标签： oop rules solid-principles package-design

【解决方案1】：

您正在寻找的似乎是Principles of Object-Oriented Design。

总结自Agile Software Development Principles, Patterns, and Practices。这些原则是数十年软件工程经验来之不易的产物。它们不是单一思想的产物，而是代表了众多软件开发人员和研究人员的整合和著作。尽管它们在这里作为面向对象设计的原则提出，但它们确实是长期存在的软件工程原则的特例。

SRP 单一职责原则一个类应该只有一个改变的理由。

OCP 开闭原则软件实体（类、包、方法等）应该对扩展开放，对修改关闭。

LSP Liskov 替换原则子类型必须可以替换它们的基本类型。

DIP 依赖倒置原则 抽象不应该依赖于细节。细节应该取决于抽象。

ISP 接口隔离原则 不应强迫客户依赖他们不使用的方法。接口属于客户端，而不属于层次结构。

REP 发布-重用等效原则 重用的颗粒就是释放的颗粒。

CCP 共同闭合原则 包中的类应该针对相同类型的更改关闭在一起。影响已关闭包的更改会影响该包中的所有类，而不会影响其他包。

CRP 通用重用原则 包中的类可以一起重用。如果你重用包中的一个类，你就重用了它们。

ADP 无环依赖原则 依赖图中不允许有循环。

SDP 稳定依赖原则 取决于稳定的方向。

SAP 稳定抽象原则 一个包应该是抽象的，因为它是稳定的。

【讨论】：

第一个链接挂起。幸运的是，还有其他来源，即wiki.c2.com/?PrinciplesOfObjectOrientedDesign。这个答案将类设计原则、包内聚原则和包耦合原则放在一起。

【解决方案2】：

不确定任何规则。所有这些提到的东西对我来说更像是面向对象的范例。我们遵循的建议很少，例如，

关注点分离
每个班级的单一职责
组合优于继承
接口编程
加上 Billybob 提到的所有内容，已经

【讨论】：

【解决方案3】：

这些OO原则直接来自Head First Design Patterns：

封装变化的内容
编程到接口，而不是实现
偏好组合优于继承
一个类应该只有一个改变的理由（单一职责原则）
子类型必须可以替换它们的基（Liskov 替换原则）
类应该对扩展开放，对修改关闭（开放-封闭原则）

【讨论】：

【解决方案4】：

这些是概念，而不是规则。真的没有规则，只是要做出决定，有些设计比其他设计好，有些比其他设计好得多:-)

虽然有很多指导方针 :-) 有些是特定于语言的（C++ 中充斥着它们），有些是特定于 OO 的。不过太多了，无法列出:-)

在我的脑海中，重要的是：

松耦合，高内聚
编写可测试的类，供您测试
谨慎使用继承，仅在有意义的地方使用（首选组合）
尽量坚持开/关原则。
（最重要的）亲吻

大量扩展和添加:-)

编辑：我应该补充一下，您列出的规则不是 OO 独有的

【讨论】：

不是你的:)。顺便说一句，我们将如何在非 OO 语言中练习继承、多态等。我相信这 4 个都是 OO 范式。

【解决方案5】：

根据实用程序员 - 规则是：

保持干燥（不要重复自己）
保持 SHY（确保您的类具有高内聚和低耦合）
并告诉其他人（关注点分离）

http://media.pragprog.com/articles/may_04_oo1.pdf

【讨论】：

【解决方案6】：

OOP 没有“规则”。

有 4 个语言属性可以使语言面向对象或不面向对象（这些是您在问题中列出的内容）。

其余的材料都有指导方针。我读过的最好/最有用的指南是GRASP

许多建议对于外行（非 CS 专业的学生）来说并不容易理解。我认为 GRASP 务实且平易近人。

我认为 GRASP 很好，因为它在名称中暗示了 OO 中最关键的部分 - 职责分配（针对对象而不是程序员）。

其他一切都源于的两个最关键的 GRASP 概念是耦合和内聚。这两个概念/原则推动了所有其他模式和方法。

顺便说一句 - 我刚刚采访过你吗？你把问题抄错了……

【讨论】：