概述
设计模式的六大原则是设计模式的基础，了解设计模式的原则，有利于设计模式实际应用的理解 ，在真实使用的时候，一般不太可能一个程序满足所有的设计模式六大原则，或多或少都会有违背设计模的地方，所以不用再写程序的时候强行满足所有设计模式的原则，合适自己的项目的才是最合适的。
开闭原则（Open Close Principle，OCP）
一个设计好的软件框架（类，模块，函数）应该对扩展开放，对修改关闭，对于已经写好的方法或类，应该提供扩展方法，不要修改原本的内容，如果有新的需求，在原有的基础上添加，不可以修改已经写好的内容，提升的代码的稳定性。总之就是写好的代码不要动，只允许扩展不允许修改（这个显然是不太可能的，哪有不修改的代码呢？）
单一职责原则（Single Responsibility Principle，SRP）
一个类应该只包含它自己的内容，或引起的变化，功能明确，比如声音管理器，那它应该只包含声音相关的功能，提供播放，暂停，继续等方法，不应该包含比如，视频播放的功能，这个原则在实际开发中是非常重要的，有利于代码的维护，提高代码的可读性。总之就是，一个类尽量只包含它自己相关的方法和属性。
里氏替换原则（Liskov Substitution Principle,LSP）
这个原则的主要内容就是，子类的可以替代父类，而不影响程序的正确性，简单来说就是，父类使用的地方，直接用子类替换掉，程序不会出问题。
接口隔离原则（Interface Segregation Principle，ISP）
接口隔离原则字面意思，接口应该隔离，我们知道，在继承一个接口的时候，我们都需要实现接口中的方法才行，那为什么需要隔离呢，举个例子，比如人类，有共有的，吃饭，睡觉，喝水的方法，但是人类，却有医生，护士，老师，工程师，程序员等子类，他们都有自己特殊的方法，那我们写个接口，把每个人特殊的方法都加进来，那这个接口就包括，开药，治病，教书，建筑，敲代码，等等等等，那得有多少个方法实现，而且其实每个职业只需要自己的方法就行，其它方法都是空的，所以就需要接口隔离，每个职业只继承自己的接口就行，这个和单一职责原则比较像，我称为单一接口职责原则（这只是我方便记忆的方法，准确的请记ISP哈）。
依赖倒转原则（Dependency Inversion Principle，DIP）
依赖倒转原则比较多的是实用在框架编写中，你写的Base基类不应该依赖于继承与基类的具体事项类，举个例子，你定义了一个UI的基类叫UIBase，然后具体的UI面板继承与UI基类叫XXPanel，但是你在UI基类中却引用到了XXPanel，这就违反了依赖导致原则，如果这个面板销毁了，那UIBase也就会报错，那引用到UIBase的面板都会报错，所以具体的抽象基类，不应该引用任何具体的实现类，可以降低各个模块的耦合性。总之定义基类的时候不可以引用具体的实现类。
迪米特原则（Law of Demeter,LD）
迪米特原则又叫最小知道原则，有名字就可以知道，一个对象应该对另外一个对象有最少的了解，这样做可以降低程序之间的耦合性，举个例子，老师类，和学生类，老师想知道学习的语文成绩是多少，但是方法却提供了，语文，数学，英语，物理，化学等多样信息，这显然是不需要的，所以对一个方法只提供需要的数据。总结，知道自己的就行，不知道的我不想知道。