设计模式概述：为什么、是什么与如何应用
引言：设计模式真的有用吗？
在日常开发中，我们常常会听到关于设计模式的两种截然不同的观点：
- 观点A：设计模式没什么用。在小公司或快速迭代的项目中，追求的是开发速度和可运行性，使用设计模式只会增加工作量。
- 观点B：设计模式非常有用。它能使代码逻辑更清晰，实现解耦，让后续更新和维护变得更加容易。
那么，哪种观点是正确的呢？
个人见解：
设计模式的确需要通过增加一定的代码量来换取更好的逻辑结构、可扩展性和解耦性，这可能会延长项目的初期开发周期。因此，在不同的项目环境下，我们应根据实际情况做出选择：
- 如果是紧急项目或后期不需要频繁维护和更新的项目，过度使用设计模式反而会增加不必要的复杂度。
- 但如果项目后期需要频繁迭代和扩展，合理运用设计模式能显著提升代码的可维护性和灵活性。
总结：选择适合当前情境的最优方案，而不是为了用设计模式而用。
一、设计模式是什么？
设计模式是软件系统设计中针对常见场景的解决方案，用于解决功能逻辑开发中的共性问题。它们不是具体代码，而是对一类问题的抽象总结和最佳实践。
二、设计模式的起源
设计模式的概念最早源于建筑师克里斯托弗·亚历山大（Christopher Alexander）的著作《建筑模式语言》（A Pattern Language）。他提出城市与建筑的设计可以基于一系列可复用的“模式”单元。软件行业受其启发，将其思想引入软件开发中，形成如今我们所学的设计模式。
三、我们学设计模式到底学什么？
很多人误以为学习设计模式就是学习怎么写代码，其实不然。设计模式是前人总结的、用于解决某一类共性问题的经验与思想。我们学习的重点是：
- 理解其背后的设计原则与适用场景；
- 学会如何灵活运用而非生搬硬套；
- 在实际项目中根据需求变通甚至扩展。
记住：是我们使用设计模式，而不是被设计模式束缚。
四、六大设计原则
设计模式大多建立在这些基本原则之上，理解它们对掌握设计模式至关重要。
1. 单一职责原则（SRP）
-
定义：一个类应该仅有一个引起变化的原因。即一个类只负责一项职责。
-
场景举例：以B站视频清晰度为例：
- 未登录用户只能观看480p；
- 登录用户可观看720p；
- 大会员可享受超高清画质。
应将用户状态判断与视频播放控制分离，避免一个类承担过多职责。
2. 开闭原则（OCP）
- 定义：软件实体应对扩展开放，对修改关闭。即通过扩展来实现新功能，而不是修改原有代码。
- 场景举例：原本的视频播放仅受清晰度限制，若需增加广告播放逻辑，应通过扩展（如继承、实现接口）实现，而非修改原有播放方法。
3. 里氏替换原则（LSP）
- 定义：子类必须能够替换其父类，而不影响程序的正确性。
- 场景举例：蜜雪冰城各分店（子类）都遵循总部的标准流程和服务规范（父类），任何一家分店都可以被替换而不影响整体运营。
4. 迪米特法则（LoD）
- 定义：一个对象应当对其他对象有尽可能少的了解，降低类之间的耦合度。
- 场景举例：公司领导只需关心各部门的汇报结果，而不需了解每个员工的具体工作内容。
5. 接口隔离原则（ISP）
- 定义：不应强迫客户端依赖它们不使用的接口。应将庞大臃肿的接口拆分为更小、更具体的接口。
- 场景举例：游戏中的攻击接口可能包含“推塔”、“打兵”、“点人”等方法。应将其拆分为多个专用接口，避免实现类被迫实现不需要的方法。
6. 依赖倒置原则（DIP）
- 定义：高层模块不应依赖低层模块，二者都应依赖于抽象。抽象不应依赖于细节，细节应依赖于抽象。
- 场景举例：领导分配任务时只提供输入要求和期望输出（抽象接口），员工根据接口实现具体功能，而不关心领导如何使用结果。
五、结语
设计模式不是银弹，而是一种思维工具。真正优秀的开发者不是背诵所有模式，而是理解其思想，在合适的场景中灵活运用。希望通过本文，你能对设计模式有一个更清晰、更实用的认识。