单一职责原则——SRP:Single Responsibility Principle
一个类在封装（抽象）时，应该只负责一件事（一个单独的功能）
对于一个类功能过多，庞大，接口过于复杂时候：可以进行类重构，将类中与实现相关的功能的部分
提取出来另外封装成为新的类，然后将新增的类加入到原有的类中，作为成员或者方法调用。
开-闭原则——OCP:Open-Closed Principle
一个类应该“对扩展开放，对修改关闭”
当项目进行到后期，关闭对修改的需求，不能修改这个类的任何接口或者实现内容，但是，当增加系统功能时候，又不能置之不理，
所以必须对功能的增加保护开放——功能接口话，将系统的功能的“操作方法”,向上提升，抽象化为接口，将功能的实现，向下移到子类中。
因此增加系统的工嗯那个便是增加子类。
里氏替换原则——LSP:Liskov Substitution Principle
子类必须能够替换父类
如果按照这个设计原则去实现一个又多层继承的类群组，那么起中的父类通常是接口类或者可被继承的类。父类中包含了可以被子类
重新实现的方法，而客户端使用的操作接口也是由父类来定义的。 客户端在使用的过程中，必须不能使用到对象强制类型转换的语句，客户
端也不应该知道，目前使用的对象是那一个类实现的，至于使用那个子类的对象来替换父类对象，则是由类本身的对象产生机制来决定，外界
无法得知。里氏替换原则基本也是对于开闭原则提供了一个实现的法则，说明如何设计才能保持正确的需求开放。
依赖倒置原则——DIP:Dependence Inversion Principle
高层模块不应该依赖于低层模块，两者都应该依赖于抽象概念
抽象接口不应该依赖于实现，而实现应该依赖于抽象接口
如计算机的USB为例，USB为接口，计算机为高层模块，U盘，存储卡，手机为低层模块，USB接口则为抽象接口，当高层模块定义了
沟通接口后，低层模块的沟通就应该是通过接口进行，在具体的实现上面，接口可能是一个类的变量或对象的引用来表示。注意，在使用这个
变量或者对象的引用的过程中，布恩那个做任何的类型转换。而且，子类在重新实现时候，都要按照接口类所定义的方法实现，不应该新增其
他方法，让高层模块有利用类型转换的方式去调用的机会。
接口隔离原则——ISP:Interface Segregation Priciple
客户端不应该被迫使用它们用不到的接口方法，当项目中出现了一个负责主要功能的类，而且这个类还必须负责跟其他子类进行沟通
时候，针对每一个子系统的需求，主要类就必须增加对应的方式，但是，增加越多的方法就等于增加类的接口复杂度。解决方法：功能的
切分，接口的简化，或者运用设计模式重新规划。
最少知识原则——LKP:Least Knowledge Principle
当设计实现一个类时，这个类应该越少使用到其他类提供的功能越好。
也就是说当这个类能够只靠自身的”知识”去完成功能的话，那么就相对地减少与其他对象知识的“依赖度”。这样的好处是减少了这个类
与其他类的耦合度（依赖度），换一个角度就是增加了这个类被不同项目共享的可能性，这将会提高类的重用性。
组合优于继承的思想——少用继承多用组合原则
在实现一个功能的时候，如果会用到其他的类的时候，我们会优先选择用对象的组合方式去实现，而少用继承，继承会带来一些问题，
会使类中包含一些可能用不到的，也就是多余的东西。同样不符合最少知识原则。