架构演化思考总结(2)

架构演化思考总结(2)

—-–从命令模式中来探索处理依赖关系

在正式引入命令模式的概念之前,我们先从简单的案例来逐步演化大家在书面上常见到的内容。

public interface ICommand
{
    void Execute();
}

public class PlayMusicCommand : ICommand
{
     public void Execute()
     {
        Debug.Log("你说家是唯一的城堡,随着稻香一路奔跑~");
     }
}

var Start()
{
    var command = new PlayMusicCommand();
    command.Execute();
}

这里我们定义一个命令接口,如果是命令,必定要实现的一个执行方法。

PlayMusicCommand 实现接口,此命令的作用就是播放Jay的《稻香》,如果想实现播放音乐功能,直接执行对应命令的方法即可!

体现出命令的本质,我们把要所作的内容或者控制逻辑封装到一起,当我们需要执行它时候,下达执行命令的方法即可!

来看AI对命令模式的介绍:

上面小案例正对应对“操作逻辑”进行封装,提炼成命令,那么这样对操作逻辑进行封装有什么好处呢?

显而易见的好处之一就是方便管理,逻辑清晰。进行复杂逻辑开发时候,我们正式把它尽可能提炼封装成方法,为的就是方便管理,而命令模式是对逻辑代码再高一个层次的封装,也就是说从方法抽象成类,显然更加便于管理和复用。

使用命令模式降低复杂逻辑的开发调试难度,你排查一个几百行的大函数的bug肯定比封装拆分成几个函数或者是几个对应的命令的状况要麻烦。比如我们需要进行某个复杂操作,但是我们对它进行拆分封装,分成几个Command来执行,这样既可以分发给几个同事一起协作复杂逻辑开发,没有与核心逻辑控制脚本产生过多的耦合

当然另一方面分担了控制脚本Controller的控制压力,使其没那么臃肿。

public interface ICommand
{
    void Execute();
}

public class ACommand
{
    public void Execute()
    {
        Debug.Log("Execute A Command");
    }
}

public class BCommand
{
    public void Execute()
    {
        Debug.Log("Execute B Command");
    }
}

public class CCommand
{
    public void Execute()
    {
        Debug.Log("Execute C Command");
    }
}

void Start()
{
    var commands = new List<ICommand>();
    commands.Add(new ACommand());
    commands.Add(new BCommand());
    commands.Add(new CCommand());
  
    commands.ForEach(c=>c.Execute());
}

命令模式–携带参数

如果我们要执行需要参数才能进行的命令呢?

好,接下来我们实现可以携带参数的命令,非常简单,只需要给执行的命令中声明参数即可!

interface ICommand
{
    void Execute();
}
public class BuyGoodsCommand : ICommand
{
    private int goodsId;
    private int goodsCount;
    public BuyGoodsCommand(int id,int count)
    {
        goodsId = id;
        goodsCount = count;
    }
    public void Execute()
    {
        Debug.Log($"购买了id为{goodsId}的商品{goodsCount}个");
        //执行相关的购买逻辑
        //......
    }
}

public class Test : MonoBehaviour
{
    private void Start()
    {
        var buyGoodsCommand = new BuyGoodsCommand(1, 15);
        buyGoodsCommand.Execute();
    }
}

命令模式–撤销功能

接下来接着向命令模式的功能实现迈进,在刚接触命令模式的时候,会好奇的想到,既然把命令都封装好一步步执行了,那能不能撤销已经执行好的行为呢?笔者也是在学习到命令模式之后才联想到各种编辑工具的Ctrl+Z的效果的实现思路。那我们往命令模式中添加一个撤销功能。

当然要执行撤销命令,要有个容器来存储已经执行的命令,这里使用的是List,也可以用Stack

和Queue,当然使用栈就可以实现Ctrl + Z的逐步撤销功能了!

interface ICommand
{
    void Execute();
    void Undo();
}
public class BuyGoodsCommand : ICommand
{
    private int goodsId;
    private int goodsCount;
    public BuyGoodsCommand(int id,int count)
    {
        goodsId = id;
        goodsCount = count;
    }
    public void Execute()
    {
        Debug.Log($"购买了id为{goodsId}的商品{goodsCount}个");
        //执行相关的购买逻辑
        //......
    }

    public void Undo()
    {
        Debug.Log($"刚才购买的id为{goodsId}的商品{goodsCount}个,已经全部退货!");
        //执行相关的退货操作
        //如库存++
        //玩家金币++
    }
}

public class Test : MonoBehaviour
{
    private void Start()
    {
        var commands = new List<BuyGoodsCommand>();
        commands.Add(new BuyGoodsCommand(1, 15));
        commands.Add(new BuyGoodsCommand(5, 2));

        //执行购买
        commands.ForEach(command => command.Execute());

        //5号物品不想要了 退货
        commands[1].Undo();
    }
}

命令模式–命令和执行分离

这里和上一篇所陈述的依赖关系大致相同,我们把命令从一个对象降级成方法来看。

我们常常进行的方法调用这种行为,就是命令和执行未分离的一个例子。即方法调用必然方法中的逻辑执行。

void DoSomethingCommand()
{
    Debug.Log("命令执行了!");
}
void Start()
{
    DoSomethingCommand();
}

那么命令和执行分开是怎么样的呢?

我们可以使用委托来实现,时间和空间上的分离。

 public class A : MonoBehaviour
 {
     B b;
     void Start()
     {
         b = transform.Find("Animation").GetComponent<B>();

         // 注册完成的事件
         b.OnDoSomethingDone += DoSomethingCommand;
     }
     void DoSomethingCommand()
     {
         Debug.Log("命令执行了!");
     }
 }

public class B : MonoBehaviour
{
    // 定义委托
    public Action OnDoSomethingDone = ()=>{};

    //当动画播放完毕后调用
    public void DoSomething()
    {
        //触发委托中的函数执行
        OnDoSomethingDone();
    }
}

这样将要执行的命令DoSomethingCommand,会在特定时机(时间上分离)由另外一个脚本(空间上分离)调用执行,实现时空分离。

好,我们已经在方法层面表述出命令的分离,现在我们回到类这个层面,将Command的声明和执行进行分离。

这就需要一个对委托进行另一层的封装使用,这里是用委托(可以简单理解为函数容器),存储的是函数(command简化为方法层面),可以使用。对应的将命令升级升级成对象,为此也要对

委托进行“升级”,这里参考QFramWork的自定义的事件机制。

自定义事件机制

我们希望它事件机制拥有功能:发送事件功能和自动注销功能。

发送事件是必须的,而自动注销功能要的是当注册事件监听的GameObject的对象Destroy之后,要注销对事件的监听功能。

现在按照这样的要求来实现接口:

 public interface ITypeEventSystem
 {
     /// <summary>
     /// 发送事件
     /// </summary>
     /// <typeparam name="T"></typeparam>
     void Send<T>() where T : new ();

     void Send<T>(T e);

     IUnRegister Register<T>(Action<T> onEvent);

     /// <summary>
     /// 注销事件
     /// </summary>
     /// <param name="onEvent"></param>
     /// <typeparam name="T"></typeparam>
     void UnRegister<T>(Action<T> onEvent);
 }
//注销机制
 public interface IUnRegister
 {
     void UnRegister();
 }

来着重实现自动注销机制:

我们来声明一个类,来具体执行注销事件的功能:

public class TypeEventSystemUnRegister<T> : IUnRegister
{
    //持有事件机制引用
    public ITypeEventSystem TypeEventSystem { get; set; }
    
    //持有待注销的委托
    public Action<T> OnEvent {get;set;}
    
    //具体的注销机方法
    public void UnRegister()
    {
        //具体就是调用事件机制(系统)对应的方法,注销掉指定的函数 (OnEvent)
        TypeEventSystem.UnRegister(OnEvent);
        
        TypeEventSystem = null;
            OnEvent = null;
    }
}

当然注销时机是在当GameObjet销毁时候,为此需要一个“触发器”,其挂载在注册事件的GameObject上,当检测到Destroy时候进行触发。

来实现对应的触发器:

/// <summary>
/// 注销事件的触发器
/// </summary>
public class UnRegisterOnDestroyTrigger : MonoBehaviour
{
    private HashSet<IUnRegister> mUnRegisters = new HashSet<IUnRegister>();

    public void AddUnRegister(IUnRegister unRegister)
    {
        mUnRegisters.Add(unRegister);
    }

    private void OnDestroy()
    {
        foreach (var unRegister in mUnRegisters)
        {
            unRegister.UnRegister();
        }

        mUnRegisters.Clear();
    }
}

来对注销机制的接口拓展功能,方便在注册事件时候调用一个方法,通过这个方法调用直接将上段代码所示的注销机制的触发器挂载在GameObject上。

public static class UnRegisterExtension
{
    public static void UnRegisterWhenGameObjectDestroyed(this IUnRegister unRegister, GameObject gameObject)
    {
        var trigger = gameObject.GetComponent<UnRegisterOnDestroyTrigger>();

        if (!trigger)
        {
            trigger = gameObject.AddComponent<UnRegisterOnDestroyTrigger>();
        }

        trigger.AddUnRegister(unRegister);
    }
}

至此,当我们在使用时候调用一下’UnRegisterWhenGameObjectDestroyed‘方法,将会挂载Tirgger,当物体销毁时候会触发,实现自动注销事件,有效的保证了在使用Unity中委托的注册和注销成对出现的特征,防止委托中出现空指针。

好,实现完成自动注销事件机制,继续实现事件的注册和调用机制。

public class TypeEventSystem : ITypeEventSystem
{
    //使用依赖倒转原则
    interface IRegistrations
    {

    }

    class Registrations<T> : IRegistrations
    {
        public Action<T> OnEvent = obj => { };
    }
//根据事件的类型来存储 对应的事件Action<T> 被封装成类 以接口类型存储 
    private Dictionary<Type, IRegistrations> mEventRegistrations = new Dictionary<Type, IRegistrations>();
    
    public void Send<T>() where T : new()
    {
        var e = new T();
        Send<T>(e);
    }
    //具体发送机制 调用机制
    public void Send<T>(T e)
    {
        var type = typeof(T);
        IRegistrations eventRegistrations;

        if (mEventRegistrations.TryGetValue(type, out eventRegistrations))
        {
            //具体调用 “解压 降维” 调用委托
            (eventRegistrations as Registrations<T>)?.OnEvent.Invoke(e);
        }
    }
    
    //注册实现
     public IUnRegister Register<T>(Action<T> onEvent)
     {
         var type = typeof(T);
         //具体存储 “加压 升维” 向委托中添加函数
         IRegistrations eventRegistrations;

         //判断存储的事件类型存在否
         if (mEventRegistrations.TryGetValue(type, out eventRegistrations))
         {

         }
         else
         {
             //不存在就添加一个
             eventRegistrations = new Registrations<T>();
             mEventRegistrations.Add(type,eventRegistrations);
         }

         //如果存在就 解压 添加到“解压”好的事件机制中
         (eventRegistrations as Registrations<T>).OnEvent += onEvent;

         //返回注销对象需要的数据(引用)实例
         // 可以不通过构造函数来对共有访问对象初始化赋值
         return new TypeEventSystemUnRegister<T>()
         {
             OnEvent = onEvent,
             TypeEventSystem = this
         };
     }
    //注销方法的具体实现
    public void UnRegister<T>(Action<T> onEvent)
    {
        var type = typeof(T);
        IRegistrations eventRegistrations;

        if (mEventRegistrations.TryGetValue(type,out eventRegistrations))
        {
            (eventRegistrations as Registrations<T>).OnEvent -= onEvent;
        }
    }
    
}

至此自定义的事件机制实现完毕!

如果感兴趣,关注其对应的测试案例展示,(将在单独一篇博客介绍此事件机制)

继续推进,使用此机制来实现Command的时空分离:

public interface ICommand
{
    void Execute();
}

public class SayHelloCommand
{
    public void Execute()
    {
        // 执行
        Debug.Log("Say Hello");
    }
}

void Start()
{
    // 命令
    var command = new SayHelloCommand();

    command.Execute();


    mTypeEventSystem = new TypeEventSystem();
    
   mTypeEventSystem.Register<ICommand>(Execute).UnRegisterWhenGameObjectDestroyed(gameObject);

    // 命令 使用Command对象注册
   mTypeEventSystem.Send<Icommand>(new SayHelloCommand());
}

那么对比三种实现方式发现什么?

  • 方法:调用即执行!没有分离
  • 事件机制:执行在事件注册中实现 有分离
  • Command:执行在Command内部实现 有分离

显然,Command对命令和执行的分离程度介于方法和事件机制之间。

重点对比事件机制,在实现自定义方法之前,笔者已经点到委托存储的方法,和在使用封装后委托(自定义事件)可以存储类(命令实例),虽然都是通过委托来存储执行方法,使用Command更为自由一些,可以在自定义的位置和时机执行,而事件机制一般至少需要通过两个对象才能完整使用。

先写到这里吧!

下面我们继续探索命令模式在架构演化中的作用,继续接近我们学习中接触到的Command模式!

谢谢各位能和我一起来探索项目架构设计演化!

热门相关:我的时光里,满满都是你   以权谋妻   完美再遇,二婚老公有点酷   佣兵的战争   欧神