得墨meter耳定律-您走了多远？

如何解决得墨meter耳定律-您走了多远？

| 我想遵循德米特法则。在我的代码中搜索“两个点”时，我发现自己在这种情况下是否值得设置委派职责：从

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

你怎么看？

解决方法

您的示例没有违反Demeter定律。用户是活动的属性，并且您正在访问该用户的公共API方法，因此您不会对原始实现产生错误。得墨meter耳定律的目标是避免破坏对象封装。您的“两个点”方法有点过于简化了这个想法。实际上，您应该检查对象之间的交互方式，并确保您对其他对象的属性或关系的了解不深。例如，如果以下情况违反了该规则：

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

这是由于该地址是用户的事，因此它应该通过用户的API适当地封装对它的访问。作为用户的客户端，我们永远不应直接访问用户属性的API。同样，在您的示例中，您直接使用了用户API，这很好并且没有违反Demeters Law。综上所述，我发现一般规则是可以遵循的好规则。如果您避免破坏所示的对象封装，通常将更容易更改和维护您的代码，并且更容易重构类。 ,我实际上希望TO看起来像这样：

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

将模块创建为“ 4”似乎会带来更多的复杂性。而且，《得墨the耳法则》的重点（我想将其更多地看作是一个指导原则。）您应该能够对ѭ5s的内部做任何您想做的事情，而不必在课堂外重写很多代码。您的UserDelegator模块并没有多大帮助-摆弄User's内部时，您仍然可以重新编写该代码。但是如果是我，除非您发现自己重写了很多代码以对ѭ5进行简单更改，否则我什至不会为之烦恼。也许这仅仅是因为我已经习惯了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;
}

因此，我全都赞成遵循适度的准则-问问自己，您的修改是否确实导致了更简洁，更可维护的代码，或者仅仅是为了遵循规则而遵循规则。