有一个代码气味的时刻，无法决定一个类是否可以被观察并且也是一个观察者，所以我想我会在这里发帖。
class ObservableAndObserver extends Observable implements Observer {
// Class is ofcourse registering and receving notifcations on different events
// effectly actving as a middle man.
// Is this a pattern in itself? 'middleman-pattern' ??
}
想法？破坏 SRP？
这在技术上是可以的，但您应该检查您不是简单地重新传输收到的通知。如果这个类正在观察 class1，然后被 class2 观察，请尝试让该类观察 class1。
我看不出有什么理由不这样做。不过，一个具体的例子会很有用。更好的是你已经实现的真实代码，我们可以批评。
没关系 ：-）。如果类订阅其他类事件并且可以引发自己的事件，那没关系。当然你可以做错，但是类的概念来寻找其他类并且是可观察的是可以的。
虽然我同意 Neil 的观点，但我可以看到这是一种代码味道，因为该类可能做的太多了。
只要对象观察到其他对象的事件并且被其他对象观察到就可以了。但如果物体观察到自己，可能会有一些非常奇怪的东西。
也许一些代码将有助于理解设计模式是否以一种奇怪的方式使用。
这是许多基于事件的系统实现过滤器的一种方式。另一个在 Java 中，有一个用于其中一个角色的内部类，但如果过滤器有多个具有不同角色的观察者，这会更常见。因此，如果您认为它最终可能具有不同的角色，您可能希望它具有您当前想到的角色的访问器getObserver() { return this; }，但这可能是 YAGNI 并且可以稍后添加。
这是邪恶的。b 观察 a 并通知 c。
所以有一段代码说 a.setValue(...) 并且在 c 中发生了一些事情。
现在想想：那段代码应该说：a.setValue(...); c.doSomething(...);
当然，那段代码现在必须知道 a 和 c，但至少没有魔法。一切都在阳光下。oo 中隐藏的信息是观察者/可观察模式中 setValue(...) no 中的代码乘以 2。
干杯，L。
您可能会误入一个名为Event Channel的 Publisher-Subscriber 模式的变体， POSA 书中清楚地引用了它：
“在这个变体中，一个事件通道被创建并放置在发布者和它的订阅者之间。对于发布者，事件通道显示为订阅者，而对于订阅者，它显示为发布者”。（第 341 页）