Design patterns 观察员/通知与代表

假设我有以下应用程序：

在这个应用程序中，我有一个带有两个按钮的菜单，一个按钮带我进入帖子屏幕，另一个按钮只带我进入喜欢的帖子屏幕

在两个视图中，实际的帖子以完全相同的方式呈现，不同之处在于，其中一个视图中，所有帖子都会选择“相似”按钮（相似的帖子屏幕），而另一个视图中会有一些帖子未选择“相似”按钮（帖子屏幕）

例如，如果我在posts屏幕中，单击一篇文章的like按钮，PostView将向PostController报告其like按钮已被单击，PostController将使用Server类更改该文章的like状态，然后PostController将更新PostView的like按钮以供选择或取消选择（与以前的状态相反）

现在，如果我单击like按钮来更改Posts屏幕中的post-like状态，那么like按钮视图应该在Posts屏幕和Liked-Posts屏幕的两个位置都会更新。 我可以想出两种方法：

1） PostController（通过委托）向PostsController报告其状态已更改，PostsController（通过委托）向MenuController报告，MenuController告诉LikedPostsController某些post的like状态已更改，LikedPostsController告知其PostController，后者告知其PostView更新like按钮（如果更改为selected）或从LikedPostsController的视图中删除帖子（如果更改为unselected）

2） 使所有PostController都成为服务器的观察者，这样服务器就可以在每次更改某个类似post的状态时发送通知

哪一个更好，为什么

---

谢谢。

如果服务器同时拥有两个列表：帖子、喜欢的帖子，那么让服务器通知感兴趣的观察者会更有意义。在最基本的层面上，喜欢/取消链接帖子应该像刷新帖子列表一样处理。这简化了应用程序的设计，因为对两个列表中的任何一个感兴趣的组件都可以订阅该列表（观察它），并且还提供了组件之间的解耦。虽然我必须说我不太喜欢调用这个组件服务器，但作为服务器组件，应该只发出服务器API请求

---

另一种方法强制您添加和维护多个委派级别，还耦合组件，因为根控制器需要知道需要更新多少个控制器。如果出现另一个列表（例如书签帖子），则需要相应地更新控制器，这可能会非常繁琐且容易出错。

我在这里简化了一些细节，这就是为什么我只有Server类。尽管如此，服务器并没有保存2个列表，而是保存一个帖子列表，每个帖子都有一个名为isLiked的属性。服务器（或其他中产阶级）可以有两个方法，retrieveAllPosts（）和retrieveLikedPosts（）。关于刷新，如果我转到“喜欢的帖子”屏幕，单击“喜欢”按钮（不喜欢它），在服务器响应返回之前，我转到“帖子”屏幕，它根据缓存的帖子刷新其帖子（未链接的帖子仍然被认为是喜欢的，因为服务器响应没有……返回），然后服务器响应返回，post应该在Posts屏幕中将其like按钮状态更改为unselected。我不想再次刷新，因为可能用户已经浏览了帖子。我也不喜欢所有的委托链，但我也不喜欢通知，因为随着应用程序的增长，它往往很难理解应用程序流。有时，您发送通知时只希望一个位置得到更新，但多个位置得到更新，您最终不得不创建一组条件。我期待第三个更好的解决方案（可能=）我都不喜欢通知，很多时候主要是为了方便而不是为了设计。我的建议是，如果不清楚的话，应该有一个组件，让我们称之为PostsHolder，一旦从服务器接收到，它将在内存中保存帖子列表。这个组件公开了两个属性-posts和likedPosts（likedPosts可以从posts动态生成），并使用它将post标记为like/unliked。一旦post状态发生变化，它会通知其观察者likedPosts属性已发生变化。顺便问一下，您是否考虑了特定的平台？”因为我可能会用更具体的平台术语来描述解决方案。