在楼下买完夜宵准备回宿舍，楼下听到杰哥一声“卧槽！猪一样地队友！”一开门，房间一片狼藉，委屈的杰哥在阳台抽着一根寂寞的香烟儿，他向我诉苦道：“现在的白银咋呢（“咋呢”方言：怎么那么）菜啊！还是我鹏牛匹，都上黄金呢！”我鹏昨天还是青铜5，怎么一下子黄金呢？！在我一顿严刑拷打审问，他终于承认他拿一星期饭钱找代练了。
   代练确实破坏游戏体验啊，青铜水平的玩家和钻石水平的队友组队，有多坑可想而知...不说了..要收拾宿舍了T_T

一、代理模式的概念

定义

   为其他对象（A）提供一种代理对象（B），并由改代理对象（B）控制对该对象（A）的访问

UML图

代理模式通用UML

图中涉及的角色如下所示：

• 协议：定义代理和委托的共同接口（方法）
• 委托：根据指定的协议，委托代理去完成实现指定接口（方法）
• 代理：根据指定的协议，实现委托需要实现的接口（方法）

二、代理模式代码演示

协议类PlayGameDelegate.swift：定义了为其他玩家代打的方法

protocol PlayGameDelegate:NSObjectProtocol {
    //给玩家代练
    func playGameForClient(player:Player)
}

委托类Player.swift：

class Player: NSObject {
    
    public var playerName = ""
    //玩家玩游戏的水平
    //1:青铜 2:白银 3:黄金 4:铂金 5:钻石 。。。
    var gameLevel = 0
    //玩家游戏账号的段位
    var accountLevel = 0
    //找代练
    weak var delegate : PlayGameDelegate?
    //构造方法
    public init(name:NSString,gl:Int) {
        super.init()
        playerName = name as String
        gameLevel = gl
        playGame()
    }
    
    func playGame() {
        //怎样的水平就该是怎样的段位囖
        accountLevel = gameLevel
    }
    
    public func levelUp() {
        print("鹏鹏：拿一个月饭钱找代练去")
        delegate?.playGameForPlayer(player: self)
    }
}

代理类GameProxy.swift：

class GameProxy: NSObject , PlayGameDelegate {
    
    //代练玩游戏的水平
    private  var gameLevel = 0
    //代练游戏账号的段位
    var accountLevel = 0
    
    public init(gl:Int) {
        super.init()
        gameLevel = gl
    }
    //实现协议方法
    func playGameForPlayer(player: Player) {
        player.accountLevel = gameLevel
        print("代练：已为\(player.playerName)代练到段位\(player.accountLevel)")
    }
}

客户端main.swift：

//上帝创造了鹏鹏,青铜渣渣
let pengpeng = Player.init(name: "鹏鹏", gl: 1)
//lol的火爆，代练小强应运而生，钻石大神
let xiaoqiang = GameProxy.init(gl:5)
//鹏鹏找到代练小强
pengpeng.delegate = xiaoqiang
//鹏鹏的账号开始升级咯
pengpeng.levelUp()

客户端运行结果：

鹏鹏：拿一个月饭钱找代练去
代练：已为鹏鹏代练到段位5

从上面的运行结果可以看出，鹏鹏只是委托了代练给他打排位赛升段位，自己并不需要亲手打，只需要等待代练反馈升级黄金的消息就可以了。另外，由于“游戏水平决定账号等级”这个道理，在没有代理的情况下账号等级不可能升到钻石啊，而且代练游戏水平gameLevel属性是一个私有属性，没有代理模式的情况下，代练的gameLevel属性不可能给鹏鹏的accountLevel属性赋值。由此可见，代理模式能控制代理和委托之间的通信，在不公有化属性或方法的前提下实现对该类的私有属性或方法的访问。

三、代理模式的扩展

代理模式PK中介者模式

   关于中介者模式的内容就不详细阐述囖，感兴趣的同学可以到温习一下中介者模式

相同点

• 在中介者模式中就有朋友说是代理模式，确实这两个模式在代码上十分相似，两种模式都会给一个类设置一个中间类（代理模式中的代理/中介者模式中的中介）客户端同样通过中间类去间接访问另外一个类（代理模式中的委托/中介者模式中的同事类）；
• 无论中介者模式和代理模式，都会把一些任务交给上述所说的中间类去完成而不用理会中间的实现过程，而只需要得到委托/同事类想要的结果

不同点

• 两种模式都有一个中间类负责控制访问，在中介者模式中，同事类是知道中介类的数据类型的，就好像我们买房肯定知道中介是一个地产中介而不是一间餐厅或其他；在代理模式中，委托不用知道代理是什么数据类型，只要那个类遵循指定协议的，都能作为委托的代理。由此可以看出，相对于中介者模式，代理模式更符合依赖倒置原则
• 代理模式中，代理和委托之间是一对一关系；中介者模式中，中介者和同事类是一对多，甚至多对多得关系

四、模式总结

优点

• 具有良好的扩展性。委托的业务逻辑可能会随时改变，当有新增功能，只需要在协议中增加方法就能不影响原有功能的情况下增加新功能
• 有利于代码的封装。如果一个类，实现了某个协议，那么这个协议中的属性或方法就不必公有化，就可以被定义协议的类调用。这样可以减少一个类暴露给外部的方法
• 有利于程序的结构化与层次化。一个协议往往是解决某一个问题，对于一个其他的不过却类似的问题，我们只用再次实现协议即可，避免了自己再次构思一组方法，提高代码的复用性

五、总结

对于设计模式的学习，我是持十分有必要学习的态度，不懂设计模式，谈何写出高质量代码呢？大家一起努力，共勉！！！

感兴趣可以到github看完整代理模式demo