1. 前要
设计模式的奇妙我想会随着你业务能力的提升和遇到编码能力的瓶颈而逐渐体会.当你面临一个遗留旧业务几千行的业务耦合无人愿意去尝试解耦和分层的时候你会急切希望自己有十八般武艺能让你去解决令人抓狂的代码.设计模式就是那种Classic到永远不会被淘汰的东西,真的遗留下来的经典值得常常回味.
我会记录下我再次学习创建型设计模式的体会,也会好好去区分总是让人傻傻分不清楚的工厂模式和抽象工厂设计模式,创建型设计模式总共是五种,但是我也会把简单工厂设计模式也引入
- 简单工厂模式
- 工厂设计模式
- 抽象工厂设计模式
- 建造者设计模式
- 单例
- 原型
1.1 设计模式原则
设计模式的终极目标 :易维护,易扩展,易复用,灵活性,所以每一个设计模式我觉得都是为了解决这些问题,达到终极目标而衍生的产物,那么在开始设计模式之前,一定要记住这些原则,在每个设计模式中体会这些原则的妙用
单一职责原则
一个类,应该只有一个引起它变化的原因
如果一个类承担的职责过多,就等于这些职责耦合在一起,一个职责的变化可能会削弱这个类完成其他职责的能力.耦合带来了脆弱的设计
设计真正要做的许多内容,就是发现类中的职责并把这些职责相互分离
做到单一职责,这样你的代码才能易维护,易扩展,易复用,灵活多样
开放-封闭原则
扩展开放,更改封闭,抽取隔离类,函数中的相同变化
完全的封闭是不现实的,总会有无法对之封闭的变化,既然不可能完全封闭,那就要预判哪些会出现变化的封闭,通过构造抽象来隔离这些变化
依赖倒转原则
抽象不依赖细节,细节应该依赖抽象.就是应该针对接口编程,而不要对实现编程
高层模块不应该依赖于低层模块,两个都应该以来抽象层
面向对象的标志,对抽象编程而不是对细节编程,程序中的所有依赖关系都是终止于抽象类或者接口
最少知识原则,迪米特法则
两个类如果不必彼此直接通信,那么那两个类就不应该有直接的相互作用,如果有调用关系,那么就通过第三者转发
1.2 接口与抽象类
2. 设计模式
2.1 简单工厂模式
- 概念
- 组成
- 代码
2.2 工厂设计模式
- 概念
- 组成
- 代码
2.3 抽象工厂设计模式
- 概念
- 组成
- 代码