分离此代码关注点的最佳方法是什么？

Question

在 上一个问题来自博士的评论之一Herbie 接受的答案是我的方法正在执行两项职责......更改数据和保存数据。

我试图找出在我的情况下区分这些问题的最佳方法。

继续我的示例，通过 NHibernate 检索一个 Policy 对象......

我当前将策略设置为非活动状态的方式如下：

Policy policy = new Policy();
policy.Status = Active;

policyManager.Inactivate(policy);

//method in PolicyManager which has data access and update responsibility
public void Inactivate(Policy policy)
{
    policy.Status = Inactive;
    Update(policy);
}

如果我将数据访问和数据更新的责任分开，将会是什么最好的方法是什么？

是让PolicyManager（充当dao的网关）管理Policy对象的状态更好：

Policy policy = new Policy();
policy.Status = Active;

policyManager.Inactivate(policy);
policyManager.Update(policy);

//method in PolicyManager
public void Inactivate(Policy policy)
{
    policy.Status = Inactive;
}

还是让Policy对象维护它自己的状态，然后使用管理器类将信息保存到数据库：

Policy policy = new Policy();
policy.Status = Active;

policy.Inactivate();

policyManager.Update(policy);

//method in Policy
public void Inactivate()
{
    this.Status = Inactive;
}

Answer 1

我会做什么：

• 创建一个保存和检索策略的存储库。 (PolicyRepository)

• 如果您必须执行复杂的逻辑来激活/停用策略，您可以为此创建一个服务。如果该服务需要访问数据库，那么您可以在必要时将 PolicyRepository 传递给它。
  如果不涉及复杂的逻辑，并且激活/停用策略只需将标志设置为 false 或 true，或者仅涉及策略类的成员，那么为什么“激活”不是策略的简单属性您可以将哪个类设置为 false / true ？
  如果涉及其他对象，或者需要数据库访问来激活或停用策略，我只会创建一个服务。

Answer 2

作为我原来评论的延续:) ...
目前你最好的选择是第三个选项，但如果事情变得更复杂，你可以选择第二个，同时添加门面方法来执行预先指定的序列：

Policy policy = new Policy();

policy.Status = Active;

policyManager.InactivateAndUpdate(policy);


//methods in PolicyManager
public void Inactivate(Policy policy)
{
    // possibly complex checks and validations might be put there in the future? ...
    policy.Status = Inactive;
}

public void InactivateAndUpdate(Policy policy)
{
    Inactivate(policy);
    Update(policy);
}

InactivateAndUpdate 是一种门面方法，它只是用来进行调用代码更整洁一点，同时仍然允许执行实际工作的方法是单独的关注点（有点打破方法的单一责任，但有时你只需要务实！）。我特意以 XandY 风格命名这些方法，以使它们在做两件事时脱颖而出。

然后，InactivateAndUpdate 方法可以让您开始实现策略模式或将实际的实现方法拆分为用于动态处理的命令对象或将来可能变得可行的任何其他体系结构。

Answer 3

由于您提到的原因，我肯定会选择第三种选择：

Policy 对象维护它自己的
状态然后使用管理器类
将信息保存到
数据库

另请查看存储库模式。它可能会替代您的 PolicyManager。

Answer 4

如果状态是 Policy 类状态的一部分，那么 Policy 还应该具有 Inactivate 方法——这只是基本封装。将多个类纠缠在一个职责中至少与赋予单个类多个职责一样糟糕。

或者，状态可以被视为关于Policy的元数据，不属于Policy而是属于PolicyManager。但在这种情况下，Policy 根本不应该知道自己的状态。