在考虑业务需求变化的情况下，POJOs/models 或领域驱动对象的本质究竟是什么？

Question

有人告诉我这段代码是一个非常讨厌的反模式。

  @SuppressWarnings("unchecked")
  private static Map<String, Object> getArgs(Object obj) {
    return new HashMap<>((Map<String, Object>) obj);
  }

  public void buildAndUpdateCustomer(List<Object> list) {
    for (Object obj : list) {
      Map<String, Object> args = getArgs(obj);
      daoProvider.updateCustomerName(args);
      daoProvider.updateAgingMia(args);
    }
  }

  public void buildAndUpdateTax(List<Object> list) {
    for (Object obj : list) {
      Map<String, Object> args = getArgs(obj);
      daoProvider.updateTaxAmount(args);
    }
  }

  public void buildAndUpdateLedgerBal(List<Object> list) {
    for (Object obj : list) {
      Map<String, Object> args = getArgs(obj);
      daoProvider.updateLedgerBalance(args);
    }
  }

对此的争论是因为：

它删除了编译器提供的所有类型安全，甚至删除名称检查。
包含不必要的转换(Map<String,Object>) obj
很难通过签名理解方法的作用，因为方法参数是Object类型。 List<Object> list

我的 List<Object> list 可以是发票税额列表、客户列表、分类帐余额列表等等...可以像这样重写。

public void buildAndUpdateCustomer(List<Customer> list) {...}
public void buildAndUpdateTax(List<Tax> list) {..}
public void buildAndUpdateLedgerBal(List<Ledger> list) {..}

这意味着必须为每个方法创建 Customer、Tax 和 Ledger POJO/entity/domain 对象。我有超过 100 个 buildAndUpdate() 这类方法更新和做不同的事情，我必须创建 100 个 POJO/entity/domain 对象吗？也许这是不好的做法，但我觉得必须在各处添加类会使整个代码库膨胀并破坏可维护性。

Answer 1

你基本上会问为什么不使用 Map<String, Object> 而不是域对象。

我无法想象有多少东西比 Map<String, Object> 的可维护性更差。 Heara 只是几个原因：

作为开发人员，您将不知道哪些字段是允许的或强制的，以及它们有哪些类型 - 除非您深入研究源代码。
至于挖源码，因为只是Map<String, Object>，很难知道这个pseudo-class到底用在什么地方。与普通 class 的 "find references" 不同。
您的域对象可能具有其他实用方法，例如提供更轻松的数据访问。
您无法在 Map<String, Object> 中执行规则。基本上，您可以创建一个从业务逻辑角度来看无效的实例。
重构。假设您需要重命名一个字段。祝您找到所有可以访问该字段的地方。

所以，是的，我肯定会创建 100 个域对象。

在考虑业务需求变化的情况下，POJOs/models 或领域驱动对象的本质究竟是什么？

What really is the essence of POJOs/models or domain-driven objects in the situation in context considering business requirements changes?

java

generics

model

arraylist

pojo