设计模式-前言

　　最近正在学习设计模式部分的知识，看了很多大牛整理好的博文和一些视频讲解。在博文和视频中各位老师举的例子都特别形象，本想转载一下了事，但知识的东西毕竟还是通过自己写出来才能理解的更透彻，也可顺便作为自己的学习总结，同时帮助自己记录下还有哪些设计模式还没有学到，已经学过的设计模式是否还没有学透。所以准备以博客形式记录下来，如果在某一点上能帮助到几名想要学习设计模式的同学那就是最好的了。话不多说，言归正传,开始我们的设计模式的征程！！

　　在前言部分需要先了解以下几个问题：

什么是设计模式
设计模式的设计原则
设计模式分类与功能介绍

1.什么是设计模式

　　官方定义如下：设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。

说白了就是老前辈们在各个项目中总结出来的一套经验方法，一种思维模式，并已经反复被使用，这些方法巧妙的解决了很多困难的问题，针对不同的情况会有相应的处理办法。

这些方法被GOF("四人帮")总结了出来，共23种经典的设计模式。如果灵活正确的使用设计模式可以提高软件整体的可复用性和可扩展性，达到“高内聚、低耦合”目的，为可复用软件设计奠定了一定的理论基础。

2.设计模式的设计原则

　　说到设计原则就不得不说面向对象的6大设计原则。具体原则简述如下：

单一职责原则：
- 即一个类只负责一个职责，只把一件事情做好，其他事情不管。
里氏替换原则：
- 当需要一个父类对象的时候，可以用一个子类对象来特换。
- 当需要一个子类对象，给一个父类对象是不行的
- 把子类类型赋值给父类类型，发生了隐式转换
- 把父类类型赋值给子类类型，需要显示转换（强制转换），前提是父类所指对象确实是显示转换的子类类型，如果不是则转换失败。
- 为了避免显示类型转换失败，可以先进行类型判断如： if（对象 is 类）（ 对象 as 类）如果失败返回null
依赖倒置原则：
- 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
- 抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成
- 依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。
  - 底层模块尽量都有抽象类或接口，或者两者都有个。
  - 变量声明类型尽量都是抽象类或接口
  - 使用继承时遵循里氏替换原则
接口隔离原则：
- 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
- 即：如果一个接口功能特别多，需要将功能进行拆分，分解为多个小接口，类只集成自己需要的接口。
迪米特法则：
- 定义：一个对象应该对其他对象保持最少的了解。
- 目的：达到模块之间的低耦合
- 方法：只与直接的朋友通信。我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。陌生的类最好不要作为局部变量的形式出现在类的内部。
开闭原则：
- 程序写好后如果要扩展功能是允许的，但是禁止修改源代码，对修改封闭。即：功能扩展开放
- 利用多态功能就可解决