【设计模式 - 2】六大设计原则

六大设计原则包含

• 单一职责原则
• 开闭原则
• 里氏替换原则
• 接口隔离原则
• 迪米特法则
• 依赖倒置原则

单一职责原则

单一职责原则一般指一个类的设计应该粒度尽量小，负责的功能尽量单一。

public class UserInfo {
	// 个人信息
	private int userId;
	String telNo;
	char gender;
	// 地址信息
	String province;
	String city;
}

这个UserInfo类是否满足单一职责原则呢？其实应该根据具体的业务需求判断。在只需要做用户信息展示的业务场景下，这个设计没有问题，但是如果加入了电商的需求，那么就应该把地址信息给拆分出来了。

开闭原则

开闭原则指的是某个功能对外提供服务的时候，客户端只需要知道接口定义，不需要知道实现，而且在需求变更之后，客户端也不需要修改接口调用，内部实现完全对客户端透明，实际上是多态的功能。
例如一个数据协议包含了解译，编制，校验功能。在第一个版本实现之后加入有新需求需要修改，那么只需要新增一个实现类，接口不需要改变，那么客户端实际上是不需要关心是否改变的。

里氏替换原则

里氏替换原则指的是用同样的接口调用情境下，如果替换了接口的实现类，那么其表现形式应该不受影响。
我觉得一个比较好的例子应该是在电商情境下，加入要知道某个商品的价格，那么可以提供一个公用的计算方法，里面调用策略接口的计算方法计算价格，但是策略接口的实现可以是不同的类，根据不同的场景传入不同的实现，就能得到不同的价格，但是整个方法不会因为传入的策略不同而受到影响。

接口隔离原则

罗伯特C·马丁说过，客户端不应该被迫依赖于它不使用的方法，也有人说过一个类对另一个类的依赖应该建立在最小的接口上。总结出来就是说，我们因该为各个类建立他们各自需要的专用接口；而不是定义一个大锅饭，里面包含各种各样的不同业务不同功能的方法，每个类都去实现它，这是不对的。假如说有个接口UserService，里面提供了一系列的操作，登录，注册，查询，删除，等等各种功能。假如有一个后台管理系统需要删除用户，可以实现这个接口调用其中的删除方法；同样的，其他的地方如要用这个接口的其他功能，也实现了这个接口，但是就有可能出现误删除用户的情况，所以可以将删除方法单独提出来，或者提供一个后台管理系统专用的接口。这样其他不需要使用的地方就没有机会调用到这个删除方法，当他需要删除的时候，再额外实现这个新接口就行了。这样分解开来就非常的清晰。
接口隔离原则能给代码带来的好处我归为以下三点：

• 将胖接口拆分成以功能为单位的小接口，大大提高了代码的灵活性，按需实现。
• 在程序员眼中这样的代码应该是层次感更加分明更加好理解和维护的
• 大大减少了冗余代码

依赖倒置原则

这个原则一般用于框架的设计。传统的一些架构设计上，一般是自顶向下的层层依赖，高层依赖中间层，中间层依赖底层，这样就会一发而动全身。根据依赖倒置原则的话，可以把中间层抽象成接口供底层实现，高层调用；这样底层的代码变化了也不会影响到高层代码。
举个例子，组装一个电脑，假如这个电脑把CPU，内存，硬盘的型号全部定死，那基本上以后就没机会换其中某个部件了，加入都是用接口依赖的形式，那么电脑无心关心硬件厂商，只需要调用硬件接口就可以了。如图：

迪米特法则

迪米特法则应该是最容易也是平时用的最多的原则。简单可以概括为最少依赖原则；不该有依赖的两个类，不要产生依赖关系；有依赖关系的两个类尽量只依赖必要的接口。一般可以通过加入第三方类来实现。
用足球来举个例子吧。球星，经纪人，俱乐部，球迷，这几个关系应该为经纪人穿插在所有对象中间做协调，除了经纪人其余对象不应该有直接的依赖。