ios中常见的设计原则和设计模式

七大设计原则

1:开闭原则

对扩展开放,对修改关闭,在设计模块的时候,使模块在不被修改的前提下可以扩展功能

2:依赖倒置原则

实现尽量依赖抽象,不依赖具体实现

(1)高层模块不应该依赖底层模块,两者都应该依赖于抽象

(2)抽象不应该依赖于细节,细节应该依赖于抽象

3:单一职责原则

对于一个类而言,应该只存在一个可以一起类变化的原因,一个类只承担一个职责,如果一个类有两个职责,应该将其非开。比如tableviewCell如果有多种样式Cell,分成几种类型写Cell。

4:里氏替换原则

适用父类的功能一定适用于子类,子类能替换父类的对象,子类可以扩展父类的功能,不能修改父类原有的功能。

5:接口隔离原则(设计更专一更小的接口)

客户端不应该依赖不需要的接口,类之间的依赖类应建立在最小的接口上,类不应该被迫实现不需要的方法

6:迪米特法则

一个对象对另一个对象了解的越多,耦合度就越高(对象之间应该保持最少的了解)

7:组合/复用原则

在一个新的对象里面使用已有的对象,使成为新对象一部分。优先使用对象组合聚合来实现代码复用,而不是继承

设计模式

ios开发中常见的设计模式主要分为三大类:

创造型模式(解决对象创建问题)

结构型模式(解决对象组织和结构问题)

行为型模式(解决对象间的交互问题)

创造型模式

单例模式

确保一个类只有一个实例,并提供全局访问点。比如userDefault、UIApplication、FileManager等

例如

class Singleton {
    static let shared = Singleton() // 全局唯一实例

    private init() {} // 防止外部初始化

    func doSomething() {
        print("执行某些操作")
    }
}

// 使用单例
Singleton.shared.doSomething()

Swift提供Lazy属性,可以保证线程安全,不需要额外加锁。

工厂模式

提供创建对象的接口,不直接实例化对象。隐藏负责的对象创建逻辑,提高代码的复用性。

示例:

protocol Animal {
    func makeSound() -> String
}

class Dog: Animal {
    func makeSound() -> String { return "🐶 汪汪" }
}

class Cat: Animal {
    func makeSound() -> String { return "🐱 喵喵" }
}

// 工厂类
class AnimalFactory {
    static func createAnimal(type: String) -> Animal? {
        switch type {
        case "dog": return Dog()
        case "cat": return Cat()
        default: return nil
        }
    }
}

// 使用工厂
let dog = AnimalFactory.createAnimal(type: "dog")
print(dog?.makeSound() ?? "未知") // 🐶 汪汪

结构型模式

代理模式

通过委托对象,处理某些任务,用于类之间通信。

protocol TaskDelegate: AnyObject {
    func taskDidComplete()
}

class Worker {
    weak var delegate: TaskDelegate?

    func doWork() {
        print("正在执行任务...")
        delegate?.taskDidComplete() // 任务完成后通知代理
    }
}

class Manager: TaskDelegate {
    func taskDidComplete() {
        print("任务完成,经理收到通知!")
    }
}

// 使用代理
let worker = Worker()
let manager = Manager()
worker.delegate = manager
worker.doWork()

观察者模式

用于通知多个对象数据更新,如NotificationCenter、KVO

NotificationCenter:

// 发送通知
NotificationCenter.default.post(name: Notification.Name("TaskCompleted"), object: nil)

// 监听通知
NotificationCenter.default.addObserver(forName: Notification.Name("TaskCompleted"), object: nil, queue: .main) { _ in
    print("收到任务完成通知!")
}

 KVO

class Person: NSObject {
    @objc dynamic var age = 20
}

let person = Person()
let observer = person.observe(\.age, options: .new) { _, change in
    print("年龄变化:\(change.newValue!)")
}

person.age = 25 // 输出:年龄变化:25

行为型模式 

责任链模式

按顺序处理事件,如UIResponder事件传递

class Handler {
    var next: Handler?
    
    func handleRequest(_ request: String) {
        if next != nil {
            next?.handleRequest(request)
        } else {
            print("请求 \(request) 没有处理者")
        }
    }
}

class ConcreteHandlerA: Handler {
    override func handleRequest(_ request: String) {
        if request == "A" {
            print("A 处理请求")
        } else {
            super.handleRequest(request)
        }
    }
}

class ConcreteHandlerB: Handler {
    override func handleRequest(_ request: String) {
        if request == "B" {
            print("B 处理请求")
        } else {
            super.handleRequest(request)
        }
    }
}

// 创建责任链
let handlerA = ConcreteHandlerA()
let handlerB = ConcreteHandlerB()
handlerA.next = handlerB

handlerA.handleRequest("B") // 输出:B 处理请求

备忘录模式

保存和恢复对象状态,如 UserDefaults。

class Game {
    var score = 0
    
    func save() -> Int {
        return score
    }
    
    func restore(_ score: Int) {
        self.score = score
    }
}

let game = Game()
game.score = 100
let savedScore = game.save()

game.score = 50
game.restore(savedScore) // 恢复存档

print(game.score) // 输出:100

1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义   就一个类而言,应该仅有一个引起它变化的原因。 定义解读   这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出   假设有一个类C,它负责两个不同的职责:职责P1P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案   遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。   说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1P2。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值