持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第3天，点击查看活动详情
软件开发模型
- 瀑布模型
开发过程通过设计一系列阶段顺序展开
需求发生变化就会比较麻烦 - 增量开发模型 把待开发的软件系统模块化，将每个模块作为一个增量组件，依次分析设计编码和测试这些增量
- 原型开发模型 在开发前，应建立系统的一个工作原型
模型图
用例图、类图、对象图、活动图、时序图、协作图、组件图、部署图
面对对象
四个特性：封装、抽象、继承、多态
面对对象分析 OOA
面对对象设计 OOD
面对对象编程 OOP
- 抽象：让调用者只关心使用，不关心功能实现，把实现的功能隐藏起来
- 继承：主要是实现代码逻辑的复用，或者说是属性和方法的复用。但是过度使用也会导致类的层次过深，类和类之间出现了耦合，如果修改父类，子类也会跟着变
- 封装：把数据封装起来，减少耦合，可以不让外部访问不该访问的，利于数据的接口权限管理，仅暴露有限的必要接口，提高类的易用性，保护类的隐私
public protected private - 多态：子类可以替换父类，保持子类的开放性和灵活性，可以重写父类中的方法
设计原则
SOLID五大设计原则
开放封闭原则
单一职责原则
- 一个类或者模块只负责完成一个职责，如果功能特别复杂就进行拆分
- 单一职责可以降低累的复杂性，提高代码可读性、可维护性
- 当类代码行数过多、方法过多、功能过多、职责太杂的时候就要对类进行拆分了
- 拆分不能过度，如果拆分过度会损失内聚性和维护性 如lodash.js、jquery
里氏替换原则
- 所有引用基类的地方必须能透明地使用其子类的对象（要求子类不能违反父类的功能和规定）
- 子类能替换掉其父类，使用者可能根本就不需要知道是父类还是子类，反之则不行
- 里氏替换原则是开闭原则的实现基础，程序设计的时候尽量使用基类定义及引用，运行时再决定使用哪个子类
- 里氏替换原则可以提高代码的复用性，提高代码的可扩展性，也增加了耦合性
- 相对于多态，这个原则是讲的是类如何设计，子类如果违反了父类的功能则表示违反了里氏替换原则
依赖倒置原则
- 面对接口编程，依赖于抽象而不依赖于具体实现
- 要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类
- 使用方只关注接口而不关注具体类的实现
接口隔离原则
- 保持接口的单一独立，避免出现胖接口
- 客户端不应该依赖它不需要的接口，类间的依赖关系应该建立在最小的接口上
- 接口尽量细化，而且接口中的方法尽量的少
- 类似于单一职责原则，更关注接口
迪米特法则
- 有时候也叫最少知识原则
- 一个软件实体应当尽可能少地与其他实体发生相互作用
- 迪米特法则的初衷在于降低类之间的耦合
- 类定义时尽量要实现内聚，少使用public修饰符，尽量使用private,protected等
合成复用原则
类的关系
- 类之间有三种基本关系，分别是关联（聚合和组合）、泛化和依赖
- 如果一个类单向依赖另一个类，那么它们之间就是单向关联。如果彼此依赖，则为相互依赖，即双向关联
- 关联关系包括两种特例：聚合和组合
- 聚合：用来表示整体与部分的关系或者拥有关系，代表部分的对象可能会被整体拥有，但并不一定定会随着整体的消亡而销毁，比如班级和学生。
- 合成：或者说组合，要比聚合关系强的多，部分和整体的生命周期是一致的，比如任何器官之间
合成复用原则
- 合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的
- 新对象可以调用已有对象的功能，从而达到复用
- 原则是尽量首先使用组合/聚合的方式，而不是使用继承
- 专业人做专业事
总结
- 开闭原则是核心，对修改关闭对扩展开放是软件设计的基石
- 单一职责要求我们设计接口和模块功能的时候尽量保证单一性和原子性，修改一条不影响全局和其他模块
- 里式替换原则和依赖倒置原则要求面向接口和抽象编程，不要依赖具体实现，否则实现一改，上层调用者就要对应修改
如何写出好代码
- 可维护性 BUG是否好改？
- 可读性 是否容易看懂？
- 可扩展性 是否可以添加新功能？
- 灵活性 添加新功能是否容易？老方法和接口是否容易复用？
- 简洁性 代码是否简单清晰？
- 可复用性 相同的代码不要写2遍
- 可测试性 是否方便写单元测试和集成测试
23种设计模式
创建型
- 工厂模式（工厂方法模式、抽象工厂模式、简单工厂模式）、建设者模式、单例模式
- 原型模式
结构型模式
- 代理模式、桥接模式、装饰器模式、适配器模式
- 外观模式、组合模式、享元模式
行为型
- 观察者模式、模板方法模式、策略模式、职责链模式、迭代器模式、状态模式
- 访问者模式、备忘录模式、命令模式、解释器模式、中介者模式
