我有一个项目，该项目大量使用wx pubsub与代码的各个部分进行通信。对于任何给定的消息，可能会吸引1至5个不同的订阅者。
在以前的代码版本中，我有一个很大的听众字典，看起来像：
{"SENSOR_FLIP": "SENSOR FLIPPED",
"ALARM_TRIGGERED": "ALARM TRIGGERED",
etc}
并且我将订阅代码中对那些事件感兴趣的各个部分。当代码开始变大并且大多数对象的初始化中都有订阅列表时，问题就开始了。这很笨拙，成为一个问题，使您很难更改消息的任何内容或知道接收到的内容。
因此，我尝试将消息标准化为3种类型：TASK，INFORM和STATUS，开头带有一个标识符，以显示谁发送了它（广义标识符，因此它将发送“传感器状态”而不是“传感器17状态”。然后，我订阅了我感兴趣的一般区域，并让听众进行排序，以了解听众是否真正感兴趣。问题出在信号“接口任务”上-一堆，每个传感器，测站，整个系统中的服务，警报，指示灯等，将它们抓住并分类。
是否有更好的方法来组织此活动？我能想到的就是回到特定的信号命名和config中的一组列表，充实每个对象感兴趣的内容，然后在每个对象的初始位置进行映射以订阅列表中的每个对象。] >
关于如何做得更好的任何想法？
我有一个项目，该项目大量使用wx pubsub与代码的各个部分进行通信。对于任何给定消息，1-5个不同的订户可能会感兴趣。在以前的版本中...
您未按预期使用pubsub。发布/订阅的概念是为了减少事件的生产者（发布者）和客户（订阅者）之间的耦合。在pubsub范式中，发布者不知道订阅者是谁，或者他们对信号做什么。当您制作“大型听众字典”时，当您说“什么在接收什么”变得很难时，表明您正在尝试重新耦合各个模块。我不明白您要解决什么问题，但是无论如何，听起来pubsub对您来说是错误的工具，或者您可能还没有考虑如何使用它。