这是什么意思？“用户不应该决定它是否是管理员。特权或安全系统应如此。”

问题中使用的示例将最少的数据传递给函数，以确定是否用户是管理员的最佳方法。一个常见的答案是：

user.isAdmin()

这引起了评论，该评论被重复了多次并被多次投票：

用户不应该确定它是否是管理员。特权或安全系统应该。与课程紧密联系并不意味着将其纳入课程是一个好主意。

我回答，

用户没有决定什么。用户对象/表存储有关每个用户的数据。实际用户不会改变自己的一切。

但这没有效果。显然，存在潜在的视角差异，这导致沟通困难。有人可以向我解释为什么user.isAdmin（）不好，并绘制一个简短的草图来“完成”吗？

确实，我看不到将安全与受保护系统分开的优势。任何安全性文字都将要求从一开始就将安全性设计到系统中，并在开发，部署，维护乃至报废的每个阶段都要加以考虑。它不是可以固定在侧面的东西。但到目前为止，此评论有17票赞成票，表明我错过了一些重要的内容。

将用户视为键，将权限视为值。

不同的上下文可能对每个用户具有不同的权限。由于权限与上下文相关，因此您必须为每个上下文更改用户。因此最好将逻辑放在其他地方（例如上下文类），然后在需要的地方查找权限。

副作用是它可能使您的系统更安全，因为您不能忘记清除与管理无关的地方的admin标志。

该评论措辞不佳。

关键不在于用户对象是否“决定”它是管理员，试用用户，超级用户还是其他与众不同的对象。显然，它并没有决定任何事情，而是由您实施的整个软件系统都可以。关键是“用户” 类是应该代表其对象所代表的主体的角色，还是这是另一类的责任。

我不会选择原始评论的措词方式，但它确实标识了潜在的合法问题。

具体而言，保证分离的关注点是身份验证与授权。

身份验证是指登录并获取身份的过程。系统就是这样来了解您的身份的，并用于诸如个性化，对象所有权等之类的事情。

授权是指您被允许做的事情，（通常）这不是由您是谁来决定的。取而代之的是，它由某些安全策略（例如角色或权限）确定，这些策略不关心您的姓名或电子邮件地址。

这两个可以彼此正交变化。例如，您可以通过添加OpenID / OpenAuth提供程序来更改身份验证模型。您可以通过添加新角色或从RBAC更改为ABAC来更改安全策略。

具有讽刺意味的是，如果所有这些都归为一类或抽象，那么作为降低风险的最重要工具之一的安全代码将变成高风险。

我曾在身份验证和授权过于紧密的系统上工作。在一个系统中，有两个并行的用户数据库，每个数据库都用于一种“角色”。设计它的人员或团队显然从未考虑过单个物理用户可能同时担任两个角色，或者可能有多个角色共有的某些操作，或者User ID冲突可能存在问题。这是一个公认的极端示例，但是使用它非常痛苦。

Microsoft和Sun / Oracle（Java）将身份验证和授权信息的集合称为“ 安全主体”。它不是完美的，但是效果很好。例如，在.NET中，您具有IPrincipal，它封装了IIdentity-前者是策略（授权）对象，而后者是身份（身份验证）。你可以合理质疑把一个决定内其他的，但重要的是，大多数的代码编写将是抽象的只有一个，这意味着它很容易测试和重构。

一个User.IsAdmin字段没有什么问题... 除非也有一个User.Name字段。这表明“用户”的概念定义不正确，可悲的是，这是在安全性方面有些耳熟能详的开发人员中的一个常见错误。通常，身份和策略应该共享的唯一内容是用户ID，而并非巧合的是，这正是Windows和* nix安全模型中如何实现的。

创建封装身份和策略的包装对象是完全可以接受的。例如，这将有助于创建仪表板屏幕，除了允许当前用户访问的各种小部件或链接之外，您还需要显示“ hello”消息。只要此包装器仅包装身份和策略信息，并且不声称拥有它即可。换句话说，只要它没有以合计root的形式出现。

由于YAGNI等原因，当您初次设计新应用程序时，简单化的安全模型似乎总是个好主意，但它几乎总是最终会在以后给您带来麻烦，因为令人惊讶的是，增加了新功能！

因此，如果您知道什么最适合您，则将身份验证和授权信息分开。即使现在的“授权”就像“ IsAdmin”标志一样简单，但是如果它与身份验证信息不在同一类或表中，那么您仍然会更好，以便在需要时以及何时需要使用安全策略更改后，您无需在已经运行良好的身份验证系统上进行重建手术。

好吧，至少它违反了单一责任原则。是否应该进行更改（多个管理员级别，甚至还有更多不同的角色？），这种设计相当混乱且难以维护。

考虑将安全系统与用户类别分离的优势，以便两者都可以具有单一的，定义明确的角色。您最终将获得更清洁，更易于维护的整体设计。

我认为这个问题，也许措辞不佳，是因为它对User全班同学施加了太大的压力。不，User.isAdmin()正如那些评论所建议的那样，使用method不会带来安全问题。毕竟，如果有人对您的代码足够深入，可以为您的核心类之一注入恶意代码，那么您将遇到严重的问题。另一方面，User对于每个上下文确定它是否是管理员都没有道理。假设您添加了不同的角色：论坛的主持人，可以将帖子发布到首页的编辑者，可以编写内容供编辑者发布的作家，等等。通过将其放在User对象上的方法，您将最终获得太多的方法和太多的逻辑，这些逻辑和逻辑User与该类没有直接关系。

相反，您可以使用不同类型的权限的枚举和一个PermissionsManager类。也许您可以使用类似的方法来PermissionsManager.userHasPermission(User, Permission)返回布尔值。实际上，它看起来像（在Java中）：

if (!PermissionsManager.userHasPermission(user, Permissions.EDITOR)) {
  Site.renderSecurityRejectionPage();
}

从本质上讲，它等效于Rails方法before_filter，该方法提供了在现实世界中这种类型的权限检查的示例。

Object.isX（）用于表示对象和X之间的明确关系，可以将其表示为布尔结果，例如：

Water.isBoiling（）

Circuit.isOpen（）

在系统的每个上下文中， User.isAdmin（）都具有“管理员”的单一含义，即在系统的每个部分中，用户都是管理员。

虽然听起来很简单，但实际的程序几乎永远都不适合该模型，但是肯定会需要用户管理[X]资源而不是[Y]，或者需要更多不同类型的管理员（[项目]管理员与[系统]管理员）。

这种情况通常需要对需求进行调查。很少，如果有的话，客户端会希望User.isAdmin（）实际代表的关系，所以我会犹豫地实施任何此类解决方案，而无需澄清。

海报的构思只是一个不同且更复杂的设计。 我认为User.isAdmin()很好。即使您稍后介绍了一些复杂的权限模型，我也没有理由提出任何理由User.isAdmin()。稍后，您可能需要将User类拆分为一个代表登录用户的对象和一个代表该用户数据的静态对象。否则，您可能不会。为明天保存明天。

真的不是问题...

我认为没问题User.isAdmin()。我当然喜欢它，而不是诸如之类的东西PermissionManager.userHasPermission(user, permissions.ADMIN)，它以SRP的圣名使代码不太清晰，并且不会增加任何有价值的东西。

我认为某些人对SRP的解释有些不确切。我认为这很好，甚至最好让类具有丰富的接口。SRP只是意味着对象必须将不属于其单一职责的所有内容委派给协作者。如果用户的管理员角色比布尔字段更多，则将用户对象委派给PermissionsManager可能很有意义。但这并不意味着保留用户isAdmin方法也不是一个好主意。实际上，这意味着当您的应用程序从简单升级为复杂时，您需要更改使用User对象的代码。IOW，您的客户不需要知道实际要回答用户是否是管理员的问题。

...但是您为什么真正想知道？

就是说，在我看来，您几乎不需要知道用户是否是管理员，而是能够回答其他问题，例如是否允许用户执行某些特定操作，例如更新小部件。如果是这样，我希望在Widget上有一个方法，例如isUpdatableBy(User user)：

boolean isUpdatableBy(User user) {
    return user.isAdmin();
}

这样，窗口小部件负责知道必须满足哪些条件才能被用户更新，而用户则负责知道它是否是管理员。这种设计可以清楚地传达其意图，并且可以在需要的时候更轻松地过渡到更复杂的业务逻辑。

[编辑]

这个问题不具有User.isAdmin()与使用PermissionManager.userHasPermission(...)

我想补充一下我的答案，如果我想知道用户是否是管理员（或具有管理员角色），为什么我更喜欢在User对象上调用方法而不是在PermissionManager对象上调用方法。

我认为可以假设您总是要依赖User类，无论您需要问这个用户是admin吗？这是您无法摆脱的依赖。但是，如果您需要将用户传递给另一个对象，以询问有关该对象的问题，则将在您已经对用户拥有的对象之上，对该对象创建新的依赖关系。如果这个问题被问了很多，那么在很多地方您会创建一个额外的依赖项，并且如果有任何一项依赖项要求您可能需要在很多地方进行更改。

将此与将依赖项移到User类中进行比较。现在，突然有了一个系统，在该系统中，客户端代码（需要问这个问题的代码是该用户是admin）没有与如何回答此问题的实现耦合。您可以自由地完全更改权限系统，并且只需要更新一个类中的一个方法即可。所有客户端代码保持不变。

在isAdmin我看来，坚持在User 上没有方法是因为担心会在权限子系统的User类中创建依赖项，这类似于花一美元赚一毛钱。当然，可以避免在User类中使用一种依赖关系，但是要在需要询问问题的每个地方都创建一个依赖关系。不好讨价还价。

这次讨论使我想起了Eric Lippert的Blog Post，在有关类设计，安全性和正确性的类似讨论中引起了我的注意。

为什么要密封这么多框架类？

特别是，埃里克提出了以下观点：

4）安全。多态性的全部意义在于，您可以绕过看起来像动物但实际上是长颈鹿的对象。这里存在潜在的安全问题。

每次实现一个采用未密封类型实例的方法时，都必须将该方法编写为在面对该类型可能具有敌意的实例时具有鲁棒性。您不能依赖任何您知道对您的实现都是正确的不变量，因为某些敌对的网页可能会使您的实现成为子类，重写虚拟方法来做弄乱您的逻辑的事情，并将其传递给我。每次我密封一个类时，我可以写出使用该类的方法，并且确信我知道该类的作用。

这似乎是切线，但我认为这与其他张贴者提出的有关SOLID 单一责任原则的观点相吻合。将以下恶意类视为不实现User.IsAdmin方法或属性的原因。

public class MyUser : User
{

    public new boolean IsAdmin()
    {
        // You know it!
        return true;
    }

    // Anything else we can break today?

}

当然，这有点麻烦：尚无人建议创建IsAmdmin虚拟方法，但是如果您的用户/角色体系结构最终变得异常复杂，则可能会发生这种情况。（或者可能不是。考虑public class Admin : User { ... }：这样的类可能恰好在上面的代码中。）将恶意二进制文件放置到位不是常见的攻击媒介，并且比晦涩的用户库具有更大的混乱可能性-然后，再次可能是“ 特权升级”错误，它打开了真正的恶作剧之门。最终，如果恶意二进制或对象实例确实在运行时找到了方式，那么想象“特权或安全系统”以类似方式被替换就不费吹灰之力了。

但是请记住Eric的观点，如果将用户代码放在特定类型的易受攻击的系统中，也许您确实输了游戏。

噢，为了准确起见，我同意以下问题中的假设：“用户不应决定它是否是管理员。该特权或保障体系”一个User.IsAdmin方法是一个坏主意，如果你正在运行的系统的代码，你不要停留在代码的100％的控制-你应该做的，而不是Permissions.IsAdmin(User user)。

这里的问题是：

if (user.isAdmin()) {
   doPriviledgedOp();
} else {
   // maybe we can anyway!
   doPriviledgedOp();
}

要么您已经正确设置了安全性，在这种情况下，特权方法应检查调用方是否具有足够的权限-在这种情况下，检查是多余的。或者，您没有并且正在信任一个非特权类来自己决定安全性。