单一职责原则
(Single Responsibility Principle, SRP)
一个类只负责一个功能领域中的相应职责
一个类只有一个引起它发生变化的原因
是实现“高内聚，低耦合”的基本原则
PS:如同一个人一样，分配的工作不能太多，否则一天到晚虽然忙忙碌碌的，但效率却高不起来。
开闭原则/开放封闭原则<br>(Open-Closed Principle, OCP)
软件实体应对扩展开放，而对修改关闭
软件实体尽量在不修改代码的情况下进行扩展
为了满足开闭原则，需要对系统进行抽象化的关键
软件开发中一般不把对配置文件的修改认为是对系统源代码的修改
PS:一个网络模块，原来只服务端功能，而现在要加入客户端功能，<br>那么应当在不用修改服务端功能代码的前提下，就能够增加客户端功能的实现代码，这要求在设计之初，就应当将服务端和客户端分开，公共部分抽象出来。
替换原则/里氏代换原则<br>(Liskov Substitution Principle, LSP)
所有引用基类对象的地方能够透明地使用其子类的对象
在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常，反过来则不成立
在程序中尽量使用基类类型来定义对象，而在运行时再确定其子类类型
里氏代换原则是实现开闭原则的重要方式之一
PS:比如：公司搞年度晚会，所有员工可以参加抽奖，那么不管是老员工还是新员工，<br>也不管是总部员工还是外派员工，都应当可以参加抽奖，否则这公司就不和谐了。
合成复用原则
(Composite Reuse Principle, CRP)
尽量使用对象组合，而不是继承来达到复用的目的
如果两个类之间是“Has-A”的关系应使用组合或聚合，如果是“Is-A”关系可使用继承
依赖原则/依赖倒转原则<br>(Dependence Inversion Principle, DIP)
抽象不应该依赖于细节，细节应该依赖于抽象（具体依赖抽象，上层依赖下层）
针对接口编程，而不是针对实现编程
PS：假设B是较A低的模块，但B需要使用到A的功能，这个时候，B不应当直接使用A中的具体类： 而应当由B定义一抽象接口，并由A来实现这个抽象接口，B只使用这个抽象接口：这样就达到<br>了依赖倒置的目的，B也解除了对A的依赖，反过来是A依赖于B定义的抽象接口。
接口隔离原则
(Interface Segregation Principle, ISP)
使用多个专门的接口，而不使用单一的总接口
客户端不应该依赖那些它不需要的接口
接口不能太小，如果太小会导致系统中接口泛滥，不利于维护
接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便
迪米特法则/最少知识原则<br>(Law of Demeter, LoD)
一个软件实体应当尽可能少地与其他实体发生相互作用
迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系
不要和“陌生人”说话、只与你的直接朋友通信等，在迪米特法则中，对于一个对象，其朋友包括以下几类
当前对象本身(this)
以参数形式传入到当前对象方法中的对象
当前对象的成员对象
如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友
当前对象所创建的对象
应该尽量减少对象之间的交互，如果两个对象之间不必彼此直接通信，那么这两个对象就不应当发生任何直接的相互作用，如果其中的一个对象需要调用另一个对象的某一个方法的话，可以通过第三者转发这个调用。
在类的划分上，应当尽量创建松耦合的类，类之间的耦合度越低，就越有利于复用，一个处在松耦合中的类一旦被修改，不会对关联的类造成太大波及
在类的结构设计上，每一个类都应当尽量降低其成员变量和成员函数的访问权限
在类的设计上，只要有可能，一个类型应当设计成不变类；在对其他类的引用上，一个对象对其他对象的引用应当降到最低
