面向对象的软件设计原则

StackOverflow https://stackoverflow.com/questions/1089504

题

我是软件设计原则的忠实粉丝，例如 坚硬的 和 干燥. 。OO 软件设计还存在哪些其他原则？

笔记。我不是在寻找“评论你的代码”之类的答案，而是在寻找面向对象的设计原则，例如 鲍勃叔叔.

有帮助吗？

解决方案

维基百科上有一个相当全面的列表：

http://en.wikipedia.org/wiki/List_of_software_development_philosophies

  • 敏捷软件开发
  • 敏捷统一流程 (AUP)
  • 行为驱动开发（BDD）
  • 预先大设计 (BDUF)
  • 布鲁克斯定律
  • 大教堂和集市
  • 编码并修复
  • 建构主义设计方法（CDM）
  • 牛仔编码
  • 晶莹剔透
  • 设计驱动开发（D3）
  • 不要重复自己 (DRY) 或一次且仅一次 (OAOO)、单点事实 (SPoT)
  • 动态系统开发方法（DSDM）
  • 极限编程（XP）
  • 功能驱动开发
  • 好莱坞原则
  • 迭代增量开发
  • 联合应用程序设计，又名 JAD 或“联合应用程序开发”
  • 改善
  • 看板
  • KISS 原则（保持简单、愚蠢）
  • 精益软件开发
  • 微软解决方案框架（MSF）
  • 模型驱动架构（MDA）
  • 开源
  • 开放统一流程
  • 又快又脏
  • Rational 统一过程 (RUP)
  • Scrum
  • 智能（敏捷开发）
  • 关注点分离 (SoC)
  • 面向服务的建模
  • 软件工艺
  • 软件系统安全
  • 螺旋模型
  • 测试驱动开发（TDD）
  • 统一流程（UP）
  • V型
  • 瀑布模型
  • 轮辐模型
  • 越差越好（新泽西风格，与麻省理工学院的方法相比）
  • 极限
  • 你不需要它（YAGNI）
  • 零一无穷大

其他提示

高内聚 - 如何重点是你正在设计模块的职责

低耦合 - 的程度模块依赖于其他模块

之所以选择组合物过度继承，是一个。

很多人，特别是那些刚接触OO将开始扩展类，当所有他们真正需要的是用的组合物。真的，如果你要问你自己，是新B级A级？如果没有，那么你不应该延长。

例如，假设我有一个Person类，一类Car，我想提出一个叫做DrivenCar类新类。一个天真的实现是说（让我们假装我们得到了多重继承）

class DrivenCar extends Person, Car  { ... }

是对DrivenCar一个Person类型？不因此它不应该是延长人。是DrivenCar车吗？是这样是有意义的延长

使用组合物中的implmentation看起来像

class DrivenCar extends Car {
    private Person driver;
}

在 GRASP 图案。是的，他们似乎相当琐碎。更像蒸馏下降到芯品质，其他，更多地参与模式演示。

接口。大多数设计模式是基于接口和实现分离。

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top