我试图在涉及事件的编程环境中协调得墨忒耳定律——我标记了这个 javascript 和 obj-c（Cocoa 的 NSNotificationCenter），因为它们都允许事件。
在这样的环境中，您可以任意解耦任何两个对象，只需让它们抛出并绑定/订阅事件即可。在 obj-c 中，这样做会容易得多，而不是传递对需要调用方法的对象的引用。我认为这可能并不总是使用：从性能的角度来看，您错过了方法调度的优化（可能可以忽略不计，除非它是一个巨大的应用程序）。为了可读性，程序员可能希望明确指出一个对象是另一个对象的依赖项，这在对象只是抛出事件时并不明显。
我想对事件在软件架构中的作用提出一些想法：您喜欢如何平衡事件绑定和直接方法调用？
小心你的术语。GUI 上下文中的“事件”一词通常表示用户生成的事件，例如鼠标单击、敲击、按键等，而这些类型的事件通常不使用您所指的观察者模式来处理。在 Cocoa 和 Cocoa-Touch 中，使用责任链模式处理用户事件。
两种模式都促进对象之间的松散耦合，但观察者中的耦合可以说是松散的。参与责任链的对象通常都继承自一个公共基类或以其他方式遵循某个公共接口，并且链中的每个对象通常都知道它在链中的邻居。使用观察者，发送消息的对象（例如 Cocoa 中的通知）不知道哪些对象可能接收到消息，而接收消息的对象通常不知道消息从何而来。特别是在 Cocoa 和 NSNotificationCenter 中，甚至没有一个通用接口——每个“观察者”对象在注册接收通知时都会注册一个通知处理程序。
如果你过度使用观察者模式，你可能会弄得一团糟。调试一堆消息可能非常困难。更糟糕的是，如果消息是同步传递给观察者的（通常是这样），发送消息的对象无法知道发送消息的成本可能有多高，接收消息的对象也不知道自己的性能如何可能会影响应用程序的其余部分。任何给定消息的观察者数量通常是无限的这一事实使得很容易意外地产生真正的性能问题。得墨忒耳法则的拥护者可能会咂舌说“我告诉过你”，但这并不意味着你应该避开观察者。使用得当并理解观察者不应该为响应消息做很多繁重的工作，