Osheep

时光不回头,当下最重要。

Swift-门面(Facade)模式

门面模式(Facade)也称为外观模式,GOF 在《设计模式》一书中给出如下定义:为子系统中的一组接口提供一个一致的界面, Facade 模式定义了一个高层接口,这个接口使得这一子系统更加容易使用.

《Swift-门面(Facade)模式》

门面模式.jpg

门面(Facade)角色:客户端可以调用这个角色的方法。此角色知晓相关的(一个或者多个)子系统的功能和责任.在正常情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去.

子系统(subsystem)角色:可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。每一个子系统都可以被客户端直接调用,或者被门面角色调用。子系统并不知道门面的存在,对于子系统而言,门面仅仅是另外一个客户端而已.

测试代码:

func work() {

        let cook:Cook = Cook()
        let service:Service = Service()

        cook.cook()
        service.server()
    }

}
class Cook {

    func cook() {
        print("开始做饭,炒菜")
    }
}

class Service {

    func server() {
        print("提供饭菜给客人")
    }

}
let facade:Facade = Facade()
        facade.work()

优点:
对客户屏蔽子系统组件,减少了客户处理的对象数目并使得子系统使用起来更加容易。通过引入门面模式,客户代码将变得很简单,与之关联的对象也很少。
实现了子系统与客户之间的松耦合关系,这使得子系统的组件变化不会影响到调用它的客户类,只需要调整外观类即可。
降低了大型软件系统中的编译依赖性,并简化了系统在不同平台之间的移植过程,因为编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。
只是提供了一个访问子系统的统一入口,并不影响用户直接使用子系统类。

缺点:
不能很好地限制客户使用子系统类,如果对客户访问子系统类做太多的限制则减少了可变性和灵活性。
在不引入抽象外观类的情况下,增加新的子系统可能需要修改外观类或客户端的源代码,违背了“开闭原则”.

参考链接:
http://blog.csdn.net/xingjiarong/article/details/50066133

点赞