【iOS架构进阶指南】：掌握这6种设计模式，轻松应对复杂项目开发

原创 于 2025-10-15 13:45:34 发布 · 808 阅读 · 22 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

第一章：iOS架构设计的核心理念

iOS架构设计以稳定性、可维护性和可扩展性为核心目标，致力于为开发者提供清晰的代码组织方式与高效的开发体验。其设计理念强调职责分离、模块解耦和测试友好性，确保应用在不断迭代中依然保持高质量。

关注点分离

将用户界面、业务逻辑与数据访问分层处理，是iOS架构的基石。通过将不同职责分配到独立组件，提升代码复用率并降低修改风险。

依赖管理原则

良好的架构应避免高层模块直接依赖低层实现。依赖注入（DI）和协议（Protocol）驱动的设计能够有效提升模块间的松耦合性。例如： 
// 定义数据服务协议
protocol DataService {
    func fetchUsers(completion: @escaping ([User]) -> Void)
}

// 视图模型依赖抽象而非具体实现
class UserViewModel {
    private let service: DataService

    init(service: DataService) {
        self.service = service
    }

    func loadUsers() {
        service.fetchUsers { users in
            // 处理用户数据
        }
    }
}
该模式允许在测试时注入模拟服务，提升单元测试覆盖率。

常见架构模式对比

架构优点适用场景
MVC系统默认，上手简单小型项目
MVVM数据绑定清晰，易于测试中大型项目
Coordinator导航逻辑集中管理复杂页面跳转

响应式编程支持

结合 Combine 或 RxSwift 等框架，可实现事件驱动的数据流管理，使状态更新更加直观且易于追踪。
  • 使用 Publisher 和 Subscriber 管理异步事件
  • 通过操作符链式处理数据转换
  • 自动取消订阅避免内存泄漏
graph TD A[View] -- 触发事件 --> B(ViewModel) B -- 请求数据 --> C[Service] C -- 返回结果 --> B B -- 发布状态 --> A

第二章：创建型设计模式的深度解析与应用

2.1 单例模式：全局状态管理的最佳实践

在复杂系统中，全局状态的一致性至关重要。单例模式确保一个类仅存在一个实例，并提供全局访问点，是管理配置、连接池或日志器的首选方案。
经典实现：懒加载与线程安全
type Logger struct {
    message string
}

var instance *Logger
var once sync.Once

func GetLogger() *Logger {
    once.Do(func() {
        instance = &Logger{message: "initialized"}
    })
    return instance
}
该 Go 实现利用 sync.Once 保证初始化仅执行一次，适用于高并发场景。函数 GetLogger() 是唯一获取实例的途径，防止重复实例化。
应用场景对比
场景是否适用单例原因
数据库连接池是资源集中管理，避免重复建立连接
用户会话上下文否每个请求上下文独立，需隔离状态

2.2 工厂方法模式：解耦对象创建与业务逻辑

在面向对象设计中，工厂方法模式通过定义一个用于创建对象的接口，将实例化延迟到子类中，从而实现创建逻辑与使用逻辑的分离。
核心结构
工厂方法模式包含四个关键角色：
  • Product：定义产品接口
  • ConcreteProduct：具体产品实现
  • Creator：声明工厂方法
  • ConcreteCreator：返回具体产品的子类
代码示例
type Product interface {
    GetName() string
}

type ConcreteProductA struct{}

func (p *ConcreteProductA) GetName() string {
    return "Product A"
}

type Creator interface {
    FactoryMethod() Product
}

type ConcreteCreatorA struct{}

func (c *ConcreteCreatorA) FactoryMethod() Product {
    return &ConcreteProductA{}
}
上述代码中，Creator 接口定义了 FactoryMethod()，由 ConcreteCreatorA 实现具体对象的创建。调用者仅依赖抽象接口，无需关心对象构造细节，有效降低模块间耦合度。

2.3 抽象工厂模式：构建可扩展的组件体系

抽象工厂模式用于创建一系列相关或依赖对象的接口，而无需指定其具体类。该模式在需要支持多种产品族时尤为有效，例如不同主题的UI组件库。
核心结构与角色
  • 抽象工厂（Abstract Factory）：声明创建产品族的接口
  • 具体工厂（Concrete Factory）：实现创建具体产品族的方法
  • 抽象产品（Abstract Product）：定义产品类型的接口
  • 具体产品（Concrete Product）：实现抽象产品的具体类
代码示例：跨平台UI组件
type Button interface {
    Render()
}

type Checkbox interface {
    Paint()
}

type UIFactory interface {
    CreateButton() Button
    CreateCheckbox() Checkbox
}
上述接口定义了UI组件的抽象工厂和产品类型。通过实现不同的工厂（如WindowsFactory、MacFactory），可在运行时动态切换整套界面风格，提升系统可扩展性。

2.4 建造者模式：复杂对象构造的优雅实现

模式核心思想
建造者模式用于分离复杂对象的构建过程与表示，使得同一构建过程可以创建不同的表示。它适用于具有多个可选参数或配置步骤的对象构造场景。
典型应用场景
  • 构建包含大量可选字段的配置对象
  • 需要分步初始化且步骤顺序敏感的对象
  • 避免构造函数参数膨胀（telescoping constructor）
代码实现示例

public class Computer {
    private final String cpu;
    private final String ram;
    private final String storage;

    private Computer(Builder builder) {
        this.cpu = builder.cpu;
        this.ram = builder.ram;
        this.storage = builder.storage;
    }

    public static class Builder {
        private String cpu;
        private String ram;
        private String storage;

        public Builder setCPU(String cpu) {
            this.cpu = cpu;
            return this;
        }

        public Builder setRAM(String ram) {
            this.ram = ram;
            return this;
        }

        public Computer build() {
            return new Computer(this);
        }
    }
}
上述代码通过内部静态类 Builder 实现链式调用，逐步设置属性并最终生成不可变对象。构造逻辑清晰，增强了代码可读性与维护性。

2.5 原型模式：高效复制与对象克隆实战

原型模式是一种创建型设计模式，通过复制现有实例来创建新对象，避免重复初始化过程。该模式适用于对象创建成本较高的场景。
核心实现机制
在 Go 中可通过接口定义克隆方法： 
type Prototype interface {
    Clone() Prototype
}

type ConcretePrototype struct {
    Name string
    Data []int
}

func (p *ConcretePrototype) Clone() Prototype {
    // 深拷贝确保数据隔离
    data := make([]int, len(p.Data))
    copy(data, p.Data)
    return &ConcretePrototype{Name: p.Name, Data: data}
}
上述代码中，Clone() 方法返回深拷贝的新对象，确保原始对象与副本之间无引用共享，避免数据污染。
应用场景对比
场景直接构造原型克隆
高频创建开销大效率高
配置对象复用需重复设置一键复制

第三章：结构型设计模式在iOS项目中的落地

3.1 适配器模式：无缝集成第三方SDK的利器

在系统集成中，第三方SDK的接口往往与现有系统不兼容。适配器模式通过封装不兼容接口，使它们能协同工作。
核心结构
适配器模式包含目标接口、适配者类和适配器类。适配器将适配者的接口转换为目标期望的形式。 

type Target interface {
    Request() string
}

type Adaptee struct{}

func (a *Adapee) SpecificRequest() string {
    return "adaptee response"
}

type Adapter struct {
    adaptee *Adaptee
}

func (a *Adapter) Request() string {
    return a.adaptee.SpecificRequest()
}
上述代码中，Adaptee 提供了特定方法，但不符合 Target 接口要求。通过 Adapter 实现 Request() 方法并内部调用 SpecificRequest()，实现接口转换。
应用场景
  • 集成支付SDK（如支付宝、微信）到统一订单系统
  • 对接多个地图服务API时提供一致调用方式

3.2 装饰器模式：动态扩展功能而不修改源码

装饰器模式是一种结构型设计模式，允许在不修改原有对象代码的前提下，动态地添加新功能。它通过组合的方式，将核心逻辑与附加行为分离，提升代码的可维护性与扩展性。
基本实现原理
装饰器通常围绕一个公共接口构建，每个装饰器持有一个组件实例，并在其前后添加逻辑。 

type Component interface {
    Operation() string
}

type ConcreteComponent struct{}

func (c *ConcreteComponent) Operation() string {
    return "基础功能"
}

type Decorator struct {
    component Component
}

func (d *Decorator) Operation() string {
    return "增强功能 -> " + d.component.Operation()
}
上述代码中，Decorator 包装了 Component 接口实例，在保留原始行为的同时，扩展了新的处理逻辑。参数 component 是被装饰的对象，实现了松耦合扩展。
应用场景
  • 日志记录、权限校验等横切关注点
  • HTTP 中间件链式处理
  • IO 流的多层封装（如缓冲、压缩）

3.3 代理模式：实现松耦合通信的经典方案

代理模式通过引入中间代理对象，控制对真实服务的访问，有效降低系统耦合度。
核心结构与角色划分
  • Subject：定义客户端使用的接口
  • RealSubject：实际业务逻辑的执行者
  • Proxy：持有 RealSubject 引用，可附加权限控制、延迟加载等逻辑
代码示例（Go语言）
type Service interface {
    Request() string
}

type RealService struct{}

func (r *RealService) Request() string {
    return "处理请求"
}

type Proxy struct {
    realService *RealService
}

func (p *Proxy) Request() string {
    if p.realService == nil {
        p.realService = &RealService{}
    }
    // 可扩展前置校验、日志记录等
    return "日志:" + p.realService.Request()
}
上述代码中，Proxy 在调用 RealService 前可插入额外行为，实现非侵入式功能增强。

第四章：行为型模式提升代码可维护性

4.1 观察者模式：响应式编程与事件驱动架构

观察者模式是响应式编程的核心基础，它定义了对象间一对多的依赖关系，当一个对象状态改变时，所有依赖者自动收到通知并更新。
核心结构与实现
该模式包含两个关键角色：**主题（Subject）** 和 **观察者（Observer）**。主题维护观察者列表，并提供注册、移除和通知机制。 
type Observer interface {
    Update(data interface{})
}

type Subject struct {
    observers []Observer
}

func (s *Subject) Attach(o Observer) {
    s.observers = append(s.observers, o)
}

func (s *Subject) Notify(data interface{}) {
    for _, o := range s.observers {
        o.Update(data)
    }
}
上述 Go 代码展示了基本结构。`Attach` 方法用于添加观察者，`Notify` 遍历所有观察者并调用其 `Update` 方法传递最新数据，实现松耦合通信。
在事件驱动架构中的应用
现代前端框架如 React 和响应式后端系统广泛采用该模式。通过事件总线或流（Stream），数据变更可自动 propagate 到多个组件或服务，提升系统响应性与可维护性。

4.2 命令模式：将操作封装为可管理的对象

命令模式是一种行为设计模式，它将请求封装为对象，从而使你可以用不同的请求、队列或日志来参数化其他对象。
核心结构与角色
  • Command：声明执行操作的接口
  • ConcreteCommand：绑定接收者与具体动作
  • Invoker：触发命令对象执行请求
  • Receiver：真正执行请求的对象
代码示例
type Command interface {
    Execute()
}

type LightOnCommand struct {
    light *Light
}

func (c *LightOnCommand) Execute() {
    c.light.TurnOn()
}
上述 Go 示例中，LightOnCommand 将开灯操作封装为对象。调用者无需了解灯的实现细节，只需调用 Execute() 方法，实现解耦。
应用场景
命令模式适用于需要支持撤销、重做、事务性操作或延迟执行的系统，如编辑器指令、远程控制、任务队列等。

4.3 策略模式：灵活切换算法与业务规则

策略模式是一种行为设计模式，它允许在运行时动态选择算法或业务规则。通过将算法封装在独立的类中，客户端可以根据上下文自由切换策略，提升系统的可扩展性与维护性。
核心结构与实现方式
策略模式包含三个关键角色：上下文（Context）、策略接口（Strategy）和具体策略（Concrete Strategy）。上下文持有策略引用，而具体策略实现同一接口的不同算法分支。 
type PaymentStrategy interface {
    Pay(amount float64) string
}

type CreditCardStrategy struct{}

func (c *CreditCardStrategy) Pay(amount float64) string {
    return fmt.Sprintf("Paid %.2f via Credit Card", amount)
}

type PayPalStrategy struct{}

func (p *PayPalStrategy) Pay(amount float64) string {
    return fmt.Sprintf("Paid %.2f via PayPal", amount)
}
上述代码定义了支付策略接口及两种实现。Pay 方法接受金额参数并返回支付描述，便于上层逻辑统一调用。
运行时策略切换示例
上下文对象通过注入不同策略实例，实现行为的动态变更： 
type PaymentContext struct {
    strategy PaymentStrategy
}

func (p *PaymentContext) SetStrategy(s PaymentStrategy) {
    p.strategy = s
}

func (p *PaymentContext) ExecutePayment(amount float64) string {
    return p.strategy.Pay(amount)
}
该设计解耦了支付逻辑与具体实现，新增支付方式无需修改上下文代码，符合开闭原则。

4.4 中介者模式：简化复杂页面间的交互逻辑

在前端开发中，多个组件或页面之间频繁通信容易导致耦合度上升。中介者模式通过引入一个中间对象统一管理交互逻辑，降低模块间的直接依赖。
核心思想
将多对多的通信关系转化为一对多结构，所有组件通过中介者进行消息传递，实现解耦。
简易中介者实现
class Mediator {
  constructor() {
    this.channels = {};
  }
  subscribe(channel, callback) {
    if (!this.channels[channel]) this.channels[channel] = [];
    this.channels[channel].push(callback);
  }
  publish(channel, data) {
    if (this.channels[channel]) {
      this.channels[channel].forEach(cb => cb(data));
    }
  }
}
上述代码定义了一个基础中介者类，subscribe 用于注册事件监听，publish 触发对应通道的回调函数，实现松耦合通信。
  • 组件A触发事件时仅通知中介者
  • 组件B订阅该事件，无需知晓A的存在
  • 新增组件C时只需订阅相应频道

第五章：从模式到架构——构建高内聚低耦合的iOS应用

依赖注入提升模块解耦
通过依赖注入（DI），将服务实例传递给视图控制器，避免硬编码依赖。例如，在初始化 ViewModel 时传入数据服务： 

class UserViewModel {
    private let userService: UserServiceProtocol
    
    init(userService: UserServiceProtocol) {
        self.userService = userService
    }
}
协议驱动设计实现职责分离
使用协议定义组件接口，提升可测试性与扩展性。如定义网络层协议：
  • UserServiceProtocol 提供 fetchUser 操作
  • MockUserService 遵循协议用于单元测试
  • 真实环境注入 NetworkUserService 实现
分层架构组织代码结构
采用 Clean Architecture 分层原则组织项目目录：
层级职责示例组件
Domain业务逻辑与实体User, UseCase
Data数据源实现API, CoreData
PresentationUI 与状态管理ViewController, ViewModel
事件总线降低界面通信耦合
使用 NotificationCenter 或自定义 EventCenter 解决模块间通信：

EventCenter.shared.post(.userLoggedIn) 触发登录事件

个人中心页面监听并刷新 UI

通知名称定义在独立枚举中避免拼写错误
StepNexus
关注
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值