设计模式
定义：软件开发中，在特定上下文中解决一类常见问题的被证明为有效的最佳实践。可供其他开发者重复使用解决相似问题。
好处：
- 提高代码的可重用性，减少重复代码。
- 提高代码的可维护性，使代码更易于理解和修改。
- 提高代码的可扩展性，使系统更易于适应新的需求或变化。
- 促进团队之间的沟通和协作，因为设计模式为解决问题提供了共同的语言和思路。
总结：
设计模式不应过渡使用，可能会导致代码变得复杂且难以理解，提高了代码抽象性，可能导致系统可维护性降低，使得适得其反。
一、单一职责原则（Single Responsibility Principle，SRP）
一个类或模块应该只有一个修改的理由。即一个类或模块应该只有一个职责。
二、开闭原则（Open/Closed Principle，OCP）
软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。即在不修改已有代码的情况下，通过扩展来实现新的功能或变化。
三、里氏替换原则（Liskov Substitution Principle，LSP）
所有引用基类（父类）的地方必须能够透明地使用其子类的对象。即子类对象可以替换掉父类对象，而程序不会出错或产生异常。
四、迪米特法则（Law of Demeter，LoD）
也称为最少知识原则（Principle of Least Knowledge，PoLK）或者叫作"不要和陌生人说话"（Don't talk to strangers）。⼀个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
五、接口隔离原则（Interface Segregation Principle，ISP）
客户端不应该依赖它不需要的接口。使用多个隔离的接口，比使用单个接口要好，降低类之间的耦合度
六、依赖倒转原则（Dependency Inversion Principle，DIP）
高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖于具体实现，具体实现应该依赖于抽象。也即是面向接口编程。