这样的情况下，其实做到了解耦的，是Blackboard自己，而不是通信双方。通信各方之间可能不会产生代码耦合，但是实际逻辑是耦合的。

解耦的本质

对解耦代码的两方来说，使用约定接口来交换信息，这一接口通常只有几个非常简练的约束，而不过于限制具体细节。

比如，我向通信的对方发送了数据，或者发起了事件，如果我不知道对方拿我的数据有什么用，怎么用，那就是真正的解耦。

假如我的逻辑需要清楚地知道通信对方拿我的数据用来干什么，如果我不知道会破坏逻辑，那就不是真正的解耦。

正面例子：

C#中随处可见的委托机制。在特定的时机提供一个可供订阅的事件，事件订阅者有多少，订阅后他们会在触发时机做什么，对于事件发布者来讲都是不知道，并且也不关心的。

反面例子：

Blackboard模式。Blackboard保存着无数据的格式，任意对象可以向它写入数据，任意对象可以从它中读取数据。

Blackboard不能识别存在它里面的数据，而Blackboard也不需要知道它内部存储的数据的任何事情，就可以正常运作。

这样的情况下，其实做到了解耦的，是Blackboard自己，而不是通信双方。通信各方之间可能不会产生代码耦合，但是实际逻辑是耦合的。

这些逻辑明明是耦合的，而这些代码却似乎没有任何关系，这只会导致一些难以理解的代码，弱化了类型约束，使得编译器无法处理明显错误的逻辑。