设计模式----设计原则
设计模式是一种设计思想，一种解决方案，能够做到代码的可复用性。这段时间利用空余的时间，在复习java的同时，学习设计模式。记录过程的一点体会。
1）单一职责原则
问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
如果一个类具有很多不同的功能，比如超人拥有很多的技能，当我们想对其中一种技能进行修改或者升级的时候就不得不停止超人其他的功能，而这期间如果有事情发生，超人是无法提供帮助的，那么是否可以让超人简单点呢？在维护世界和平的时候，也能够帮助人们除草呢？
这就是单一职责——对于一个类，应该只有一个引起她变化的原因。
实际上，往往会碰到职责分块的问题，会遇到将职责A划分为职责A1和A2，这时就需要重新设计类，尽量降低类的复杂度，提高类的可读性。
遵循单一职责原的优点有：
（1）可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
（2）提高类的可读性，提高系统的可维护性；
（3）变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
2）里氏代换原则
问题由来：有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
反映父类和子类的关系。B类继承A类，属于B的对象就具有A类的全部属性和方法。里氏代换的原则就是：子类型必须能够完全替换掉他们的父类型。即子类可以以父类的身份出现，并且不影响程序的功能时父类才能真正得到复用。所有引用基类的地方必须能透明地使用其子类的对象。通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。
3）开放-封闭原则
问题由来：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
解决方案：当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
在面向对象编程时，如果要实现一个新的功能，添加一个新类来完成往往要比修改现有的类更加方便和安全。封装变化，降低耦合。OCP的原则是：程序的实体对象（模块、类、函数）应该可以进行扩张，但不应该可以修改。对于扩展是开放的，对于修改是封闭的。绝对的封闭很难做到，那么在面对需求变化时，设计人员就应该对自己设计的模块决定选择哪种变化封闭，保证无需对原码进行修改。
具体的实现就是面向抽象编程，继承抽象父类，通过重写其方法来改变固有行为，从实现新的扩展方法。
4）依赖倒转原则
问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。核心思想是面向接口编程。
程序的高层模块不应该依赖于低层模块，但两者都应依赖于抽象：抽象不应该依赖于具体细节，而细节应该依赖于抽象，简而言之就是针对接口编程，不应该是针对实现编程。即通过抽象（接口或抽象类）是各个类或模块的实现彼此独立，不互相影响。程序的依赖关系终止于接口或抽象。
5）合成聚合复用原则
尽量不使用类继承，而尽量使用合成/聚合。聚合是一种比较弱的拥有关系，具体表现是甲对象中可以包括乙对象，但乙对象不是甲对象的一部分；合成则是一种比较强的拥有关系，体现的是严格整体和部分的关系，并且整体和部分有相同的生命周期。如果两个类的关系是Has-a，则不应该设计成继承。这个原则有一个去缺点，就是系统中会有很多对象需要管理。
6）迪米特法则
也叫做最少知识原则，一个对象尽可能少的了解其他对象，不和陌生人说话。每个类要尽可能的减少对其他类的依赖，不希望类之间建立直接的接触，如果需要接触则希望通过友元类（第三方）来传达（转发调用），这样会导致系统中存在大量的友元类。
问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
解决方案：尽量降低类与类之间的耦合。
