java - 实体惰性方法和 Dimetra 法

Question

我有实体:

@Entity
@Table(name = "CARDS")
public class Card {

  @ManyToOne
  @JoinColumn(name = "PERSON_ID", referencedColumnName = "ID", nullable = false)
  private Person person;

  @OneToMany(mappedBy = "card")
  private List<CardStatus> cardStatuses;

我的服务可以调用下一个代码:

public Card getCardBlaBlaBla(Long id){

   Card card  = cardRepository.findaCard(id);

   Something something = card.getCardStatuses().get(0).getSomething();
}

card.getCardStatuses().get(0).getSomething() - getCardStatuses 是 LAZY

我的问题 - 此挑战是否违反 Dimetra 法律？

The Law of Demeter There is a well-known heuristic called the Law of Demeter2 that says a module should not know about the innards of the objects it manipulates. As we saw in the last section, objects hide their data and expose operations. This means that an object should not expose its internal structure through accessors because to do so is to expose, rather than to hide, its internal structure. More precisely, the Law of Demeter says that a method f of a class C should only call the methods of these:

• C
• An object created by f
• An object passed as an argument to f
• An object held in an instance variable of C

The method should not invoke methods on objects that are returned by any of the allowed functions. In other words, talk to friends, not to strangers. The following code appears to violate the Law of Demeter (among other things) because it calls the getScratchDir() function on the return value of getOptions() and then calls getAbsolutePath() on the return value of getScratchDir(). final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

Card - 是数据结构，不违反 Dimetra 法则，但 LAZY 方法具有 logik(选择数据库)。

此挑战是否违反 Dimetra 法律？如果是的话我该如何正确使用它？

我确实有很多代码，例如:

entityOblect.getChield().getChield().getSomething();

编辑

摘自《Clean Code》书:

编辑2

(c) Robert C. Martin - 干净的代码

Active Record Active Records are special forms of DTOs. They are data structures with public (or beanaccessed) variables; but they typically have navigational methods like save and find. Typically these Active Records are direct translations from database tables, or other data sources. Unfortunately we often find that developers try to treat these data structures as though they were objects by putting business rule methods in them. This is awkward because it creates a hybrid between a data structure and an object. The solution, of course, is to treat the Active Record as a data structure and to create separate objects that contain the business rules and that hide their internal data (which are probably just instances of the Active Record).

Answer 1

这违反了德墨忒耳定律:

Something something = card.getCardStatuses().get(0).getSomething();

在一个语句中，您可以浏览所有这些对象:
Card -> List<CardStatus> -> CardStatus -> Something 。

理想情况下，您应该从客户端进行此通信:
Card -> Something .

在Card中类，Something return 可以通过执行此导航的方法来实现:
List<CardStatus> -> CardStatus -> Something 。

在某种程度上，最后一个也违反了德米特定律，但在我们可以认为可以接受的水平上，因为我们不应该考虑这种关系 List<CardStatus> -> CardStatus作为陌生人关系。

它可以给:

Something something = card.getSomethingOfCardStatuses(0);

或者避免使用 get 前缀:

Something something = card.findSomethingOfCardStatuses(0);

和findSomethingOfCardStatuses()可以在 Card 中定义如:

public Something findSomethingOfCardStatuses(int statusNumber){
    // add some check for the index if required 
    // you could return Optional or an Exception according to your requirements
    return cardStatuses.get(0).getSomething();
}

我知道许多开发人员喜欢在实体字段中手动挖掘，但我个人避免这样做，并且尝试为他们提供一些具有有意义的名称和行为的逻辑方法。它使核心更加清晰。