网站外包如何报价近三天发生的重要新闻
- OOA：面向对象分析
- OOD：面向对象设计
- OOP：面向对象编程
- OOD的难点在于将一个系统分解成对象
- （Robert C.Martin）一个可维护性（Maintainability）较低的软件设计，通常由于如下4个原因造成：
- 过于僵硬（Rigidity）
- 过于脆弱（Fragility）
- 复用率低（Immobility）
- 黏度过高（Viscosity）
- （Peter Coad）一个好的系统设计应该具备如下三个性质：
- 可扩展性（Extensibility)
- 灵活性（Flexibility）
- 可插入性（Pluggability）
- 软件的可维护性和可复用性
- 面向对象设计复用的目标在于实现支持可维护性的复用
- 恰当的复用还可以改善系统的可维护性
常用面向对象设计原则
单一职责原则（Single Responsibility Principle，SRP）
类的职责要单一，不能将太多的职责放在一个类中
- 就一个类而言，应该仅有一个引起它变化的原因
开闭原则（Open-Closed Principle，OCP）
- 最重要的原则之一
软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能
- 设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为
- 抽象化是开闭原则的关键
里氏代换原则（Liskov Substitution Principle，LSP）
- 实现开闭原则的重要方式之一
所有引用基类（父类）的地方必须能透明地使用其子类的对象，即在软件中如果能够使用基类对象，那么一定能够使用其子类对象
- 如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o2都代换成o1时，程序P的行为没有变化，那么类型S是类型T的子类型
依赖倒转原则（Dependency Inversion Principle，DIP）
- 面向对象设计的主要手段
高层模块不应该依赖低层模块，它们都应该依赖抽象；抽象不应该依赖于细节，细节应该依赖于抽象
- 要针对接口编程，不要针对实现编程，即要针对抽象层编程，而不要针对具体类编程
- 常用实现方式之一是在代码中使用抽象类，而将具体类放在配置文件中
- 类之间的耦合
- 零耦合关系
- 具体耦合关系
- 抽象耦合关系
- 依赖倒转原则要求客户端依赖于抽象耦合，以抽象方式耦合是依赖倒转原则的关键
接口隔离原则（Interface Segregation Principle，ISP）
一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可，即使用多个专门的接口来取代一个统一的接口
- 客户端不应该依赖那些它不需要的接口
- 用多个专门的接口，而不使用单一的总接口
- 使用接口隔离原则拆分接口时，首先必须满足单一职责原则
合成复用原则（Composite Reuse Principle，CRP）
尽量使用对象组合，而不是继承来达到复用的目的，即在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系
迪米特法则（Law of Demeter，LoD）
- 又称最小知识原则
一个软件实体对其他实体的引用越少越好
- 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互
可变性封装原则（Principle of Encapsulation of Variation，EVP）
找到一个系统的可变因素，将之封装起来，即在设计中什么可能会发生变化，应使之成为抽象层而封装，而不是什么会导致设计改变才封装
| 目标 | 开闭原则 |
|---|---|
| 指导 | 最小知识原则 |
| 基础 | 单一职责原则、可变性封装原则 |
| 实现 | 依赖倒转原则、合成复用原则、里氏代换原则、接口隔离原则 |
软件模式
设计模式
分类
- 按目的分类
- 创建型：创建对象
- 结构型：处理类或对象的组合
- 行为型：描述对类或对象怎样交互和怎样分配职责
- 按范围分类
- 类模式：处理类和子类
- 在编译时就已经确定
- 属于静态的
- 对象模式：处理对象间的关系
- 在运行时刻变化
- 属于动态的
- 类模式：处理类和子类
| 范围\目的 | 创建型模式 | 结构型模式 | 行为型模式 |
|---|---|---|---|
| 类模式 | 工厂方法模式 | （类）适配器模式 | 模板方法模式 |
| 对象模式 | 抽象工厂模式 建造者模式 原型模式 单例模式 | （对象）适配器模式 享元模式 代理模式 | 命令模式 迭代器模式 中介者模式 观察者模式 状态模式 策略模式 |
Q&A about 设计模式与类库框架
- Q：如果设计模式这么好，为什么没人构建一个包含这些模式的库，这样就不用自己去弄了呢？
- A：设计模式比库的层次更高。设计模式告诉我们如何构建类和对象来解决特定问题，而根据我们特定的应用去调整这些设计是我们（开发者）的工作。
- Q：类库和框架不也是设计模式吗？
- A：框架和类库并非设计模式；它们提供特定的实现，供我们关联到自己的代码中。不过，有时类库和框架在其实现中会运用设计模式。这很好，因为一旦理解了设计模式，就能更快地理解那些围绕设计模式构建的应用程序编程接口（APIs） 。