我将开发一个工具来执行以下操作：
从客户端，它每 5 或 10 分钟向服务器发送一次请求。然后服务器然后发送文件列表。这部分称为“收藏”。'collection'之后，需要进行'export'（合并所有在'collection'期间收集的文件。
我的想法是，上面的“收集”和“导出”动作就像“生产者”和“消费者”。那么，我可以使用“观察者”模式来实现上述操作吗？如果没有，请提出任何其他设计模式。
问候， Kannan DV
由于这两个组件自然是松耦合的，因此您可以分别设计、实现和测试它们。我不认为这里存在对已知模式之一的内在需求。
但是，如果您希望接收来自收集器的通知，您确实可以查看观察者模式：
观察者。定义对象之间的一对多依赖关系，以便当一个对象更改状态时，它的所有依赖项都会自动得到通知和更新。
另一方面，据我了解，导出不会在导出器请求时完成，而是在固定的时间间隔内完成，因此导出器可以随时获取集合，因此您可能需要在收集器中使用一些缓存机制（而不是通知系统）。
观察者模式可以通过正确的设计应用在这里......您目前正在轮询您的服务器并消化数据，这本质上不适合观察者模式（如果我正确理解您的帖子）。这里有两个不错的选择是让服务器在更改/更新/添加准备好导出时通知 JMS 队列，然后您可以使用观察者模式接收消息并消化它们。或者，您可以让您的服务器将数据发布到提要（如 RSS），然后有一个服务来轮询提要并创建通知（当自上次提要更新以来发生更改时）。然后你可以使用观察者模式来消化数据。
如果服务器可能非常频繁地生成导出数据，那么这些选项都不太适合......但是，如果它们是受控间隔（及时）或仅在一定数量的数据时推送数据可用（而不是在频繁变化的环境中推动每个变化），那么这可能是一个很好的模型，因为它使您的组件保持松散耦合和可重用。服务器的直接轮询可能会创建一个不可重用的组件（在这里可能没问题，我不知道）。
希望有帮助。
听起来很有希望。为了在这里给出一个好的建议，有人可能需要更多关于你的背景和你对工具的期望的信息。为您的组件找到正确的责任分配取决于您。
我发现这篇文章非常有助于找到正确的组件切片：
这里的难点是确保/管理生产者需要知道消费者成功接收到集合的事实。
当它发送文件但没有收到确认回执时，它是否会自动将文件留在原地以供下一次收集并让消费者将其全部整理出来，还是需要 UI 将其作为人工任务进行管理， 或者是什么？
服务器无法主动通知收集器，这就是收集器轮询服务器的原因。这意味着收集器和服务器之间没有适用的观察者模式。
如果你想让导出器自主启动它的进程，你可以给它一个 BlockingQueue，收集器在它上面放置一个通知（即一个指示哪些文件需要导出的“作业”对象）。exporter 反复调用 queue.take() 来获取下一个 Job。请注意，BlockingQueue.take() 会等待队列中的元素可用，而不会占用 CPU。请参阅：http: //java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html，其中包含一些示例代码。