设计模式（06）——设计原则（1）
设计原则
设计原则，是设计模式的内功心法，基本所有的设计模式都是基于设计原则进行的具体化，如果说设计模式是如何操作的话，那么设计原则就是为何这么做的基石，因此，只要我们能充分理解设计原则，那么在此基础上，对设计模式就能更好的理解，甚至能自己设计出一种设计模式来。
单一职责原则
定义
一个类或模块，只需要完成一个范围的功能，而不要搞得大而全。
场景
例如我们设计一个社交网站，现在要存储用户信息，类设计如下：
public class UserInfo {
private String name;
private String like;
private String location;
}
现在，我们想想该类的设计是否符合单一职责原则？
答案是可能符合，也可能不符合。那么判断依据是什么呢？
原因就是类或模块职责的判断是根据业务来定的，并没有一个普遍认同的规则。例如，如果该需要要的网站还提供卖东西的功能，那么用户的地址信息，就是一个十分关键的信息，且该块功能就需要抽离出来作为一个单独的模块，此时，地址信息放在这里就不合适了，违反了单一职责原则。
但如果地址信息，只是一个值对象，也就是说其只是一个展示属性，那么放在这里就是合适的。
综上所述，可以看到单一职责原则并不是设计出来就一成不变的，其需要结合业务发展的具体情况来判断。因此我们在设计之初，可以考虑一个大而全的类，但随着业务的发展需要，需要持续不断的进行优化（也就是持续重构的思想）。
用处
单一职责，因为类的设计比较小而精，因此可以极大提高代码的可维护性和可读性。
此外因为每个类或模块只涉及自己的功能部分，因此，也做到了高内聚。
其他
但类的设计也不是越单一越好，因为如果拆分的过细的话，可能上层一个类需要修改，会导致下层所有依赖其的类都要修改，又影响了代码的可维护性，因此还是要根据业务需要来合理评估，重点是感觉要对。
开闭原则
定义
字面意思，一个类的设计，应该要对拓展开放，对修改关闭。因此这里的重点就是以下定义该如何判断：
- 什么样的代码修改是拓展；
- 什么样的代码修改是修改；
- 修改代码就一定是违反了该原则吗
场景
public static void main(String[] args) {
Demo demo = new Demo();
demo.consume(1);
}
// 根据传递过来的级别来进行不同的会员逻辑判断
public void consume(int type) {
if (type == 1) {
Console.log("您好，1级会员！");
}
if (type == 2) {
Console.log("您好，2级会员！");
}
}
现在，又提出一个新的需求，还需要根据对应的会员等级进行对应的金额扣除，如果是上述的设计方式，那么修改的方式则是下面这样：
public void consume(int type, int price) {
if (type == 1) {
Console.log("您好，1级会员，扣除金额{}", price);
}
if (type == 2) {
Console.log("您好，2级会员，扣除金额{}", price);
}
}
很明显，这样的方式有问题，如果还要再传递一个字段，例如优惠比例，那么依照该方案，则还需要修改接口定义，这就意味着调用方都需要修改，测试用例也需要对应的修改。
那么如果按照开闭原则的话，该如何设计呢？
首先我们对代码进行下重构
// 将所有相关属性封装起来
public class Vip {
private int type;
private int price;
private int radio;
}
针对每种处理方式，根据他们的公有行为抽象出一个抽象层：
public interface VipHandler {
void consume(Vip vip);
}
每种特殊处理方式实现对应的抽象：
public class FirstVipHandler implements VipHandler {
@Override
public void consume(Vip vip) {
if (vip.getType() == 1) {
Console.log("您好，1级会员，扣除金额{}", vip.getPrice() * vip.getRadio());
}
}
}
public class SecondVipHandler implements VipHandler {
@Override
public void consume(Vip vip) {
if (vip.getType() == 2) {
Console.log("您好，2级会员，扣除金额{}", vip.getPrice() * vip.getRadio());
}
}
}
通过这样的处理方式，在每次接到新的任务后，就不需要重新修改原有的逻辑方法，可以直接进行拓展即可：
// 根据传递过来的级别来进行不同的会员逻辑判断
public void consume(Vip vip, VipHandler vipHandler) {
vipHandler.consume(vip);
}
其他
可以看到即使是上述的方式来拓展代码，仍旧会修改原有代码，那么这种方式是违反了开闭原则吗？
在这里，我们判断其并符合了开闭原则，因为我们判断是修改还是拓展，并不能只是简单的根据看是否修改了原有代码，真正核心的关键问题应该是：
- 改动没有破坏原有代码的正常运行；
- 改动没有破坏原有单元测试
**
在上述的修改后，我们如果加一种特殊的情况，并没有修改到原先的处理逻辑类，这也就意味着原先的代码不会引入一些可能的 bug，针对原始代码的测试用例也还是可以照常的进行编写，而不用再根据新的改动而进行改动。
用途
开闭原则的关键点是代码的可拓展性，即如何快速的拥抱变化，当每次新的任务来后，不必修改原始代码，而直接在原有的基础上进行拓展即可。
关闭修改是保持原有代码的稳定性。
里氏替换原则
定义
子类对象可以代替父类对象出现的任何地方，并保证原来程序逻辑行为不被破坏。
因为要保证子类对象不能破坏原有程序逻辑行为，因此该方式跟多态的区别是：如果子类进行了重写，并在重写的逻辑中加入了跟父类对应方法不同的逻辑，那么该方式可以称之为多态，但就不符合里氏替换原则了。
用途
该原则最重要的作用是指导子类的设计，保证在替换父类的时候，不改变原有程序的逻辑行为。
在这里，重点是逻辑行为的不改变，这就意味着，我们可以对实现的细节进行修改，只要保证业务含义不变，那么就是符合里氏替换原则的。
因此，针对这种情况，有一种用途是可以 改进 原有的实现，例如原先采用的排序算法比较低效，那么可以设计一个子类，然后重写对应排序算法，保证逻辑不发生变化。重点是，我们做的是改进，不管如何改，排序的业务含义是不变的。
实现方式，则是按照协议进行编程，关键是子类重写过程中，要保证不破坏原有函数声明的输入、输出、异常以及注释中罗列的任何特殊情况声明。
接口隔离原则
定义
首先，我们要对接口进行定义，明确其特殊含义，对于接口来说，我们将其分为两种类型的表现形式。
- 一种语法定义，其代表了一组方法的集合；
- 向外暴露的单个API接口或函数实现
下面，我们分别对其进行介绍。
场景：一组API聚合
public interface UserInfoService {
boolean login();
void getUserInfoByPhone();
void deleteUserByPhone();
}
看上述这个接口定义是否符合接口隔离原则？？？
其实这跟单一职责原则一样，也是要看业务发展的。例如，如果该接口是提供给后台管理系统来使用的，那么没有问题，作为一个后台系统的 admin 权限人员当然可以有很多操作的能力。
但如果该接口是给第三方用户来使用的话，就不是很合适了。因为删除操作是一个高权限能力，作为用户来说，一般是没有权限做的，那么在设计时，对应实现类就不应该实现全部接口内定义的方法，这就是接口隔离原则中所说的，不强制依赖接口中的所有方法。
**
而是，根据具体的定义，将其进行拆分，对应权限的实现类实现对应的权限行为。
场景：单个API接口或函数实现
public class Statistics {
private int max;
private int min;
private int sum;
//......
public Statistics count(List<Integer> data){
Statistics statistics = new Statistics();
// 计算 Statistics 中的每个值
return statistics;
}
}
首先，我们来看上述方法定义是否符合接口隔离原则？？？
在这里，我们还是要结合具体的业务场景才能做出结论，如果使用该函数的调用者，在大部分场景下都需要用到其中的大部分字段，那么该设计就是可以的。
但是如果每次只用到其中的几个，那么该设计就不合理了，其会浪费大量的无效计算能力，影响性能。在该场景下，就需要进行拆分。
public int max(List<Integer> data) {
return data.stream().max(Statistics::compare).get();
}
public int min(List<Integer> data) {
return data.stream().min(Statistics::compare).get();
}
依赖翻转原则
对于依赖翻转原则来说，有很多看着很像的定义，我们分别对其进行介绍，看看其都是什么含义，他们之间又有什么关联。
控制翻转（IOC）
控制翻转，针对是在原有的程序设计流程中，整个程序的运行流程是直接交由程序员来控制的，但是如果使用控制翻转的思想，则是在一个架子中，已经定义好了执行的流程，而只是预先定义好了拓展点，后续程序员所能修改的只有拓展点，开发人员在拓展点里添加相关业务逻辑即可。
public abstract class VipProcess {
public abstract boolean isVip();
public void consume() {
if (isVip()) {
Console.log("vip hello");
} else {
Console.log("get out");
}
}
}
public class Vip extends VipProcess {
@Override
public boolean isVip() {
return true;
}
public static void main(String[] args) {
VipProcess vip = new Vip();
vip.consume();
}
}
public class CommonPeople extends VipProcess {
@Override
public boolean isVip() {
return false;
}
public static void main(String[] args) {
VipProcess vip = new CommonPeople();
vip.consume();
}
}
上述方式，就是通过模板方法来实现的控制翻转，提供一个拓展的 isVip() 逻辑来交给程序员来实现，而框架根据实际实现的方法返回来决定下面的程序流转。
依赖注入（DI）
依赖注入更好理解，一句话概括：不用程序员显式通过 new 来创建对象，而是通过构造函数，函数传递的方式来传递对象。
即A类如果需要依赖B类，不是通过在 A 中 new 一个 B 出来，而是在外面创建好 B 后，传递给 A。通过这样的方式，可以在需求改变中，灵活的替换传递参数（B 实现 C 接口的话）。
而更进一步，现在一些框架都提供了 DI 的功能，只需要简单的配置一下相关类对象，所需参数等，框架就会自动接管对象的创建流程已经生命周期等。（AutoWired）
依赖翻转（DIP）
定义：高层模块不依赖于底层模块，而是通过一个抽象层来解耦。
该定义其实在我们的平常业务开发中，不怎么会用到，因为我们平常就是高层依赖着底层，例如 Controller 依赖 Service，Service 依赖 Repository，该原则的重点还是指导框架层面的开发。
例如 Tomcat ，我们知道 Tomcat 的运行是我们将程序写完后，打成 war 包扔到对应目录就可以启动了，而 Tomcat 和应用程序就是通过一个共同的抽象 **Servlet **来关联的。
Tomcat 不直接依赖于底层实现：Web 程序，而是跟 Web 都依赖于 Servlet，而 Servlet 不依赖于具体的Tomcat 实现的 Web 的具体细节。
通过该实现方式，在编码中，可以灵活的进行替换，比如我们还是一个 web 程序，但是运行的容器不使用 tomcat 了，也可以无缝的进行切换，只要保证要替换的容器，还是依赖于 Servlet 规范即可。
