类设计决策

Question

我有一个小难题，也许你能帮我解决。

今天我一直在修改 ASP.NET 的成员身份以添加间接级别。基本上，ASP.NET 的成员资格支持用户和角色，所有授权规则都基于用户是否属于角色。

我需要做的是添加功能的概念，其中用户将属于一个角色（或多个角色），并且该角色将具有一个或多个与之关联的功能，允许我们根据用户是否属于来授权特定操作分配给已分配功能的角色。

话虽如此，我的问题与此无关，这是一个通用的类设计问题。

我想在我的 RoleProvider 基类中提供一个抽象方法来创建该函数（并持久化它），但我希望可以选择保存该函数的描述，因此我需要使用重载创建 CreateFunction 方法，一个签名接受名称，另一个接受名称和描述。

我可以想到以下场景：

1. 使用 Abstract 修饰符创建两个签名。这存在的问题是，实现者可能不尊重最佳实践，即一个重载应该使用规范化的参数调用另一个重载，并且逻辑应该只在最后一个重载中（具有所有参数的重载）。此外，要求开发人员同时实现这两种方法也不太好。

2. 创建第一个像虚拟的，第二个像抽象的。从第一个调用第二个，允许实现者覆盖该行为。它也有同样的问题，实施者在覆盖它时可能会做出“错误的决定”。

3. 与以前相同，但不允许覆盖第一个（删除 virtual 修饰符）。这里的问题是，实现者必须意识到可以使用空描述来调用该方法，并且必须处理这种情况。

我认为最好的选择是第三种...

一般如何处理这种情况？当您设计一个抽象类并且它包含重载方法时。我认为这种情况并不少见...

Answer 1

我觉得 DRYness 和强制合约的最佳组合如下（伪代码）：

class Base {
  public final constructor(name) {
    constructor(name, null)
  end

  public abstract constructor(name, description);
}

或者，或者：

class Base {
  public abstract constructor(name);

  public final constructor(name, description) {
    constructor(name)
    this.set_description(description)
  }

  private final set_description(description) {
    ...
  }
}

Java 中有一条规则支持这个决定：“永远不要从构造函数中调用非最终方法。”

Answer 2

要回答您帖子的第一部分，请查看 AzMan（授权管理器），顺便说一句，它内置于 Windows 中。它能够指定可以重新组合为角色或直接分配给用户的操作。

查看

为了回答你问题的第二部分，我不会使用抽象类。相反，只需在构造函数中提供功能并完成即可。看起来您想要指定的行为，并且不希望它改变。为什么要强迫后代提供实施。