Unity【话大】设计模式之代理模式

前言：笔者在最开始写程序的时候经常会遇到一种情况，例如更改一个字段、或者添加一种小功能，就要把原来写过的东西几乎废弃掉，或者更改大量以前写过的代码。又或者自己写的东西时间久了再去回顾，完全找不到到时为什么这么写的头绪，如果遇到了Bug更是无法快速定位在哪里小范围出现的问题。如果你也经常遇到这种问题，就说明你现阶段非常需要学习下设计模式了。

在网上经常说的设计模式有23种，也有一些更多的设计模式，无非也是从这些设计模式中变种而来。如果让笔者来形容什么是设计模式，我认为设计模式是：一种思想，一种模式，一种套路，一种解决问题的高效策略。

---

---

有说的不正确或者不准确的地方欢迎留言指正

---

有什么有趣的写作技巧或者想法欢迎大家给我留言，大家的帮助是我写下去最有效的动力

---

---

定外卖几乎成了现在上班一族必不可少的项目了，想想最早，买点吃的总是需要自己亲自去买，如果遇到人多的时候排队还需要等好久，而且还不一定有位置，自从美团外卖等业务出现后，大大的提高了便捷程度，不过方便面这类东西就惨了，XD~,今天笔者要说的设计模式，有点和这个类似，那就是代理模式

示例

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public interface IBuyFood
{
    void OrderFood();
    bool GetFood();
}

常规购买

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using System.Threading;
using Custom.Log;
public class BuyFood : IBuyFood
{

    private bool isOrderSuccessful = false;

    public BuyFood()
    {
        this.Log("买东西时各种准备");
        Thread.Sleep(1000);
    }
    public bool GetFood()
    {
        if (isOrderSuccessful)
        {
            this.Log("买食物成功");
            return true;
        }
        else
        {
            this.Log("买食物失败");
            return false;
        }
    }

    public void OrderFood()
    {
        isOrderSuccessful = true;
    }
}

代理购买

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using Custom.Log;

public class BuyFoodProxy : IBuyFood
{
    protected readonly object syncRoot = new object();

    private BuyFood buyFood = null;

    protected BuyFood GetbuyFood
    {
        get
        {
            //双if加Lock锁也可以不加
            if (buyFood == null)
            {
                lock (syncRoot)
                {
                    if (buyFood == null)
                    {
                        this.Log("代理准备中。。。。");
                        buyFood = new BuyFood();
                    }
                }
            }
            return buyFood;
        }
    }
    /// <summary>
    /// 下订单
    /// </summary>
    public void OrderFood()
    {
        GetbuyFood.OrderFood();
        this.Log("代理已经接单，等待派送");
    }
    /// <summary>
    /// 派送的过程
    /// </summary>
    /// <returns></returns>
    public bool GetFood()
    {
        if (GetbuyFood.GetFood())
        {
            this.Log("代理派送食物成功");
            return true;
        }
        else
        {
            this.LogWarning("代理派送食物失败");
            return false;
        }
    }
}

调用~

    void Start()
    {
        IBuyFood buyFood = new BuyFood();
        this.Log("思考是否买吃的？？？");
        this.Log("确定买吃的！！！");
        buyFood.OrderFood();
        buyFood.GetFood();

        this.Log(new string('*', 20));

        buyFood = new BuyFoodProxy();
        this.Log("思考是否买吃的？？？");
        this.Log("确定买吃的！！！");
        buyFood.OrderFood();
        buyFood.GetFood();
    }

打印如下

用了代理看上去貌似没什么卵用啊，和原来没区别啊，但是请仔细看打印信息，买东西时各种准备与思考是否买吃的？？？的位置，用了代理把需要事先准备的东西延迟了，在真正决定需要的时候才进行初始化，这种延迟的初始化在代理中经常使用。

根据单一职责原则我们知道，BuyFood只需要知道买东西的准备、下订单和获取食物。其他的BuyFood都不需要知道，例如一些什么时候准备（使用延迟加载）、是否买过食物（使用缓存）、最近是否在减肥，要不要买？（权限检查）、店铺是否用户太多不接单了（线程争用检测）等等（目前笔者只能想出这些），都可以交给对应的代理来做。

这时又有人提出疑问了，你说的这些装饰器模式也可以做到啊。那我们就要看看代理模式的定义了

代理模式（Proxy），为其他对象提供一种代理以控制对这个对象的访问。
说白了仅仅是在原有业务逻辑添加原有功能的限制。
那装饰器模式呢？装饰器模式(Decorator),动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
装饰器模式对原有业务逻辑的动态扩展
一个是原有业务逻辑的访问限制，一个是原有业务逻辑的动态扩展。

不知道大家是否对代理模式有了进一步的了解呢？