设计模式(Swift)-模板方法

定义

Template Method模式:

定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

动机

在软件构建过程中,对于某一项任务,它常常有稳定的整体操作结构,但各个子步骤却有很多改变的需求,或者由于固有的原因(比如框架与应用之间的关系)而无法和任务的整体结构同时实现。

如何在确定稳定操作结构的前提下,来灵活应对各个子步骤的变化或者晚期实现需求?

案例

假如有这样一套固定的流程

swift 复制代码
step1()

if step2() {
    step3()
}

let count = step4()

for _ in 0..<count {
    step5()
}

现在有个框架要封装这个功能,框架会实现step1step3step5的流程,但是step2step4并不由框架决定,而是由客户端开发者决定的。我们先可以顺着流程实现下,我们先实现下框架的接口:

方案一

swift 复制代码
class Library {
    func step1() {
        // do something
    }

    func step3() {
        // do something
    }

    func step5() {
        // do something
    }
}

然后我们可能需要一份文档,需要指明如何使用框架接口,所以最终结果应该是这样的:

swift 复制代码
class Application {
    func step2() -> Bool {
        return true
    }

    func step4() -> Int {
        return 3
    }
}

let app = Application()
let lib = Library()

lib.step1()
if app.step2() {
    lib.step3()
}

let count = app.step4()

for _ in 0..<count {
    lib.step5()
}

这种设计方案并不是很好,这些流程其实是框架的业务逻辑,现在客户端开发需要关注这些过程,这样不仅复杂,而且容易接错。我们改进一种方案,我们把接口设计成协议:

方案二

swift 复制代码
protocol Library {
    func step2() -> Bool
    
    func step4() -> Int
}

extension Library {
    
    func doWork() {
        step1()
        if step2() {
            step3()
        }
        
        let count = step4()
        
        for _ in 0..<count {
            step5()
        }
    }
    
    
    private func step1() {
        // do something
    }
    
    private func step3() {
        // do something
    }
    
    private func step5() {
        // do something
    }
}

现在,整个的业务流程已经封装到了doWork的方法里了,所以在客户端的开发里,我们只要遵守协议,然后实现协议方法就行:

swift 复制代码
class Application : Library {
    func step2() -> Bool {
        return true
    }

    func step4() -> Int {
        return 3
    }
}

let app = Application()
app.doWork()

这样看着就很简洁,我们看下有什么优势:

  • 客户端开发无需关注具体业务实现
  • 如果业务流程发生了改变,那么变化也只是Library内部的部分,不会影响了客户端的开发
  • 方案一的方法是Library早绑定Application,而方案二的方法是Library晚绑定Application。如何理解这句话,Library一定是早于Application开发的,但是在改进前,Library还需要依赖于Application的实现,改进后就不一样了,Library不依赖Application的实现,基于协议先把流程实现了。

虽然方案二挺好的,但是总觉得怪怪的,平时开发的时候不怎么能碰到这样的设计(这种方案是从C++那边翻译过来的),我们在改一种方案:

方案三

swift 复制代码
protocol LibraryDelegate: AnyObject {
    func step2() -> Bool
    
    func step4() -> Int
}

class Library {
    
    weak var delegate : LibraryDelegate?
    
    func doWork() {
        step1()
        if let result = delegate?.step2() , result {
            step3()
        }
        
        if let count = delegate?.step4() {
            for _ in 0..<count {
                step5()
            }
        }
        
    }
    
    private func step1() {
        // do something
    }
    
    private func step3() {
        // do something
    }
    
    private func step5() {
        // do something
    }
}


class Application : LibraryDelegate {
    func step2() -> Bool {
        return true
    }

    func step4() -> Int {
        return 3
    }
}

let app = Application()
let lib = Library()
lib.delegate = app
lib.doWork()

这种方案有没有觉得很熟悉,对,和UITableViewDataSource一样,UITableViewDataSource用的就是模版方法的设计模式。那方案三和方案二相比有什么优势?

  • 方案二的协议其实是一种继承(相当于C++的虚类继承),但方案三是组合,组合的耦合性是低于继承的
  • 职责明确,就像上面doWork方法,这个功能其实是框架的功能,但是在方案二中却变成了Application的功能。

总结

最后我们在看下模板方法的定义,看看通过案例是不是好理解一点。

Template Method模式是一种非常基础性的设计模式,在面向对象系统中有着大量的应用。它用最简洁的机制(协议的多态性)为很多应用程序框架提供了灵活的扩展点,是代码复用方面的基本实现结构。

除了可以灵活应对子步骤的变化外,"不要调用我,让我来调用你"的反向控制结构是Template Method的典型应用。

相关推荐
天天扭码3 小时前
五天SpringCloud计划——DAY2之单体架构和微服务架构的选择和转换原则
java·spring cloud·微服务·架构
余生H3 小时前
transformer.js(三):底层架构及性能优化指南
javascript·深度学习·架构·transformer
凡人的AI工具箱3 小时前
15分钟学 Go 第 60 天 :综合项目展示 - 构建微服务电商平台(完整示例25000字)
开发语言·后端·微服务·架构·golang
运维&陈同学4 小时前
【zookeeper01】消息队列与微服务之zookeeper工作原理
运维·分布式·微服务·zookeeper·云原生·架构·消息队列
哔哥哔特商务网17 小时前
一文探究48V新型电气架构下的汽车连接器
架构·汽车
007php00717 小时前
GoZero 上传文件File到阿里云 OSS 报错及优化方案
服务器·开发语言·数据库·python·阿里云·架构·golang
今天啥也没干17 小时前
使用 Sparkle 实现 macOS 应用自定义更新弹窗
前端·javascript·swift
码上有前19 小时前
解析后端框架学习:从单体应用到微服务架构的进阶之路
学习·微服务·架构