一、“组件协作”模式

概述:现代软件专业分工之后的第一个结果是划分出了框架和应用。而“组件协作”模式通过晚绑定,来实现框架和应用的松耦合,是两者之间协作的常用模式。

这个思想的典型模式是:Template模板方法、Strategy策略模式、Observer/Event观察者模式.
ps:这并非表示其他模式就不注重组件协作的问题,只是这三个模式在这个特性上尤为突出。

二、设计动机

在现在的软件构建的过程中,常常会有稳定的整体结构,但是各个子模块常常会有频繁变化的需求,还有可能在软件构造中,由于不同模块的不同构造时间,子模块代码晚于整体稳定模块。

三、模式场景

下面展示一段库和程序开发中的例子：我在Playground中书写代码举例

//库发开程序员
class Library{
    func step1() -> Void {
        //...
    }
    func step3() -> Void {
        //...
    }  
    func step5() -> Void {
        //...
    }
}
//iOS应用程序开发程序员
class Application{  
    func step2() -> Bool {
        //...
        return true
    }
    func step4() -> Void {
        //...
    }
}

//逻辑代码
let lib:Library = Library()
let app:Application = Application()
lib.step1()
if (app.step2()) {
    lib.step3()
}
for _ in 0...4 {
    app.step4()
}
lib.step5()

这个例子中展示了开发中iOS开发程序员和库开发程序员的例子。这里假设了库代码和程序开发中的方法先后执行顺序的问题。
但是这其中埋藏着一个问题,作为库开发人员,其实调用库的逻辑代码流程一般而言应该由库开发程序员来设定,它应该是稳定的,不应修改的。所以我们可以尝试来改写它。

四、修改设计

现在我们来利用模板方法来进行修改,我们将算法代码中稳定的部分固定在Library里,而将变化的部分留给子类。于是这里Application继承于Library。

class Library{   
    func Run(){   
        func step1() -> Void {
            //...
        }
        func step3() -> Void {
            //...
        }        
        func step5() -> Void {
            //...
        }   
  
        step1()
        if (step2()) {
            step3()
        }
        for _ in 0...4 {
            step4()
        }
        step5()    
    } 
    func step2() -> Bool {
        //...
        return true
    }
    func step4() -> Void {
        //...
    }    
}
class Application:Library{
//重载变化的部分
    override func step2() -> Bool {
        //...
        return true
    }
    override func step4() -> Void {
        //...
    }
}
//主逻辑
let app:Application = Application()
app.Run()

不得不承认,这个模式看上去十分简单,这个模式的存在依赖于面向对象的特点,但往往很多人在书写代码的时候,虽然使用面向对象语言,但是设计思想往往是结构化的。
如果step1是变化的,你就可以重载step1方法。关键是抓住一个算法中变化的部分。假如step1-step5全都是不变化的,那么没有一个设计模式可以适应这种变化。
设计模式的存在是依赖于稳定点。
换言之,假如step1-step5全都是不变的,那么也不需要设计模式了。

46733935-09B3-4772-823C-A39CB76A34BA.png

模板方法模式的思想是定义一个稳定的算法骨架,而将变化的部分放置到子类中去。子类可以通过override来重写变化的部分。这样达到设计模式复用的目的。
需要注意的是,这个模式的存在依赖run(稳定)的存在,必须有一部分是稳定的,如果run函数出现了变化,这个模式就是失败的。所以我们必须找出不变的部分。

AF405227-5C25-4A50-9538-9321088383BF.png

第一种写法为早绑定,第二种写法为晚绑定。
就如上图所示,一般而言,库开发往往都早于我们App开发,晚开发的东西调用早开发的东西即为早绑定,这种思想其实十分正常,c语言时期都默认这种做法。
但当有了面向对象特性之后,我们就可以实现晚绑定。

五、模板方法的弊端

模板方法在面向对象语言中使用非常多,但是它也有它自己的弊端。
因为把主要逻辑都封在了父类中,例子中的iOS App开发人员或者说对于继承父类的子类,只需要重载某些步骤,甚至一句调用代码都不用写,应用程序就可以直接跑起来。
但这样,上层开发人员(此处指实现子类的程序员)就会只知道用法,却不清楚整个实现逻辑的感觉。因为整个逻辑骨架都封装在父类中。
所以作为应用程序app开发人员,有时也有必要去了解一下库的实现。