oop - 为什么二传手在接口(interface)中不好？

Question

如果我们谈论域对象，为什么 setter 在接口(interface)中不好？

澄清:

我有一个存储在数据库中的域对象。它有几个字段，设置成本很高。 IE。

class JurasicPark {

  private long area;

  ...other fields ...

  getters and setters

  ....

  private Collection<Dinosaur> dinosaurs;
  private Collection<ExoticTree> flora;

  public Collection<Dinosaur> getDinosaurus(){
      ...
  }

  public Collection<ExoticTree> getFlora(){
      ...
  }


}

字段 dinosaurs和 flora初始化和设置成本非常高。但在很多情况下，我不需要每次都设置这个字段。

问题是如果我返回 JurasicPark 类的用户实例 dinosaurs或 flora不要初始化它会导致 NPE 或我自己的一些期望。我不想让 api 用户考虑这一点并记住哪些字段可能未设置。

所以为了解决这个问题，我想创建两个接口(interface) IJurasicPark和 IFullJurasicPark第一个将声明对简单字段的所有访问方法，前者将声明对 flora 的访问方法和 dinosaurs字段。

   interface IFullJurasicPark extends IJurasicPark

    class IJurasicPark implements IFullJurasicPark

在这种方法中 IJurasicPark 接口(interface)将包含 getter 和 setter，所以我实际上问这种设计是坏的吗？

我也不想用 LazyInit 异常以休眠方式实现它。

Answer 1

谁告诉你的？一般来说，这肯定不是真的。
在某些情况下可能是正确的，即相关属性(property)不应被外部各方修改。例如。不可变类的接口(interface)肯定不能包含 setter。
确实，在设计接口(interface)时应该仔细考虑，而不是盲目地为类的所有属性自动生成 getter+setter。但这并不意味着二传手总是坏的。
澄清问题后更新
您的澄清完全改变了问题......您可以立即从这个问题开始，从而节省您和其他人的时间。虽然我没有提示 - 我得到了很多(不应该的)赞成票 :-)
所以你的问题是在域对象中初始化/设置昂贵的集合属性。我的第一种方法确实是延迟加载/保存，可以根据上下文以多种不同的方式实现。
您的帖子建议(但没有明确说明)有问题的集合是从数据库中获取/持久化到数据库中的。但是，您没有提到您使用的持久性解决方案。你也没有解释为什么你不想要“休眠风格的惰性初始化”——恕我直言，它在大多数情况下非常有效且易于使用。如果您向我们提供有关这些的更多详细信息，我们也许能够提供更好的答案。
如果没有恐龙和植物群的侏罗纪公园对象合乎逻辑并且可以按原样使用，那么您建议的界面拆分可能是有意义的。同样，如果没有更多的上下文，很难判断这一点。您似乎正在根据实现细节做出设计决策，这通常不是一个好主意。
如果你真的想这样做，你实际上不应该需要单独的接口(interface) - 只需定义一个 JurassicPark (抽象)包含简单成员及其访问器方法的基类，然后用另一个添加重量级字段的类对其进行子类化。