Java 德米特法不适用于本案？

假设我有一个函数，它接受一个对象列表，比如：

class A{
  C c;
  C getC();
}

Class C{
  boolean propBool;
  boolean getPropBool();
}

public void someThing(List<A> lst){ 
  for(A a : lst){
    if(a.getC().getPropBool()){
      //do some stuff
    }
  }
}

---

这里的方法是什么？

取决于您在该

中执行的操作，如果您这样重写代码

for (A a : lst) {
    a.getC().doStuff();
}

在
C.doStuff（）中检查布尔值并实现逻辑。
LoD实际上不是一条定律。这实际上只是一个设计原则。它通常是有用的，但决不是普遍适用的。如果您认为它对您的用例不适用（或没有帮助），您可以忽略它。没有人会因为你违反LoD而起诉你

在您的用例中，您需要确定
C
是否是
A
的实现细节，以及隐藏它是否是一件好事。得墨忒尔定律不能为你回答这个问题。您需要根据用例的具体需求自行决定

但是，如果您决定
C
是
A
的一个实现细节，并且它应该被隐藏，那么Demeter定律说您应该实现类似于helper函数的东西。在这种情况下，它并非“极其无用”。它有一个特定的目的。。。这是为了隐藏实现细节。我会这样写：

public class A {
  private C c;
  private C getC() {...}
  public getTheProperty() {
    return this.getC().getPropBool();
  }
}

class C {
  private boolean propBool;
  boolean getPropBool();
}

（这是其中一种无法同时使用的情况。LoD适用且辅助对象不是无用的，或者不适用。）

请注意，我们无法就是否应在此处应用LoD向您提供建议。你的例子太抽象了。只有在现实的应用程序设计中才能做出有效的判断。
我仍然认为这违反了德米特定律。与其说是“定律”，不如说是“指南”；）不要过火，只要运用常识。如果你遵循这个原则，通常其他一切都会遵循。包括他所谓的“松耦合、高内聚”的“德墨忒尔定律”旨在促进。。附言：你的问题的答案必然是一个意见问题。鉴于这是一个虚构的例子，很难说什么是对的或错的。我认为，如果您关心的是函数采用
列表
，但它只关心对象
C
，那么您应该采用
列表
。或者，如果您的应用程序在Java>8上，那么您可以将其设置为
Stream
，然后执行
操作（a.Stream（）.map（v->v.getC（））基本上，我真正需要的是
C
和
C.getPropBool（）
，但是
C
是
a
中的一个字段，我得到了一个
列表，一个人说你可以更改参数以接收
流
（所以给它一个
lst.Stream（）.map（a:：getC）
相反，这更有意义，但是助手只有两行，这将是
流。anyMatch（C:：getPropBool）
，很难决定这里什么是正确的。因此，如果C不是a的隐藏实现细节，那么这就不是LoD适用的情况。在本例中，您的原始版本是正确的（IMO）。从LoD的角度来看，流解决方案与您的原始版本是等效的。回答很好，您能简要解释一下您所说的
实现细节的确切含义吗？
？这就像……您希望API的客户端了解并可能依赖于这一方面……还是不了解。对不起，英语不是我的第一语言，哪个API是w基本上，
someThing
函数实际上只需要一个
列表
，因为如果你看到的话，它根本不关心
A
的任何其他字段，但是我有一个
列表
而不是
列表
。我仍然不确定实现细节是什么
someThing
函数只关心
C
，而不关心
A
public class A {
  private C c;
  private C getC() {...}
  public getTheProperty() {
    return this.getC().getPropBool();
  }
}

class C {
  private boolean propBool;
  boolean getPropBool();
}