1、单一职责原则（Single Responsibitity Principle）
一个类或者模块只负责完成一个职责；
【实例】
上面这个类，当此类只是用来展示用户信息，则设计符合单一职责；当此用户的地址经常需要使用，比如电商平台类的项目，则需要将地址信息分离出来才符合单一职责。
1.1 如何判断一个类是否违反单一职责
- 类中代码行数、函数、属性过多
- 类依赖的其他类过多（如果某个 service 类需要依赖多个不同功能的 service 类来完成一个复杂的业务逻辑，但自身的职责仍然是单一的，那么这也是符合单一职责原则的）
- 私有方法过多
- 类中的大量的方法总是操作类中的几个属性（这种时候这几个属性可能构成独立职责）
2、开闭原则（Open Close Principle）
软件当中的对象、类、模块和函数对扩展应当开放，对于修改应该封闭；
【实例】
系统A与系统B之间进行数据传输使用的是427版本的协议，一年以后对427版本的协议进行了修正；设计时应该考虑的数据传输协议的可变性，抽象出具有报文解译、编制、校验等所有版本协议使用的通用方法 ；
2.1 如何保证开闭原则的实现
需要培养顶层设计思维：
- 抽象意识：要求我们在编写代码时尽量定义抽象（如接口或抽象类），而不是具体的实现；这使得我们能够在需要扩展功能时，通过实现新的具体类而不是修改已有类的方式来实现。
- 封装意识：要求我们将变化的细节封装起来，通过稳定的接口对外提供服务。这样，当需要更改内部实现时，对外部使用者的影响最小。
- 扩展意识：设计灵活的体系结构，使系统能够通过添加新代码来实现扩展，而不是修改现有代码。
3、里氏替换原则（Liskov Substitution Principle）
子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。
【实例】
如在一个商城项目中, 定义结算接口Istrategy，该接口有三个具体实现类，分别为 PromotionalStrategy （满减活动，两百以上打八折）、RebateStrategy （打折活动）、 ReduceStrategy（返现活动）
结算接口与三个实现类：
public interface Istrategy {public double realPrice(double consumePrice);
}public class PromotionalStrategy implements Istrategy {public double realPrice(double consumePrice) {if (consumePrice > 200) {return 200 + (consumePrice - 200) * 0.8;} else {return consumePrice;}}
}
public class RebateStrategy implements Istrategy {private final double rate;public RebateStrategy() {this.rate = 0.8;}public double realPrice(double consumePrice) {return consumePrice * this.rate;}
}
public class ReduceStrategy implements Istrategy {public double realPrice(double consumePrice) {if (consumePrice >= 1000) {return consumePrice - 200;} else {return consumePrice;}}
}调用方
public class Context {//使用基类定义对象变量private Istrategy strategy;// 注入当前活动使用的具体对象public void setStrategy(Istrategy strategy) {this.strategy = strategy;}// 计算并返回费用public double cul(double consumePrice) {// 使用具体商品促销策略获得实际消费金额double realPrice = this.strategy.realPrice(consumePrice);// 格式化保留小数点后1位，即：精确到角BigDecimal bd = new BigDecimal(realPrice);bd = bd.setScale(1, BigDecimal.ROUND_DOWN);return bd.doubleValue();}
}4、接口隔离原则（Interface Segregation Principle）
客户端不应该被迫依赖于他不使用的方法。 --《代码整洁之道》
要为各个类建立他们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用；
【实例】
实现删除用户的功能遵照接口隔离原则,为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
将删除接口单独放到另外 一个接口 RestrictedUserService 中, 然后将 RestrictedUserService 只打包提供给后台管理系统来使用。
5、依赖倒置原则（Dependence Inversion Principle）
高层模块不应该依赖于底层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象。
【实例】
假设需要组装一台电脑，需要cpu、硬盘、内存等，具体的配置有多种品牌的选择；
这样设计电脑就可以随意搭配不同品牌配置，使得代码更加灵活；
6、迪米特法则（Law Of Demter）
一个类（模块）对其他的类（模块）有越少的了解越好；
【实例】
如明星与经纪人、粉丝之间的关系
明星不需要对粉丝有过多了解，他们之间的互动通过经纪人来运行；
- 通过中介会避免过于耦合的关系，但是中介多了又会增加复杂性，降低模块之间的通信效率；