mobile wallpaper 1mobile wallpaper 2mobile wallpaper 3mobile wallpaper 4
1134 字
3 分钟
设计模式与架构模式深度解析
2024-03-10

一、设计模式概述#

设计模式是软件开发中经过验证的解决方案模板。GoF(Gang of Four)将 23 种设计模式分为三大类:

graph TB subgraph "GoF 设计模式体系" A["设计模式"] --> B["创建型<br>5 种"] A --> C["结构型<br>7 种"] A --> D["行为型<br>11 种"] B --> B1["单例模式"] B --> B2["工厂方法"] B --> B3["抽象工厂"] B --> B4["建造者"] B --> B5["原型"] C --> C1["适配器"] C --> C2["桥接"] C --> C3["组合"] C --> C4["装饰器"] C --> C5["门面"] C --> C6["享元"] C --> C7["代理"] D --> D1["策略"] D --> D2["观察者"] D --> D3["命令"] D --> D4["迭代器"] D --> D5["模板方法"] D --> D6["责任链"] D --> D7["其他 5 种"] end

1.1 创建型模式#

创建型模式关注对象的创建过程,将对象的创建和使用分离。

classDiagram class Client { +useProduct() } class Factory { <<interface>> +createProduct() Product } class ConcreteFactoryA { +createProduct() ProductA } class ConcreteFactoryB { +createProduct() ProductB } class Product { <<interface>> +operation() } class ProductA { +operation() } class ProductB { +operation() } Client --> Factory Factory <|.. ConcreteFactoryA Factory <|.. ConcreteFactoryB ConcreteFactoryA --> ProductA ConcreteFactoryB --> ProductB Product <|.. ProductA Product <|.. ProductB
模式用途场景核心思想
单例全局唯一配置、日志私有构造 + 静态实例
工厂方法对象创建依赖注入子类决定实例化
抽象工厂产品族创建UI 组件相关对象统一创建
建造者复杂对象构建SQL Builder分步构建 + 链式调用
原型对象克隆缓存对象复制而非新建

1.2 结构型模式#

结构型模式关注类和对象的组合,形成更大的结构。

flowchart TB subgraph "适配器模式" A1[客户端] --> A2[目标接口] A3[适配器] -.->|实现| A2 A4[被适配者] --> A3 end subgraph "装饰器模式" B1[组件] --> B2[装饰器基类] B3[具体装饰器A] -.->|继承| B2 B4[具体装饰器B] -.->|继承| B2 end subgraph "代理模式" C1[客户端] --> C2[代理] C2 --> C3[真实对象] end
模式用途场景核心思想
适配器接口转换旧接口兼容包装不兼容接口
桥接抽象与实现分离多平台支持组合替代继承
组合树形结构菜单系统统一处理个别与整体
装饰器动态增强日志、缓存包装器链式叠加
门面简化接口统一入口提供高层统一接口
代理间接访问远程调用控制对象访问

1.3 行为型模式#

行为型模式关注对象之间的通信和职责分配。

sequenceDiagram participant C as Client participant S as Context participant SA as StrategyA participant SB as StrategyB C->>S: 设置策略 A C->>S: 执行操作 S->>SA: algorithm() SA-->>S: 结果 C->>S: 设置策略 B C->>S: 执行操作 S->>SB: algorithm() SB-->>S: 结果
模式用途场景核心思想
策略算法切换支付方式算法封装可互换
观察者事件通知消息订阅一对多依赖通知
命令请求封装撤销重做操作对象化
迭代器集合遍历数据处理统一遍历接口
模板方法算法骨架框架扩展固定流程可变步骤
责任链请求处理过滤器链式传递处理

二、SOLID 原则#

SOLID 是面向对象设计的五大原则,详见代码设计的原则中的深入讨论。

2.1 五大原则关系#

graph TB subgraph "SOLID 原则体系" S["单一职责<br>SRP"] --> |"一个类只做一件事"| S1["低耦合"] O["开闭原则<br>OCP"] --> |"扩展开放 修改关闭"| O1["稳定性"] L["里氏替换<br>LSP"] --> |"子类可替换父类"| L1["多态安全"] I["接口隔离<br>ISP"] --> |"接口小而专注"| I1["解耦"] D["依赖倒置<br>DIP"] --> |"依赖抽象不依赖具体"| D1["灵活性"] S1 --> G["高内聚低耦合"] O1 --> G L1 --> G I1 --> G D1 --> G end
原则说明违反表现重构方向
S单一职责类承担过多职责拆分职责
O开闭原则修改现有代码抽象扩展点
L里氏替换子类违反父类行为规范继承关系
I接口隔离接口过于臃肿接口拆分
D依赖倒置依赖具体而非抽象依赖注入

2.2 实践示例#

# 违反 SRP:类承担多个职责
class UserManager:
def create_user(self, name, email):
# 用户创建
pass
def send_email(self, user, message):
# 发送邮件
pass
def generate_report(self):
# 生成报告
pass
# 符合 SRP:职责分离
class UserService:
def create_user(self, name, email):
pass
class EmailService:
def send_email(self, user, message):
pass
class ReportService:
def generate_report(self):
pass
# 违反 OCP:新增类型需要修改现有代码
class DiscountCalculator:
def calculate(self, customer_type, amount):
if customer_type == "regular":
return amount * 0.9
elif customer_type == "vip":
return amount * 0.8
# 新增类型需要修改这里
# 符合 OCP:通过扩展而非修改
from abc import ABC, abstractmethod
class DiscountStrategy(ABC):
@abstractmethod
def calculate(self, amount: float) -> float:
pass
class RegularDiscount(DiscountStrategy):
def calculate(self, amount: float) -> float:
return amount * 0.9
class VIPDiscount(DiscountStrategy):
def calculate(self, amount: float) -> float:
return amount * 0.8
# 新增类型只需添加新类,无需修改现有代码
class SVIPDiscount(DiscountStrategy):
def calculate(self, amount: float) -> float:
return amount * 0.7

三、微服务架构模式#

3.1 服务拆分模式#

graph TB subgraph "单体架构" M["单体应用<br>所有功能一体"] end subgraph "微服务架构" subgraph "按业务能力拆分" U["用户服务"] O["订单服务"] P["支付服务"] I["库存服务"] end subgraph "基础设施" G["API Gateway"] R["服务注册"] C["配置中心"] MQ["消息队列"] end end M -.->|拆分| U M -.->|拆分| O M -.->|拆分| P M -.->|拆分| I G --> U G --> O G --> P G --> I U <--> R O <--> R P <--> R I <--> R
拆分策略说明适用场景优缺点
按业务能力职责分离业务边界清晰清晰但需协调
按子域DDD 分析复杂业务领域精确但复杂
按团队康威定律独立团队交付敏捷但可能分散

3.2 微服务通信模式#

sequenceDiagram participant C as Client participant G as API Gateway participant U as User Service participant O as Order Service participant MQ as Message Queue Note over C,MQ: 同步通信 (REST/gRPC) C->>G: GET /orders/123 G->>U: 验证用户身份 U-->>G: 用户信息 G->>O: 获取订单详情 O-->>G: 订单数据 G-->>C: 响应 Note over C,MQ: 异步通信 (消息队列) C->>G: POST /orders G->>O: 创建订单 O->>MQ: 发布 order.created MQ->>U: 通知用户服务 MQ->>I: 通知库存服务
# 同步通信:REST/gRPC
class UserService:
def __init__(self, http_client):
self.http = http_client
def get_order(self, order_id):
response = self.http.get(f"/orders/{order_id}")
return response.json()
# 异步通信:消息队列
class OrderService:
def __init__(self, message_queue):
self.queue = message_queue
def create_order(self, order):
self.queue.publish("order.created", order)

3.3 服务发现#

# 客户端发现
apiVersion: v1
kind: Service
metadata:
name: user-service
spec:
selector:
app: user
ports:
- port: 80
targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: api-gateway
spec:
type: NodePort
ports:
- port: 80
targetPort: 8080

四、分层架构模式#

4.1 经典三层架构#

graph TB subgraph "三层架构" subgraph "表现层 Presentation" P1["Controller"] P2["REST API"] P3["GraphQL"] end subgraph "业务层 Business" B1["Service"] B2["Domain Model"] B3["Business Logic"] end subgraph "数据层 Data" D1["Repository"] D2["DAO"] D3["ORM"] end subgraph "基础设施 Infrastructure" DB[(Database)] Cache[(Cache)] MQ[(Message Queue)] end end P1 --> B1 P2 --> B1 P3 --> B1 B1 --> B2 B2 --> B3 B3 --> D1 D1 --> D2 D2 --> D3 D3 --> DB D3 --> Cache B3 --> MQ
职责技术示例关注点
表现层用户界面交互Controller、API请求处理
业务层业务逻辑处理Service领域逻辑
数据层数据持久化Repository、DAO数据存取

4.2 六边形架构(端口与适配器)#

graph TB subgraph "六边形架构 Hexagonal Architecture" subgraph "外部世界" W1["Web UI"] W2["Mobile App"] W3["CLI"] W4["外部 API"] end subgraph "适配器层" A1["REST Adapter"] A2["GraphQL Adapter"] A3["CLI Adapter"] A4["External API Adapter"] end subgraph "端口层" P1["端口 IN<br>驱动端口"] P2["端口 OUT<br>被驱动端口"] end subgraph "应用核心" CORE["领域模型<br>业务逻辑<br>用例"] end subgraph "基础设施适配器" IA1["数据库适配器"] IA2["缓存适配器"] IA3["消息队列适配器"] end end W1 --> A1 W2 --> A2 W3 --> A3 W4 --> A4 A1 --> P1 A2 --> P1 A3 --> P1 A4 --> P1 P1 --> CORE CORE --> P2 P2 --> IA1 P2 --> IA2 P2 --> IA3
组件说明示例
端口 IN驱动端口(API)用例接口
端口 OUT被驱动端口(DB)仓储接口
适配器 IN接收外部请求REST Controller
适配器 OUT与外部系统交互数据库实现
应用核心业务逻辑领域模型

4.3 架构对比#

graph LR subgraph "架构演进" A["三层架构"] --> B["六边形架构"] B --> C["洋葱架构"] C --> D["整洁架构"] end A -.->|"依赖方向"| E["外层依赖内层"] B -.->|"依赖倒置"| F["核心独立于框架"] C -.->|"层次化"| G["领域模型居中"] D -.->|"统一抽象"| H["关注业务规则"]

五、响应式架构模式#

5.1 响应式宣言#

graph TB subgraph "响应式系统特性" R["响应式<br>Responsive"] --> |"及时响应"| U["用户满意"] RES["弹性<br>Resilient"] --> |"故障恢复"| U E["弹性伸缩<br>Elastic"] --> |"资源优化"| U M["消息驱动<br>Message Driven"] --> |"松耦合"| RES M --> |"异步非阻塞"| E M --> |"背压控制"| R end
# 响应式系统特性
class ReactiveSystem:
def __init__(self):
self.principles = {
"responsive": "及时响应用户",
"resilient": "故障时仍可响应",
"elastic": "负载变化时弹性伸缩",
"message_driven": "异步通信松耦合"
}

5.2 命令查询职责分离(CQRS)#

graph TB subgraph "CQRS 架构" subgraph "Command Side 写端" C1["Command"] C2["Command Handler"] C3["Aggregate"] C4["Write Model"] C5["Event Store"] end subgraph "Query Side 读端" Q1["Query"] Q2["Query Handler"] Q3["Read Model"] Q4["Materialized View"] end subgraph "Event Bus" EB["事件总线"] end end C1 --> C2 C2 --> C3 C3 --> C4 C4 --> C5 C2 --> EB EB --> Q3 Q3 --> Q4 Q1 --> Q2 Q2 --> Q4
# CQRS 示例
class CommandHandler:
def handle(self, command):
"""处理写操作"""
if isinstance(command, CreateOrderCommand):
return self.create_order(command)
elif isinstance(command, UpdateOrderCommand):
return self.update_order(command)
class QueryHandler:
def handle(self, query):
"""处理读操作"""
if isinstance(query, GetOrderQuery):
return self.get_order(query.order_id)
elif isinstance(query, ListOrdersQuery):
return self.list_orders(query.filters)

六、架构选择指南#

6.1 架构模式对比#

graph TB subgraph "架构选择决策树" START["项目复杂度"] --> LOW{"低复杂度?"} LOW -->|是| MONO["单体架构"] LOW -->|否| MED{"中等复杂度?"} MED -->|是| LAYERED["分层架构"] MED -->|否| HIGH{"高复杂度?"} HIGH -->|是| DOMAIN{"领域复杂?"} HIGH -->|否| MICRO["微服务架构"] DOMAIN -->|是| HEX["六边形架构<br>+ DDD"] DOMAIN -->|否| MICRO MONO --> TEAM{"团队规模?"} LAYERED --> TEAM HEX --> TEAM MICRO --> TEAM TEAM -->|小型| SIMPLE["简单优先"] TEAM -->|大型| SCALE["考虑扩展性"] end

6.2 总结对比#

模式类别适用场景优点缺点
设计模式代码层面的可复用方案提高代码质量过度使用复杂化
分层架构传统 Web 应用结构清晰层间耦合
微服务架构大规模分布式系统独立部署扩展运维复杂
六边形架构领域驱动设计业务与技术解耦学习曲线陡
响应式架构高并发实时系统高性能高可用调试困难

架构选择原则

  1. 简单优先:先简单后复杂,避免过度设计
  2. 业务适配:匹配业务复杂度,不盲目追新
  3. 团队匹配:考虑团队能力,选择合适的架构
  4. 演进思维:预留扩展空间,支持渐进式演进

支持与分享

如果这篇文章对你有帮助,欢迎支持作者或分享给更多人

设计模式与架构模式深度解析
https://blog.souloss.com/posts/programming/software-architecture-and-design-patterns/
作者
Souloss
发布于
2024-03-10
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时