/MyCAT/-JDBC 所有源码分析文章列表 /MyCAT/-JDBC 中文注释源码地址 您对源码的疑问，每条留言都会细心解答。 即使您不知道如何阅读源代码，也可以寻求建议。 新源码分析文章实时通知。 每周更新一篇文章左右。 认真的源码交流微信群。
这是设计模式系列开头的第一篇文章。 也是我学习设计模式过程的一个总结。 本文主要讲一下面向对象设计中我们应该遵循的六个原则。 只有掌握了这些原理，我们才能更好地理解设计模式。 接下来我们将介绍以下6个内容。
单一责任原则
单一责任原则的定义是，对于一个类来说，他的改变应该只有一个原因。 也就是说，一个类应该只负责一件事。 如果一个类负责两个不同的事情，方法M1和方法M2，当M1方法发生变化时，我们需要修改这个类的M1方法，但此时，M2方法可能不起作用。 这不是我们所期望的，但由于这种设计，这种情况很有可能发生。 所以这时候我们需要将M1方法和M2方法分成两个类。 让每个类只关注自己的方法。
单一职责原则的好处如下：
它可以降低类的复杂性。 一个类只负责一项职责，这样逻辑就简单很多，提高了类的可读性和系统的可维护性，因为不会有其他奇怪的方式干扰我们对这个类含义的理解。 当发生变化时，可以将变化的影响降到最低，因为修改只会在这个类中进行。
开闭原理
开闭原则，就像单一责任原则一样，是一个非常基本且普遍常识的原则。 开闭原则的定义是软件中的对象（类、模块、函数等）应该对扩展开放，但对修改关闭。
当需求发生变化时，我们需要修改代码。 这时候我们应该尝试扩展原有的代码，而不是修改原有的代码，因为这可能会带来更多的问题。
这个原则和单一职责原则一样，是一个大家都这么认为但没有具体说明如何去做的原则。
开闭原则可以通过某种方式来保证。 我们使用抽象来构建框架，并使用实现来扩展细节。 这样，当发生修改时，我们直接使用抽象派生一个具体的类来实现修改。
里氏替换原则
里氏替换原理是一个非常有用的概念。他的定义
如果对于每个类型为 T1 的对象 o1，都有一个类型为 T2 的对象 o2，使得 T1 定义的所有程序 P 在所有对象 o1 被替换为 o2 时都不会改变其行为，则类型 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());
}
}
这是一个非常简单的例子，但是如果我们想添加一个新的功能，工人用螺丝刀来修理东西，在这个类中，我们发现很难做到。 因为我们的类依赖于一个具体的实现类。 于是我们采用面向接口编程的思想，改成如下代码：
public interface Tools {
public String function();
}
然后我们通过这个接口来依赖其他的类。 代码如下所示：
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());
}
}
我们的类用类实现了这个接口
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来组成，满足这五个原则的程序也称满足SOLID准则。
德米特原理
德墨忒尔原理也称为最小知识原理，他的定义
一个对象应该保留其他对象的最少知识。
因为类之间的关系越密切，耦合程度就越大，而当一个类发生变化时，对另一个类的影响就越大，所以这也是我们提倡的软件编程的总原则：低耦合，高内聚。也是德米特定律的一个更简单的定义
只与直接的朋友交流。 首先解释一下什么是直接友元：每个对象都与其他对象存在耦合关系。 只要两个对象之间存在耦合关系，我们就说这两个对象是朋友。 耦合的方式有很多种，比如依赖、关联、组合、聚合等，其中，我们把成员变量、方法参数、方法返回值中出现的类称为直接友元，而出现的类称为直接友元。局部变量不是直接的啦。 也就是说，不熟悉的类最好不要作为局部变量出现在类内部。
这里我们可以用一个现实生活中的例子来解释。 例如，如果我们需要一张CD，我们可能会去音像店询问老板是否有我们需要的CD。 在这里我们不需要关心boss从哪里以及如何得到CD。 我们只和老板（直接朋友）交流。 至于老板是在什么条件下从他的朋友那里得到CD的，我们并不关心。 我们不同意。 老板的朋友（陌生人）沟通，这是的一个应用。 说白了，就是一种中介的方式。 我们利用老板作为中间人来联系实际提供CD的人。
总结
至此，面向对象的六大原则就讲完了。 我们可以看到，这些原则实际上是在响应不断变化的需求。 每当需求发生变化时，我们都会使用这些原则来最大限度地减少代码更改，并将影响降到最低。 但当我们审视这些原则时，我们会发现，很多原则并没有提供公式化的结论，甚至提供公式化结论的原则也只是建议而已。 这是因为这些设计原则最初是从很多实际代码中提炼出来的，他是一个经验结论。 如何使用、用好它，取决于设计者的经验。 否则，盲目使用设计原则可能会导致代码的过度设计。 大多数原理都是通过提取抽象和接口来实现的。 如果设计过多，就会出现很多抽象类和接口，增加系统的复杂度。 让原来的小项目变得非常大，当然这也是Java的一个特性（任何小项目都会被做成中型项目）。
