那就从这里开始吧。
设计模式是以解藕为目的，解决一类问题的方法。
设计模式的六大原则是指导方案，按照这些原则更容易写出低耦合，高内聚的代码，学习设计模式就是学习套路。
设计模式中有一个非常重要的思想：封装变化。把代码中会变化的部分用一些技巧封装起来，设计模式也是在封装某一类问题的变化部分，设计模式的原则能够指导我们去实现和理解设计模式。
设计模式六大原则分别是：
接下来单独说明一下每个原则的基本意义，以下内容整理自互联网。
<h1 id="1">开闭原则</h1>
<b>开闭原则</b>规定“<i>软件中的对象（类，模块，函数等等）应该对于扩展是开放的，但是对于修改是封闭的</i>”，这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的，在这种环境中，改变源代码需要代码审查，单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变，因此无需上述的过程。
<h1 id = "2">单一职责原则</h1>
<b>单一功能原则</b>（Single responsibility principle）规定每个类都应该有一个单一的功能，并且该功能应该由这个类完全封装起来。所有它的（这个类的）服务都应该严密的和该功能平行（功能平行，意味着没有依赖）。把功能（职责）定义为：“改变的原因”，并且总结出一个类或者模块应该有且只有一个改变的原因。一个具体的例子就是，想象有一个用于编辑和打印报表的模块。这样的一个模块存在两个改变的原因。第一，报表的内容可以改变（编辑）。第二，报表的格式可以改变（打印）。这两方面会的改变因为完全不同的起因而发生：一个是本质的修改，一个是表面的修改。单一功能原则认为这两方面的问题事实上是两个分离的功能，因此他们应该分离在不同的类或者模块里。把有不同的改变原因的事物耦合在一起的设计是糟糕的。保持一个类专注于单一功能点上的一个重要的原因是，它会使得类更加的健壮。继续上面的例子，如果有一个对于报表编辑流程的修改，那么将存在极大的危险性，打印功能的代码会因此不工作，假使这两个功能存在于同一个类中的话。
<h1 id="3">接口隔离原则</h1>
<b>接口隔离原则</b>（interface-segregation principles， 缩写：ISP）指明没有客户（client）应该被迫依赖于它不使用方法。接口隔离原则(ISP)拆分非常庞大臃肿的接口成为更小的和更具体的接口，这样客户将会只需要知道他们感兴趣的方法。这种缩小的接口也被称为<b>角色接口</b>（role interfaces）。接口隔离原则(ISP)的目的是系统解开耦合，从而容易重构，更改和重新部署。
<h1 id="4">里氏替换原则</h1>
<b>里氏替换原则</b>(Liskov Substitution Principle LSP) 指任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
<h1 id="5">依赖反转原则</h1>
<b>依赖反转原则</b>（Dependency inversion principle，DIP）是指一种特定的解耦（传统的依赖关系创建在高层次上，而具体的策略设置则应用在低层次的模块上）形式，使得高层次的模块不依赖于低层次的模块的实现细节，依赖关系被颠倒（反转），从而使得低层次模块依赖于高层次模块的需求抽象。
该原则规定：
- 高层次的模块不应该依赖于低层次的模块，两者都应该依赖于抽象接口。
- 抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。
<h1 id="6">迪米特法则</h1>
<b>迪米特法则</b>（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
不登高山，不知天之高也；不临深溪，不知地之厚也
感谢指点、交流、喜欢
