我的目的地，就是下一步所能跨到的最远的中央。不管何时，迈出第一步永远是最难的，因为有些路一但跨入就无奈回头，我无数次告诫本人，做过的事不悔恨，我跨出的每一步都是裹足不前的。

这篇文章次要讲的是面向对象设计中，咱们应该遵循的六大准则。只有把握了这些准则，咱们能力更好的了解设计模式。咱们接下来要介绍以下 6 个内容。

• 繁多职责准则——SRP
• 开闭准则——OCP
• 里式替换准则——LSP
• 依赖倒置准则——DIP
• 接口隔离准则——ISP
• 迪米特准则——LOD

繁多职责准则

繁多职责准则的定义是就一个类而言，应该仅有一个引起他变动的起因。也就是说一个类应该只负责一件事件。如果一个类负责了办法 M1, 办法 M2 两个不同的事件，当 M1 办法发生变化的时候，咱们须要批改这个类的 M1 办法，然而这个时候就有可能导致 M2 办法不能工作。这个不是咱们期待的，然而因为这种设计却很有可能产生。所以这个时候，咱们须要把 M1 办法，M2 办法独自拆散成两个类。让每个类只分心解决本人的办法。

繁多职责准则的益处如下：

能够升高类的复杂度，一个类只负责一项职责，这样逻辑也简略很多。进步类的可读性，和零碎的维护性，因为不会有其余奇怪的办法来烦扰咱们了解这个类的含意，当发生变化的时候，能将变动的影响降到最小，因为只会在这个类中做出批改。

开闭准则

开闭准则和繁多职责准则一样，是十分根底而且个别是常识的准则。开闭准则的定义是软件中的对象 (类，模块，函数等) 应该对于扩大是凋谢的，然而对于批改是敞开的。

当需要产生扭转的时候，咱们须要对代码进行批改，这个时候咱们应该尽量去扩大原来的代码，而不是去批改原来的代码，因为这样可能会引起更多的问题。

这个准则和繁多职责准则一样，是一个大家都这样去认为然而又没规定具体该如何去做的一种准则。

开闭准则咱们能够用一种形式来确保他，咱们用形象去构建框架，用实现扩大细节。这样当产生批改的时候，咱们就间接用抽象类派生一个具体类去实现批改。

里氏替换准则

里氏替换准则是一个十分有用的一个概念。他的定义：

如果对每一个类型为 T1 的对象 o1, 都有类型为 T2 的对象 o2, 使得以 T1 定义的所有程序 P 在所有对象 o1 都替换成 o2 的时候，程序 P 的行为都没有发生变化，那么类型 T2 是类型 T1 的子类型。

这样说有点简单，其实有一个简略的定义：

所有援用基类的中央必须可能通明地应用其子类的对象。

里氏替换准则艰深的去讲就是：子类能够去扩大父类的性能，然而不能扭转父类原有的性能。他蕴含以下几层意思：

• 子类能够实现父类的形象办法，然而不能笼罩父类的非形象办法。
• 子类能够减少本人独有的办法。
• 当子类的办法重载父类的办法时候，办法的形参要比父类的办法的输出参数更加宽松。
• 当子类的办法实现父类的形象办法时，办法的返回值要比父类更严格。

里氏替换准则之所以这样要求是因为继承有很多毛病，他尽管是复用代码的一种办法，但同时继承在肯定水平上违反了封装。父类的属性和办法对子类都是通明的，子类能够随便批改父类的成员。这也导致了，如果需要变更，子类对父类的办法进行一些复写的时候，其余的子类无奈失常工作。所以里氏替换法令被提出来。

确保程序遵循里氏替换准则能够要求咱们的程序建设形象，通过形象去建设标准，而后用实现去扩大细节，这个是不是很耳熟，对，里氏替换准则和开闭准则往往是相互依存的。

依赖倒置准则

依赖倒置准则指的是一种非凡的解耦形式，使得高层次的模块不应该依赖于低层次的模块的实现细节的目标，依赖模块被颠倒了。这也是一个让人难懂的定义，他能够简略来说就是：

高层模块不应该依赖低层模块，两者都应该依赖其形象；形象不应该依赖细节，细节应该依赖形象。

在 Java 中形象指的是接口或者抽象类，两者皆不能实例化。而细节就是实现类，也就是实现了接口或者继承了抽象类的类。他是能够被实例化的。高层模块指的是调用端，低层模块是具体的实现类。在 Java 中，依赖倒置准则是指模块间的依赖是通过形象来产生的，实现类之间不产生间接的依赖关系，其依赖关系是通过接口是来实现的。这就是俗称的面向接口编程。

咱们上面有一个例子来讲述这个问题。这个例子是工人用锤子来修理货色。咱们的代码如下：

public class Hammer {public String function() {return "用锤子修理货色";}
}

public class Worker {public void fix(Hammer hammer) {System.out.println("工人" + hammer.function());
    }

    public static void main(String[] args) {new Worker().fix(new Hammer());
    }
}

这个是一个很简略的例子，然而如果咱们要新减少一个性能，工人用螺丝刀来修理货色，在这个类，咱们发现是很难做的。因为咱们 Worker 类依赖于一个具体的实现类 Hammer。所以咱们用到面向接口编程的思维，改成如下的代码：

public interface Tools {public String function();
}

而后咱们的 Worker 是通过这个接口来与其余细节类进行依赖。代码如下：

public class Worker {public void fix(Tools tool) {System.out.println("工人" + tool.function());
    }

    public static void main(String[] args) {new Worker().fix(new Hammer());
        new Worker().fix(new Screwdriver());
    }
}

咱们的 Hammer 类与 Screwdriver 类实现这个接口：

public class Hammer implements Tools {public String function() {return "用锤子修理货色";}
}

public class Screwdriver implements Tools {
    @Override
    public String function() {return "用螺丝刀修理货色";}
}

这样，通过面向接口编程，咱们的代码就有了很高的扩展性，升高了代码之间的耦合度，进步了零碎的稳定性。

接口隔离准则

接口隔离准则的定义是：

客户端不应该依赖他不须要的接口

换一种说法就是类间的依赖关系应该建设在最小的接口上。咱们通过一个例子来阐明。咱们晓得在 Java 中一个具体类实现了一个接口，那必然就要实现接口中的所有办法。如果咱们有一个类 A 和类 B 通过接口 I 来依赖，类 B 是对类 A 依赖的实现，这个接口 I 有 5 个办法。然而类 A 与类 B 只通过办法 1,2,3 依赖，而后类 C 与类 D 通过接口 I 来依赖，类 D 是对类 C 依赖的实现然而他们却是通过办法 1,4,5 依赖。那么在实现接口的时候，类 B 就要有实现他不须要的办法 4 和办法 5，而类 D 就要实现他不须要的办法 2 和办法 3。这几乎就是一个劫难的设计。

所以咱们须要对接口进行拆分，就是把接口分成满足依赖关系的最小接口，类 B 与类 D 不须要去实现与他们无关接口办法。比方在这个例子中，咱们能够把接口拆成 3 个，第一个是仅仅有办法 1 的接口，第二个接口是蕴含 2,3 办法的，第三个接口是蕴含 4,5 办法的。这样，咱们的设计就满足了接口隔离准则。

以上这些设计思维用英文的第一个字母能够组成 SOLID，满足这个 5 个准则的程序也被称为满足了 SOLID 准则。

迪米特准则

迪米特准则也被称为最小常识准则，他的定义：

一个对象应该对其余对象放弃最小的理解。

因为类与类之间的关系越亲密，耦合度越大，当一个类产生扭转时，对另一个类的影响也越大，所以这也是咱们提倡的软件编程的总的准则：低耦合，高内聚。迪米特法令还有一个更简略的定义：

只与间接的敌人通信。首先来解释一下什么是间接的敌人：每个对象都会与其余对象有耦合关系，只有两个对象之间有耦合关系，咱们就说这两个对象之间是敌人关系。耦合的形式很多，依赖、关联、组合、聚合等。其中，咱们称呈现成员变量、办法参数、办法返回值中的类为间接的敌人，而呈现在局部变量中的类则不是间接的敌人。也就是说，生疏的类最好不要作为局部变量的模式呈现在类的外部。

这里咱们能够用一个现实生活中的例子来解说一下。比方咱们须要一张 CD, 咱们可能去音像店去问老板有没有咱们须要的那张 CD，老板说当初没有，等有的时候你们来拿就行了。在这里咱们不须要关怀老板是从哪里，怎么取得的那张 CD，咱们只和老板（间接敌人）沟通，至于老板从他的敌人那里通过何种条件失去的 CD，咱们不关怀，咱们不和老板的敌人（陌生人）进行通信，这个就是迪米特的一个利用。说白了，就是一种中介的形式。咱们通过老板这个中介来和真正提供 CD 的人产生分割。

总结

到这里，面向对象的六大准则，就写完了。咱们看进去，这些准则其实都是应答一直扭转的需要。每当需要变动的时候，咱们利用这些准则来使咱们的代码改变量最小，而且所造成的影响也是最小的。

然而咱们在看这些准则的时候，咱们会发现很多准则并没有提供一种公式化的论断，而即便提供了公式化的论断的准则也只是倡议去这样做。这是因为，这些设计准则原本就是从很多理论的代码中提取进去的，他是一个教训化的论断。怎么去用它，用好他，就要依附设计者的教训。

否则一味者去应用设计准则可能会使代码呈现适度设计的状况。大多数的准则都是通过提取出形象和接口来实现，如果产生适度的设计，就会呈现很多抽象类和接口，减少了零碎的复杂度。让原本很小的我的项目变得很宏大，当然这也是 Java 的个性（任何的小我的项目都会做成中型的我的项目）。