解耦通知的两个类答案

【问题标题】：Decoupling two classes for notifications解耦通知的两个类
【发布时间】：2013-01-19 12:53:06
【问题描述】：

我只是盯着 Poco 框架。我有另一个底层框架，它已经在使用 Poco 框架并抽象了它的某些部分以使其更加容易。

我想用一个简单的场景来解释这个问题：
考虑我的程序中有一个矩形对象。该形状内部具有私有 hit Testing 方法，并且在命中测试为真一段时间后，我不得不在另一个类中触发一个函数，即我的 Fountain 类。

我不需要将任何特定的形状对象信息传递给Fountation 类中的函数。我的框架已经为我提供了NotifyEvent 和AddListener 的一些功能。如果我采用这种方法，我的形状类中会有一个事件，该事件将在喷泉中由 Add Listener 订阅（如果通过了形状，则为对象）和形状内的事件 notified类。

现在，使用 Poco 通知中心，我不会将形状对象引用传递给基础类，而是将 NotificationCenter 引用传递给第二个类。然后fountain 类将有一个观察者，观察者将从形状中收到postNotification()
我在这里看到的两种方法之间的唯一区别是不传递特定的对象信息。
我只是这里的新手开发人员，尽可能地学习良好的编码实践，并不清楚这里的解耦。这两个类在这里是如何解耦的？（因为我没有传递shape 对象而只是使用notificationcenter 对象？）

编辑：添加到上述问题。假设我有 10 个其他类必须收听某个通知，那么我还必须将 Notification Center 的引用传递给所有这些类吗？只有这样我才能在我的课程中为通知中心添加观察者。

【问题讨论】：

标签： c++ algorithm events poco

【解决方案1】：

基本上是的。如果Fountain 类只知道NotificationCenter，则它不再与形状（Rectangle 或其他）耦合。这假设形状发布的通知也不依赖于触发它的对象。

编辑：对您的编辑的回复是肯定的，您需要为每个需要通知的对象调用 addObserver 方法

【讨论】：

还有其他查询。那么，我也可以使用相同的全局通知类型来发布来自其他对象的通知吗？假设从Fountain class 为其他课程设置通知。这也是正确的吗？ P.S 你能推荐一些教科书，让我在编写程序时能有更好的想法，从而真正了解什么是好、坏还是更好？
是的，Fountain 类也可以使用通知系统。我会小心我如何使用它。如果所有通信都通过这个系统，可能会更难了解正在发生的事情。
tomislav 推荐的这本书非常经典，你不会错的。我想说你已经需要很好的面向对象设计知识才能充分利用阅读它。

【解决方案2】：

你应该做的是将消息发送和接收过程解耦成一个Observer - Listener结构。这称为观察者模式。您可以阅读有关此模式的更多详细信息here。这将使您免于处理多个引用和事件，以及每次需要将通信添加到另一个类时考虑消息发送/接收实现。

你可以在Design Patterns. Elements of Reusable Object-Oriented Software一书中找到更多关于设计模式的信息。

【讨论】：

还有其他查询。那么，我也可以使用相同的全局通知类型来发布来自其他对象的通知吗？假设从 Fountain 类为其他类设置通知。这也是正确的吗？ P.S 你能推荐一些教科书，让我在编写程序时有更好的想法，以便真正了解什么是好、坏还是更好？但是如果我现在通过通知引用，那么这样做只是为了暂时避免进入观察者实现是错误的吗？
@user1240679 你需要以某种方式耦合观察者 - 监听器，到目前为止我所做的是在监听器类中保留对观察者的引用以使接口简单：更新（）而不是像一百万更新采用不同参数的函数。这是解决“推”和“拉”通信问题的两种标准方法。通过“推送”，您向更新方法提供了侦听器更新其状态所需的参数，通过“拉动”，您通知已经将 ref 存储到观察者的侦听器以更新自身。到目前为止，我使用的是拉动的方法。