#设计模式#GeekBand设计模式第一周课程
今天看了李老师的设计模式，晚上在此通过记忆整理一下，明天再根据笔记详细整理。
————————通过记忆整理————————————————————————
设计原则 比 设计模式 更本质
目前常用的设计模式有23种，然而这都是方法，更重要的是其中本质的东西：设计原则，设计思想。
分解和抽象
面向对象的三个重要概念是：1、封装 2、继承 3、多态 但是这三个概念都是底层的，在上层上需要使用“抽象”的思想去处理问题。
分解：分而治之，这是人们经常使用的解决问题的方法，其基本思想是把问题拆分开来处理
抽象：将问题统一起来看待，找到不考虑细节、更理想化的模型
设计模式的目标是：复用
当处理一个简单，或者不需要变化的问题时，设计模式的不同影响不大。
然而一旦出现变化（客户需求变化，开发平台变化，开发人员变化），那么设计模型的作用就体现出来了。
在一系列设计原则的指导下，可以尽可能小的修改代码，就应付出现的变化。
设计原则
李老师提到了好几条设计原则，
我记忆最深的是三个思想：
1、向下依赖
稳定的模块不要依赖变化的模块。
2、各司其职
每个代码完成其对应的工作，比如“打印”，该类需要被打印，那么就自己实现打印函数。
这样其他类通过该类的基类的虚函数就可以调用该类的函数（多态性）。
3、继承和组合。
如果子类不会使用父类的太多函数，可以考虑使用“组合”的模式，而不是“继承”的模式。
继承其实在一定程度上破坏了“封装”，增加了耦合
————————通过笔记整理————————————————————————
***********第一讲开始********************************************
设计模式主要是一种松耦合设计思想
每一种设计模式，其实是针对某个重复出现的问题，提出的解决方案
在编程过程中，向下是底层思维，向上是抽象思维
| 底层思维 | 抽象思维 |
|
语言构造 编译转换 内存模型 运行时机制 |
面向对象 组件封装 设计模式 架构模式 |
对于问题，人们常用两种解决方法
| 分解 |
将问题分解成一个一个的步骤， 建立一个类A类B 如果类C需要使用类A的信息，就包含类A类B作为成员 如果类C需要打印类A的信息，就在类C中撰写打印类A类B的函数 |
| 抽象 |
由于不能掌握全部的复杂对象，选择忽视它的非本质细节，而去处理泛化和理想化的模型 类C并不知道需要为哪个类服务，需要它选择为类A类B的基类服务 类A类B各自实现功能，可以通过虚函数去调用 如果类C需要打印类A，就通过虚函数，动态调用类A的打印函数； 如果类C需要打印类A，就通过虚函数，动态调用类B的打印函数； |
软件设计的目标是：复用
***********第一讲结束，第二讲开始********************************************
在代码不出现变化的时候，设计模式的优势看不出来，而一旦出现变化，好的设计模式的作用就体现出来了。
面向对象的最大优势是：抵御变化
重新认识面向对象：
1、宏观角度。隔离变化
2、微观角度（具体实现角度）。各个部分各司其职，完成各自的功能。
3、对象是什么？
从语言实现角度，对象就是代码和数据的集合
从规格层面，对象是一系列可被使用的公共接口
从概念角度，对象是拥有责任的抽象
面向对象设计模型的8大原则
| 依赖倒置原则(DIP) |
1、高层模块(稳定)不应该依赖于低层模块（变化），二者都依赖于抽象（稳定） 2、抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定） 稳定不能依赖变化 |
| 开放封闭原则(OCP) |
对扩展开放，对更改封闭 类模块应该是可扩展的，但不可修改 （对于“变化”，用“增加”去应对） |
| 单一职责原则（SRP） |
一个类应该仅有一个引起它变化的原因 （变化的方向隐含类的责任） |
| Liskov替换原则（LSP） |
子类必须能够替换它们的基类（反映的是is-A的关系） |
| 接口隔离原则（ISP） |
不应该强迫客户程序依赖它们不用的方法 接口要小而完备 |
| 优先使用对象组合，而不是类继承 |
类继承通常是“白箱复用”，对象组合通常为“黑箱复用” 继承在某种程度上破坏了封装性，子类父类的耦合度高 而对象组合只要求对象有良好定义的接口 |
| 封装变化点 | 使用封装来创建对象之间的分界层，让设计者可以只对一侧进行修改，而不影响另外一侧 |
| 针对接口编程，而不是针对实现编程 |
不将变量类型声明为某个特定的具体类，而是声明为某个接口 客户程序无需知道对象的具体类型，只需要知道接口 （老师提到，产业强盛的标志是“接口标准化”） |
纸上学来终觉浅，绝知此事要躬行。
设计模式，还需要多体会。
