### Java设计模式学习笔记
#### 1. 设计模式的七大原则
##### 1.1 设计模式的目的
设计模式是一种解决特定问题的通用解决方案，它可以帮助开发人员编写出更高质量、更容易维护和扩展的代码。设计模式的目标在于提高代码的可重用性、可读性、可扩展性、可靠性和灵活性，同时降低系统的耦合性，提高内聚性。通过这些设计原则的应用，可以确保软件系统具有良好的结构和性能。
- **代码重用性**：减少重复编写相同的代码逻辑，提升开发效率。
- **代码可读性**：遵循一定的编码规范，使得他人或未来的自己能够更容易地理解和维护代码。
- **可扩展性**：随着业务需求的变化，能够快速地添加新功能而不破坏原有系统。
- **可靠性**：增加新功能时不影响现有的功能稳定性。
- **高内聚低耦合**：模块内部紧密相关，模块之间相对独立，减少相互间的依赖关系。
##### 1.2 设计模式的七大原则
设计模式中有七个重要的原则，它们是指导我们在实际开发过程中如何组织和设计代码的重要指南。
- **单一职责原则**：一个类应该只有一个引起它变化的原因。
- **接口隔离原则**：客户端不应该被迫依赖它不使用的方法。
- **依赖倒置原则**：高层次的模块不应该依赖于低层次的模块，二者都应该依赖于抽象。
- **里式替换原则**：子类型必须能够替换掉它们的基类型。
- **开闭原则**：软件实体应该是对扩展开放的，对修改关闭的。
- **迪米特法则**：一个对象应当尽可能少地与其他对象发生交互。
- **合成/聚合复用原则**：尽量使用对象组合而不是继承来达到复用的目的。
##### 1.3 单一职责原则
单一职责原则（Single Responsibility Principle, SRP）强调一个类应该仅有一个引起它变化的原因。这意味着每个类应当聚焦于完成一个明确的任务，而避免承担过多的责任。
- **单一职责介绍**：单一职责原则是针对类的，即一个类应该只负责一项职责。例如，类 `A` 如果包含两个不同的职责：职责1和职责2，那么当职责1发生变化时可能会导致职责2无法正常工作。为了遵循SRP，我们需要将类 `A` 分解成两个类 `A1` 和 `A2`，各自负责一个职责。
- **应用示例**
- **初始案例**：考虑一个交通工具类 `Vehicle`，它最初只负责汽车的运行逻辑。随后增加了轮船和飞机的运行逻辑，导致这个类承担了过多的职责。
```java
public class Vehicle {
public void run(String vehicleName) {
System.out.println(vehicleName + "在公路上跑");
}
}
```
- **分解后的案例**：为了解决这个问题，我们可以将 `Vehicle` 类分解为多个子类，每个子类负责一种交通工具的运行逻辑。例如，创建 `CarVehicle`、`SteamerVehicle` 和 `AirVehicle` 类。
```java
public class CarVehicle {
public void run(String vehicleName) {
System.out.println(vehicleName + "在公路上跑");
}
}
public class SteamerVehicle {
public void run(String vehicleName) {
System.out.println(vehicleName + "在大海上航行");
}
}
public class AirVehicle {
public void run(String vehicleName) {
System.out.println(vehicleName + "在天空中飞");
}
}
```
- **方法拆分案例**：除了通过类来拆分职责外，还可以考虑在同一个类中使用不同的方法来处理不同的场景，这样也符合单一职责原则的精神。
```java
public class Vehicle {
public void runOnRoad(String vehicleName) {
System.out.println(vehicleName + "在公路上跑");
}
public void sailOnSea(String vehicleName) {
System.out.println(vehicleName + "在大海上航行");
}
public void flyInSky(String vehicleName) {
System.out.println(vehicleName + "在天空中飞");
}
}
```
通过以上示例可以看出，单一职责原则有助于提高代码的可维护性和可扩展性，降低耦合性，使系统更加灵活。在实际项目中，我们应该根据具体的需求和场景选择合适的方法来应用这一原则。
