得墨忒尔定律——你能走多远？

Question

我想遵循德墨忒尔法则。当我在代码中搜索“两个点”时，我发现自己问自己是否真的值得在这种类型的上下文中设置委托职责：

从

class Activity
  def increment_user_points!
    self.user.increment_points!(points, true)
  end
end

到

module UserDelegator
  def user_increment_points!(points, increment_credits=false)
    self.user.increment_points!(points, increment_credits)
  end
end

class Activity
  include UserDelegator

  def increment_user_points!
    user_increment_points!(points, true)
  end
end

您的想法是什么？

Answer 1

你的例子并没有违反德米特法则。用户是 Activity 的一个属性，并且您正在访问用户的公共 API 方法，因此原始实现不会出现错误。

德米特定律的目标是避免破坏对象封装。你的“两点”方法有点过于简单化了这个想法。实际上，您应该检查对象是如何交互的，并确保您没有过多地了解其他对象的属性或关系。例如，如果以下情况违反规则：

def update_user_address
  @user.address.set(new_address)
end

这将是因为该地址是用户的业务，并且应该通过用户的 API 适当封装对其的访问。作为用户的客户端，我们永远不应该直接访问用户属性的 API。

同样，在您的示例中，您直接使用用户 API，这很好并且没有违反德米特法则。综上所述，我发现一般规则是一个很好遵循的规则。如果您避免破坏对象封装（如图所示），您的代码通常会更容易更改和维护，并且类将更容易重构。

Answer 2

我实际上希望看起来更像这样：

class User
  def increment_points!(points, increment_credits)
    @points+=points if increment_credits
    @points-=points unless increment_credits
  end
end

class Activity
  def increment_user_points!
    @user.increment_points!(points, true)
  end
end

创建一个包含 include 的模块似乎会产生更多复杂性。德墨忒尔法则的全部要点（我更喜欢将其视为指南......）是，您应该能够对用户的内部进行任何您喜欢的操作，而不必在类外重写大量代码。您的 UserDelegator 模块没有多大帮助——当您摆弄 User 的内部结构时，您仍然需要重写该代码。

但如果是我，我认为我不会为此烦恼，除非您发现自己重写了很多代码来对 User 进行简单的更改。也许这只是因为我习惯了 Linux 内核编码风格，它经常违反 Demeter 定律：

static inline int need_reval_dot(struct dentry *dentry)
{
    if (likely(!(dentry->d_flags & DCACHE_OP_REVALIDATE)))
        return 0;

    if (likely(!(dentry->d_sb->s_type->fs_flags & FS_REVAL_DOT)))
        return 0;

    return 1;
}

三个对象远离:)并且我不确定如果这样写代码会更清晰：

need_reval_dot(dentry) {
    if(likely(!dentry_need_reval_dot(dentry))
        return 0;
}

dentry_need_reval_dot(dentry) {
    return superblock_need_reval_dot(dentry->d_sb);
}

superblock_need_reval_dot(sb) {
    return fs_type_need_reval_dot(sb->s_type);
}

fs_type_need_reval_dot(s_type) {
    return fs_flags_need_reval_dot(s_type->fs_flags);
}

fs_flags_need_reval_dot(fs_flags) {
    return fs_flags & FS_REVAL_DOT;
}

所以我所有人都赞成适度遵循准则——问问自己，您的修改是否实际上会导致更干净、更易于维护的代码，或者是否只是为了遵循规则而遵循规则。