一个目标:管理变化,提高复用
两种手段
分解
分解事务,归类事务,那些是变化的那些是不变的。
抽象
抽象出接口,变化点
八大原则
- 依赖倒置原则
- 开闭封闭原则
- 单一职责原则
- Liskov替换原则
- 接口隔离原则
- 面向对象优先使用对象组合,而不是类继承。
- 封装变化点
- 针对接口编程,而不是针对实现编程
相辅相成
内化成自己的一种认知
重构技法
静态 =》动态
早绑定 =》晚绑定
继承=》组合
编译时依赖=》运行时依赖
紧耦合=》松耦合
C++对象模型
//1
class A:B
{
};
//2
class A
{
B b;
};
//3
class A
{
B *pb;
};
觉大多数模式都是基于第三种,通过类型指针动态的指向某个具体类型的对象,来应对变化点。
任何模式的的优点就在于它解决的变化点,它的缺点就是它要求的稳定点。 如果一个模式的稳定点出现变化那这个模式不适合解决当前事务需要其他设计模式来解决。解决事务在于如何找出变化点与稳定点。
什么时候不适用模式
不要盲目的使用设计模式
- 代码可读性很差
- 需求理解还很浅显
软件的第一版,第二版 - 变化没有显现
- 不是系统的关键依赖点
- 项目没有复用价值时
- 项目将要发布时
经验之谈
- 不要为了模式而模式
- 关注抽象类&接口
- 理清变化点和稳定点
- 审视依赖关系
- 要有框架和应用接口的娶个思维
- 良好的设计是演化的结果
设计模式的成长之路
手中无剑,心中无剑:看见这个设计模式,但是不理解这个设计模式。
手中有剑,心中无剑:可以识别模式。作为应用开发人员使用模式
手中有剑,心中有剑:作为框架开发人员为应用设计某些模式。
手中无剑,心中有剑:忘掉设计模式,只遵守涉及原则。