GRASP模式的9大核心原则如何提升你的软件设计能力？

GRASP模式中的9个基本模式

在面向对象设计与软件架构领域,GRASP模式（General Responsibility Assignment Software Patterns）是一组核心原则，帮助开发者合理分配系统职责，提升代码的可维护性、扩展性和复用性，以下将逐一解析GRASP的9个基本模式，结合实际场景说明其应用价值。

创建者（Creator）

核心思想：对象的创建职责应分配给与其关系最密切的类。

• 典型场景：如果类A包含类B的对象、聚合类B的对象，或直接使用类B的对象，则由类A负责创建类B的实例。
• 示例：购物车（ShoppingCart）类应负责创建购物车项（CartItem）对象。
• 优势：避免创建逻辑分散，降低系统耦合。

信息专家（Information Expert）

核心思想：职责应分配给拥有完成该职责所需信息的类。

• 典型场景：订单总价的计算应由订单类（Order）完成，因为订单类包含商品列表和单价信息。
• 优势：减少跨类交互，提升内聚性。

低耦合（Low Coupling）

核心思想：尽量减少类之间的依赖关系，避免牵一发而动全身。

• 典型场景：用户身份验证模块（AuthService）应通过接口与日志模块（Logger）交互，而非直接依赖具体实现类。
• 优势：增强系统灵活性，降低修改成本。

控制器（Controller）

核心思想：将系统事件的接收与协调职责分配给一个中间类（控制器），而非界面层或实体类。

• 典型场景：处理用户提交订单的请求，应由OrderController协调订单创建、库存更新等操作。
• 优势：分离界面逻辑与业务逻辑，提高可测试性。

高内聚（High Cohesion）

核心思想：一个类的职责应高度相关，避免“万能类”的出现。

• 典型场景：将文件读取（FileReader）和文件解析（FileParser）分为两个类，而非合并为一个“FileProcessor”。
• 优势：提升代码可读性，减少单点故障。

多态性（Polymorphism）

核心思想：通过多态机制处理基于类型差异的行为，避免冗余的条件判断。

• 典型场景：支付方式（PayPal、CreditCard）的不同处理逻辑应通过实现同一接口（IPayment）来管理。
• 优势：简化代码结构，支持开闭原则（对扩展开放，对修改关闭）。

纯虚构（Pure Fabrication）

核心思想：为减少耦合或提高内聚，虚构一个“中间类”来承担本不属于领域模型的职责。

• 典型场景：数据库操作类（DBHelper）并非业务实体，但用于集中管理数据库连接与查询。
• 优势：隔离技术细节，聚焦业务逻辑。

间接性（Indirection）

核心思想：通过引入中间层（如接口、代理类）解耦两个直接交互的类。

• 典型场景：使用消息队列（MessageQueue）解耦订单生成系统与物流系统。
• 优势：增强系统扩展性，支持异步通信。

防止变异（Protected Variations）

核心思想：识别系统中可能变化的点，通过抽象隔离变化，保障核心逻辑稳定。

• 典型场景：通过依赖注入（Dependency Injection）将数据库类型（MySQL、MongoDB）的差异封装在接口（IDatabase）背后。
• 优势：降低需求变更对系统的影响，提升鲁棒性。

GRASP模式的应用价值

GRASP模式的本质是职责驱动设计（Responsibility-Driven Design），通过规范化的原则解决软件设计中“谁该做什么”的核心问题，其价值体现在：

• 提升代码质量：清晰的职责划分减少冗余代码和潜在冲突；
• 降低维护成本：高内聚、低耦合的设计使修改局部化；
• 加速团队协作：统一的模式语言便于沟通与文档化。

引用说明 参考自Craig Larman的《Applying UML and Patterns》及GRASP设计原则的权威技术文档，结合实践案例进行解读。