设计模式之开篇原则（二）

续设计模式之开篇原则（一）

今天介绍设计模式原则之接口隔离、依赖倒置、迪米特法则

接口隔离

接口隔离（分离）指的是对高层接口的独立、分化，客户端对类的依赖应该基于最小接口，而不应该依赖不需要的接口。简单来说就是定义接口的时候尽量往小定义，不要定义成全能型的，什么都能，什么都会，最好是一个接口只对应一个角色职能。

假设我们要定义一个动物高层接口，我们开始思考，区别于植物，动物一定是能跑的，而且能叫，于是我们定义一个移动方法，和一个发声方法。然后动物们都开始实现这俩方法了，猫跑并喵喵叫；鸟飞并吱吱叫，看似很合理其实不然，有一天兔子蹦蹦跳跳可就是不会叫，但不得不默默地加个哑巴空方法。

这时就需要反思，接口定义的行为太多了，这些行为定义完全可以拆分开为两个独立接口“可移动接口”与“可发声接口”，这时兔子可以只依赖可移动接口了，而猫则可以依赖一个全新的“又可跑又可发声”的接口，显而易见此接口是从那两个独立出来的接口继承来的。

接口隔离原则要求我们对接口尽可能地细粒度化，小接口总比大接口要好。其实接口隔离原则与单一职责原则如出一辙，只不过是对高层行为能力的细粒度化规范，这非常好理解，分开的容易合起来，但合起来的就不好分开了，请记住，分开容易合起来难。接口隔离原则能很好地避免接口被设计地过于臃肿，轻量化接口更不会造成对实现类的污染，使系统模块间依赖变得更加松散、灵活。

依赖倒置

依赖倒置是指出只依赖抽象而不依赖具体实现，从而达到降低客户端对其他模块耦合的目的。我们知道客户端类要访问另一个类，传统做法是直接访问其方法，这就导致对实现类的强耦合，而依赖倒置的做法是反其道而行，间接地访问实现类的高层抽象，依赖高层比依赖底层实现要灵活得多，这也印证了我们在里氏替换里提到的”针对抽象编程“。

我们在做开发的时候常常会从高层往底层写代码，例如从业务逻辑层的时候我们大可不必过多关心数据源是什么，是文件还是数据库，是MySQL还是Oracle。所以我们可以调用数据访问接口，而其实现类可以暂且不写或者写一个模拟实现类用来单元测试，甚至可以交给熟悉的同事并行开发，只要是定义了良好的接口规范就不必关心底层实现细节，依赖高层抽象，不依赖底层具像，这就是依赖倒置原则的核心思想，从具象到抽象的倒置。

迪米特法则

迪米特法则或者被称为最少知识原则主要是通过最小化各模块间的通信、而割裂模块间千丝万缕的不必要联系，以达到松耦合的目的。迪米特法则提出一个模块对其他模块要知之甚少、拒绝陌生人、只和熟人交谈，否则对一个类的变动将引发蝴蝶效应般的连锁反应，这会波及到大范围的变动，系统可维护性差。

举个例子，我们买了一台游戏机，它像一给黑盒子内部集成了非常复杂的电路以及各种电子元件并且对外开放了手柄控制接口，这便是一个完美的封装。对于我们用户来说只需要用手柄操作就可以了，至于其内部的那些磁盘载入、内存读取、CPU指令接收、显卡显示等等我们是完全陌生的，也并不会去直接调用，这就是用户的正确使用方法