中介设计模式答案

【问题标题】：mediator design pattern中介设计模式
【发布时间】：2012-08-21 13:18:00
【问题描述】：

在我的系统中，我有 2 个类：User 和 LoginUser 类。 LoginUser 是用户的孩子。在 2 个对象 - User 和 LoginUser 之间可能存在各种通信（好友请求、照片请求、好友请求接受等）。基于 LoginUser 的成员身份，有各种安全权限，基于这些权限，会有不同的消息。

对于给定的场景，我应该使用哪种设计模式？我正在考虑使用调解器设计模式。

【问题讨论】：

孩子是什么意思？ LoginUser 是 User 的子类还是 User 有 LoginUser？您可能想多描述一下 LoginUser 和 User 中包含的内容。
LoginUser 是 User 的子类。用户包含姓名、电子邮件、会员资格等属性。LoginUser 包含执行编辑、登录等操作的一些特权。
好的，最后一个问题，我会尝试发布答案 - 所有用户都是 LoginUser 的吗？如果不是，那么不是的用户的示例是什么
是的。通信必须仅与 LoginUser 发生。这些类是根据行为分开的。假设我登录了我的系统，那么我是 LoginUser 的对象，其他用户是 User 类的对象。必须在 LoginUser 和 User 之间进行通信。

标签： design-patterns class-diagram

【解决方案1】：

这并不是真正的设计模式，但我会将这两个概念分开：权限和用户信息。

从可读性的角度来看，当我看到一个子类时，我通常会假设还有其他一些互斥的子类。例如，如果我看到一个 Animal 接口和一个 MeatEater 子类，我会假设在其他地方有一个 VeggieEater 子类。 LoginUser 是一个子类并且所有用户都是 LoginUsers 对我来说感觉不自然。

从设计的角度来看，您是 LoginUser，有 2 个不同的职责：
1) 用户名、邮箱、好友等房屋用户级别信息
2) 确定权限

我会尝试打破它。比如

public class User { 
  // keep info in here 
  private String username;
  private String email;
}


public class Authorization {
   // this will determine access
   public Authorization(User user) { this.user = user; }

   public boolean isAccessAllowed(String someAction) { // ... }
}

这样的事情会分解不同的职责。

【讨论】：

感谢@Jeff 的解决方案。现在我能够分清责任。但我必须将我的消息传递系统也整合到位。我想到了一个在 LoginUser 和 User 之间进行通信的 Communicator 类。请求好友、请求照片、接受好友请求等所有方法都是我的 Communicator 类的一部分。在 Authorization 类的帮助下，我可以获得 LoginUser 权限并在我的相应方法中使用相同的权限。现在如何合并我的消息系统？根据授权/方法，我有不同的消息。
我仍然不确定我是否完全理解 Communicator 的角色。也许您可以编辑您的问题并包含这些类中的一些示例代码，以提供更好的想法。