在类之间传递参数 - 使用公共属性或将属性类作为参数传递？

Question

所以假设我有一个名为 ABC 的类，它有一个 Point 对象列表。

我需要用它们做一些绘图逻辑。这些 Point 对象中的每一个都有一个 Draw() 方法，该方法将由 ABC 类调用。

Draw() 方法代码需要来自 ABC 类的信息。

我只能看到两种让他们拥有此信息的方法：

1. 让 Abc 类公开一些允许 draw() 做出决定的属性。
2. 让 Abc 类传递给 draw() 一个充满属性的类。

两种情况下的属性是相同的，我的问题是在这种情况下首选什么。也许第二种方法更灵活？也许不吧？我在这里没有看到明显的赢家，但这肯定与我缺乏经验有关。

如果还有其他好的方法，请随时分享。

以下是两种情况：

class Abc1 {
    public property a;
    public property b;
    public property c;
    ...
    public property z;

    public void method1();
    ...
    public void methodn();
}

这是方法2：

class Abc2 {
    //here we make take down all properties

    public void method1();
    ...
    public void methodn();
}

class Abc2MethodArgs {
    //and we put them here. this class will be passed as argument to
    //Point's draw() method!
    public property a;
    public property b;
    public property c;
    ...
    public property z;
}

此外，如果这两种方法有任何“正式”名称，我想知道它们，以便我可以更好地选择标签/线程名称，因此它对于搜索目的更有用。或者随意编辑它们。

Answer 1

最佳方法取决于 ABC 需要向 Point 实例提供的信息的性质、这些类之间关系的性质以及它们的“预期”未来。换句话说，有很多定性因素。

如果您确实将 Point 传递给 ABC 实例，不要 - 相反，为 Point 从 ABC 需要的任何东西制定一个适当的抽象，并将其封装在一个接口中。在静态方面，这类似于简单地创建一个新类来封装信息，但在动态方面则完全不同。

您不应该简单地传递 ABC 实例的原因是它会创建循环依赖项。无需过多介绍，这通常应被视为非常糟糕的事情，除非绝对必要，否则应避免。

而且，在更抽象的层面上，如果您确定这种明显的循环依赖的原因并将其排除在外 - 即创建一个接口来表示此“点的数据源”，它将更有意义并在以后启用逻辑更改ABC 必须履行的职责。此角色与“积分容器”角色不同，应该反映在您的设计中。

您也可以将参数传递给 draw() 方法 - 这可能是好是坏，取决于一堆因素。只要您考虑过其中的含义，这当然不是一件非常糟糕的事情。

Answer 2

创建和维护一个单独的类来在ABC 和point 之间传递状态会做更多的工作，但是如果你想将point 与ABC 解耦，这样做是值得的。

主要问题是，将它们脱钩对您来说有多重要？如果点实例了解 abc 实例在您的域中有意义，则可能不值得创建参数类，您应该选择选项 1。

Answer 3

使用方法#2，但没有对象。直接把参数传给Draw就行了。

Answer 4

既然Point 类和ABC 似乎必须在它们之间就绘制什么进行调解，为什么不在Point 上调用draw() 方法，将实际的ABC 对象作为参数传递. ABC 对象可以提供访问器方法（不要公开这些属性！），并且点类（或子类实现）可以决定在 ABC 上回调什么。

Answer 5

您可能需要考虑反转依赖关系。不是点访问来自 ABC 的属性，而是让 ABC 在每个点上调用“draw()”时（或之前）在点上设置属性。类似于在 Swing 的 JTable 中渲染单元格时使用的 Flyweight pattern（请参阅 javadoc）。您还可以考虑将Point（数据模型）与PointDrawer（可重用的渲染代码）解耦。这样，您的 Points 将不依赖于所有这些属性，只有您的 PointDrawers 会。

是的，即使您在绘图时将所有参数显式传递给每个 Point，这也是 OO 编程 - 这样，Points 完全不依赖于 ABC 或 ABC 可能的“参数传递类”。