设计问题：传递你使用的字段还是传递对象？

Question

我经常看到方法接口的两种相互冲突的策略，大致总结如下：

// Form 1: Pass in an object.
double calculateTaxesOwed(TaxForm f) { ... }

// Form 2: Pass in the fields you'll use.
double calculateTaxesOwed(double taxRate, double income) { ... }

// use of form 1:
TaxForm f = ...
double payment = calculateTaxesOwed(f);

// use of form 2:
TaxForm f = ...
double payment = calculateTaxesOwed(f.getTaxRate(), f.getIncome());

我见过第二种形式的拥护者，特别是在动态语言中，在动态语言中评估正在使用哪些字段可能更困难。

但是，我更喜欢第一种形式：它更短，出错的空间更小，并且如果对象的定义稍后发生更改，您不一定需要更新方法签名，也许只需更改在对象内部使用对象的方式即可。方法。

这两种形式是否都有令人信服的一般情况？ 是否有明确的示例说明何时应该使用第二种形式而不是第一种形式？ 我是否可以指出 SOLID 或其他 OOP 原则来证明我使用一种形式而不是另一种形式的决定是合理的？ 如果您使用动态语言，上述答案是否会改变？

Answer 1

老实说，这取决于所讨论的方法。

如果该方法在没有对象的情况下也有意义，那么第二种形式更容易重用，并且消除了两个类之间的耦合。

如果该方法依赖于该对象，那么传递该对象就足够了。

对于第三种形式可能有一个很好的论据，您可以传递一个旨在与该方法一起使用的接口。 为您提供第一种形式的清晰度和第二种形式的灵活性。

Answer 2

这取决于你的方法的意图。

如果该方法被设计为专门针对该对象并且仅针对该对象，则传递该对象。 它形成了一个很好的封装。

但是，如果该方法更通用，您可能需要单独传递参数。 这样，当信息来自另一个来源（即不同类型的对象或其他派生数据）时，该方法更有可能被重用。

Answer 3

我强烈推荐第二种解决方案 - calculateTaxesOwed() 计算一些数据，因此需要一些数字输入。 该方法与用户界面绝对无关，因此不应使用表单作为输入，因为您希望业务逻辑与用户界面分离。

执行计算的方法（通常）甚至不应该与用户界面属于同一模块。 在这种情况下，您会得到循环依赖，因为用户界面需要业务逻辑，而业务逻辑需要用户界面形式 - 强烈表明出现了问题（但仍然可以使用基于接口的编程来解决）。

更新

如果纳税表单不是用户界面表单，情况会发生一些变化。 在这种情况下，我建议使用 TaxForm 类的实例方法 GetOwedTaxes() 或实例属性 OwedTaxes 公开该值，但我不会使用静态方法。 如果计算可以在其他地方重用，则仍然可以创建一个使用值而不是表单的静态辅助方法，并从实例方法或属性中调用此辅助方法。

Answer 4

我认为这并不重要。 如果您传入对象，您就会面临副作用，因为它可能会发生突变。 然而，这可能正是您想要的。 为了减轻这种情况（并帮助测试），您可能最好传递接口而不是具体类型。 这样做的好处是，如果您想访问对象的另一个字段，则无需更改方法签名。

传递所有参数可以更清楚地了解类型需要什么，并且可能使其更容易测试（尽管如果您使用接口，这没有什么好处）。 但你将会有更多的重构。

根据每种情况的优点来判断，并选择最不痛苦的。

Answer 5

仅传递参数可以更容易进行单元测试，因为您不需要仅仅为了测试本质上只是静态计算的功能而模拟充满数据的整个对象。 如果对象的许多字段中只使用了两个字段，那么在其他条件相同的情况下，我倾向于只传递这些字段。

也就是说，当您最终有六个、七个或更多字段时，是时候考虑在“有效负载”类（或结构/字典，具体取决于语言风格）。 长方法签名通常会令人困惑。

另一种选择是使其成为类方法，这样您就不必传递任何内容。 测试不太方便，但当您的方法仅用于 TaxForm 对象的数据时值得考虑。

Answer 6

我意识到这很大程度上是所使用示例的产物，因此它可能不适用于许多现实情况，但是，如果该函数与特定类紧密相关，那么它不应该是：

double payment = f.calculateTaxesOwed;

它似乎更合适对我来说，税务文件本身将承担计算相关税收的责任，而不是将该责任归于效用函数，特别是考虑到不同的税收形式往往使用不同的税表或计算方法。

Answer 7

第一种形式的一个优点是

1. 抽象——对接口而不是实现进行编程。 从长远来看，它使代码的维护更加容易，因为只要 TaxForm 的接口不改变，您就可以更改 TaxForm 的实现而不会影响客户端代码。

Answer 8

这与 Martin Fowler 的重构书中的“引入参数对象”相同。 Fowler 建议，如果有一组参数倾向于一起传递，则执行此重构。

Answer 9

如果您相信德墨忒尔法则，那么您会赞成准确传递所需内容：

http://en .wikipedia.org/wiki/Law_of_Demeter

http://www.c2.com/ cgi/wiki?LawOfDemeter

Answer 10

将要操作的 UI 和数据分离

在您的情况下，您缺少一个中间类，例如 TaxInfo，代表要征税的实体。 原因是UI（表单）和业务逻辑（如何计算税率）处于两个不同的“变化轨道”，一个是随着呈现技术（“web”、“Web 2.0”、“WPF”、. ..)，其他用法律术语进行更改。 在它们之间定义清晰的接口。

---

一般讨论，使用示例：

考虑一个为名片创建位图的函数。 该函数的目的是

(1) // 根据名字和姓氏格式化名片标题

或

(2) // 根据 Person< 格式化名片标题/code> record

第一个选项更通用，耦合性较弱，通常更可取。 然而，在许多情况下，对变更请求的鲁棒性较差 - 例如考虑“2017 年案例：将人员姓名首字母添加到名片”。

更改实现（添加 person.Initial）通常比更改接口更容易、更快。

最终的选择取决于您期望的更改类型：是否更有可能需要来自Person记录的更多信息，或者您是否更有可能希望为其他数据结构创建名片标题？ 人？

如果这是“未决定”，那么您不能出于目的（1）或（2）进行操作，为了语法的简洁性，我宁愿选择（2）。

Answer 11

如果我被迫选择两者之一，我总是会选择第二个 - 如果您发现您（无论出于何种原因）需要计算所欠税款，但您没有 TaxForm 的实例，该怎么办？

这是一个相当简单的示例，但是我见过一些情况，其中执行相对简单任务的方法具有难以创建的复杂输入，使得该方法比应有的更难使用。 （作者根本没有考虑到其他人可能想要使用该方法！）

就我个人而言，为了使代码更具可读性，我可能会两者兼而有之：

double calculateTaxesOwed(TaxForm f) 
{
    return calculateTaxesOwed(f.getTaxRate(), f.getIncome());
}

double calculateTaxesOwed(double taxRate, double income) { ... }

我的经验法则是尽可能有一个完全接受输入的方法它需要 - 编写包装方法非常容易。

Answer 12

就我个人而言，我会选择#2，因为它更清楚该方法需要什么。 通过 TaxForm（如果它是我所认为的那样，就像 Windows 窗体一样）有点臭，让我有点畏缩 (>_<)。

仅当您传递特定于计算的 DTO 时，我才会使用第一个变体，例如 IncomeTaxCalculationInfo 对象，它将包含 TaxRate 和 Income 以及计算方法中的最终结果所需的任何其他内容，但绝不会像 Windows / Web 之类的东西形式。