架构演化思考总结(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模式！
谢谢各位能和我一起来探索项目架构设计演化！
