大家有没有向我这样写代码的呀？都是怎么优化的？

Creator 2.x
#1

初期感觉还好。后期依旧感觉，很复杂！消息扔来扔去的，头都晕了

1554961345(1).png753×455 18.1 KB

#2

你这种方式应该是为了解耦设计的。但你的理解有点偏差，这种发消息尽量少用。

#3

哪里有偏差？求解

#4

看不懂你在干嘛，也没见你传消息啊，命令的话可以进行抽象，命令对象来发消息，可以写成openChatPabel.doSomething(obj)，obj是执行命令的对象,doSomething(){}里面可以写命令的逻辑。

#5

openChatPabel.doSomething(obj)，这样需要“拖”，就是为了嫌弃“拖”太累了，单例太多很恶心，所以独立于cocoscreator，另外开发了一套消息传递的代码

微信图片编辑_20190411144114.jpg753×455 35.4 KB

#6

类似于这样分发消息

#7

不知道你说的拖什么意思，你把所有命令写成类，再写一个命令管理类管理命令对象不可以吗，跟cocos没关系啊，你只要操作管理类这个单例。

#8

commandManager.getInstance().getCommand(命令名).exec(this,msg)

#10

我内部的实现类似于这样，但是最后我还是优化成这个样子了！这样简洁很多，可以传递到每一个框架之内脚本之中！但是消息多了容易乱

#11

就像这样,一个项目下来，一两百这样的玩意

#12

命令少就用命令 多的话根据你实际需求用其他方式来做 优化也没用

#13

就像家具被选中这种事情你为什么 不把它作为一个变量定义在物品类中呢 重要事情又不好抽象出来你再用通知

#14

而且看你写的 好像对命令理解有误 命令是一个可以执行的对象 你这种更像是事件枚举

#15

说实话，很像puremvc的思维，puremvc就是这样搞的

#16

这种跟android 的 pushMessage 和 handler 有点像。有点折腾啊:mask:

#17

cocoscreator的事件分发机制就很好用啊，被观察者<==>消息队列<==>listener<==>真正的观察者，被观察者和观察者彻底解耦了。你这个，观察者和消息队列、listener是一个东西（放在一起的），肯定扩展不好。

你的要求是一对一的回调，最好的办法还是用消息队列来做。你这个还不算真正意义上的事件分发，就是根据enum的回调。

#18

引擎本身的分发机制，无法向下分发事件的，没办法！我只不过拓展了一下，真正意义上，实现了每一个脚本都可以接受到自己需要的信息

#19

一对一，一对多都行！无法回调

#20

无法向下分发事件？什么意思？

#21

事件冒泡