设计模式
设计模式的概念
设计模式最初用于建筑领域的设计中。
软件的设计模式，又称设计模式，是一套被反复使用，多数人知道的，经过分类编目的，代码设计经验的总结。
它描述了在软件设计过程中的一些不断重复发生的问题，以及如何解决这些问题。
它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。
设计模式的作用
设计模式的本质是面向对象设计原则的实际运用，是对类的封装性，继承性和多态性记忆类的关联关系和组合关系的充分理解。
正确使用设计模式具有以下优点：
- 可以提高程序员的思维能力，编程能力和设计能力。
- 使程序设计更加标准化，使软件开发效率大大提高。
- 使设计的代码可重用性高，可读性强，可靠性高，灵活性好，可维护性强。
- 能够更好的去理解源码架构。
如果需要设计大型项目架构，必须考虑增加新功能的代码变动成本，要保证新加入的功能不影响以前的功能。
建模语言
统一建模语言（Unifiled Modeling Language）简称UML是一种用于软件系统分析和设计的语言工具，用于帮助软件开发人员进行思考和记录思路的结果。
UML图：通过不同的图形和符号来描述软件模型以及各个元素之间的关系。
类图：展示模型的静态结构，特别是模型中存在的类，类的内部结构以及它们与其他类的关系等。
类
类是指具有相同属性，方法，关系的对象的抽象，封装了数据和行为，是OOP（面向对象程序设计）的基础，具有封装性，继承性和多态性等三大特性。
在UML中，类使用包含类名，属性和操作且带有分割线的矩形表示。
- 类名是一个字符串，例如：Student，Teacher
- 属性是指类的特性，即类的成员变量。
UML按照以下格式：
[可见性]属性名:类型[=默认值]
例如:-name:String
注意：“可见性”表示该属性对类外的元素是否可见，包括公有（Public）、私
有（Private）、受保护（Protected）和朋友（Friendly）4 种，在类图中分别
用符号+、-、#、~表示。
3.操作是类的任意一个实例对象都可以使用的行为，是类的成员方法
UML按照以下格式：
[可见性]名称(参数列表)[:返回类型]
例如：+display():void。
学生类的UML表示如下：
接口
接口是一种特殊的类，它具有类的结构但不可被实例化，只可以被子类实现。
它包含抽象操作，但不包含属性。它描述了类或组件对外可见的
UML表示如下：
类之间的关系
在软件系统中，类不是孤立的，类与类之间存在各种关系。根据类与类之间的耦合度从弱到强排列，UML中类图有以下几种关系：
依赖关系，关联关系，聚合关系，组合关系，泛化关系，实现关系。
其中泛化和实现的耦合度相等，它们是最强的。
1.依赖关系
依赖关系指的是一种临时使用的关联，是耦合度最低的关系。
某个类的方法通过局部变量，方法的参数或者对静态方法的临时调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。
在UML中依赖关系使用带箭头的虚线表示，剪头从使用类指向被依赖类。
下图展示人通过手机的语言传送方法打电话
2.关联关系
是对象之间的引用关系。
用于表示一类对象与另一类对象之间的联系，如老师和学生，师傅和徒弟等。
关联关系是类与类之间最常用的一种关系，氛围一般关联关系，聚合关系和组合关系。
关联可以分为单向关联，双向关联，自关联。
单向关联：
双向关联：
所谓双向关联就是双方各自持有对方类型的成员变量。
自关联：
3.聚合关系
聚合关系是关联关系的一种,是强关联关系,是整体和部分之间的关系。
聚合关系通过成员对象实现，其中成员对象时整体对象的一部分，但成员对象可脱离整体对象独立存在。例如学校和老师的关系，若学校消失老师独立存在
聚合关系在UML图中用空心菱形的实线表示，菱形指向整体。
4.组合关系
组合表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系。
在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在了，部分对象也将不复存在，部分对象无法脱离整体对象而存在。例如头和嘴的关系。
在UML图中组合关系使用实心菱形实线表示：
5.继承关系
继承关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与字类之间的关系，是一种继承关系，是is-a的关系。
在UML图中，继承关系使用空心三角剪头实线表示，剪头从子类指向父类，在代码实现时，使用面向对象的继承机制来实现继承关系。
例如下图：
6.实现关系
实现关系是接口和实现类之间的关系。
在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。
在UMl类图中，实现关系使用带空心三角剪头的虚线表示
如下图：
面向对象设计原则
单一职责
单一职责原则是最简单的面向对象设计原则，用于控制类的粒度大小。
对于单一职责原则，可以理解为一个类只负责一个功能领域中的相应职责，即一个类不要负责太多杂乱的工作。
在软件系统中，如果一个类继承的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或已知这个类完成其他职责的能力，这种耦合会导致一个脆弱的设计。
单一职责原则是实现高内聚，低耦合的指导方针。
以项目开发为例，如果项目组成员每个人的职责都很明确，可以专心开发自己负责的板块，那么项目成功就会相对较高，反之则较低
开闭原则
开闭原则指的是对拓展开放，对修改封闭。
在程序需要进行拓展时，不能去修改原有的代码，实现一个热插拔的效果。
为了使程序的拓展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。
而软件中易变的细节可以中抽象派生出来的实现类来拓展。
依赖倒置
上层模块不应该依赖低层模块，它们都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。
核心思想：面向接口，不面向实现编程。
抽象指的是抽象类或接口，细节指的是实现类。
使用接口或抽象类制定好规范和契约，不设计任何具体的操作，把展现细节的人物交给它们的实现类完成。
依赖倒置原则是实现开闭原则的重要途径之一，降低了类与类模块之间的耦合。
接口隔离
使用多个接口，而不使用单一的接口，不强迫新功能实现不同的方法。
组合/聚合复用原则
优先使用组合/聚合,使系统更加灵活,其次才考虑继承,达到复用的目的.
一般而言,如果两个类之间是"Has-A"关系应使用组合或聚合,如果是"Is-A"关系使用继承
里氏替换原则
使用继承时若父类的方法是非抽象的，那么子类继承父类并对父类中的非抽象方法进行重写时要注意，若使用父类的时候换成子类对象，由于子类对象重写的父类方法，从而导致有可能实现不相同导致结果不对
里氏替换原则的提出
1987年麻省理工计算机科学实验室思里科夫女士在面向对象技术的高峰会议上发表的文章《数据抽象和层次》中提出，她表明：挤成必须保证超类所拥有的性质在子类中仍然成立。
里氏替换原则主要阐述了有关挤成的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，使用继承时应该避免哪些问题。
里氏替换原则的定义
所有使用父类的地方必须能透明地使用其子类的对象。
在软件中将一个基类对象替换成它的子类对象时程序将不会产生任何错误和异常
简单来说，任何基类可以出现的地方，字类一定可以出现，所以字类可以拓展父类的中能，但不能改变父类原有的功能。
也就是说子类继承父类时，除了添加新的方法完成新增功能外，尽量不要重写父类方法，如果重写父类的方法，程序运行会发生出错概率。如果一定要用多态，那么父类可以设计成抽象接口。
历史替换原则的作用
它是功能正确性的保证。
加强程序的健壮性，提高程序的维护性降低需求变更时引入的风险
迪米特原则
只和“朋友”交谈，不和“陌生人”说话。
两个类之间如果没有直接的联系，那么就不要相互之间调用，可以通过一个第三方进行调用。
例如：明星，公司，粉丝，经纪人之间的交流
可以通过经纪人和明星，公司，粉丝分别进行接触，交流
总结
设计原则的核心思想
找出应用中可能需要变化之处，独立出来，不要和不需要变化的代码混在一起
针对抽象编程，而不是针对程序编程
为了交互对象的松耦合设计而努力
遵循设计原则；为了让程序高内聚，低耦合