我们应该避免将自定义对象作为参数吗？

假设我有一个自定义对象Student：

public class Student{
    public int _id;
    public String name;
    public int age;
    public float score;
}

还有一个窗口Window，用于显示学生的信息：

public class Window{
    public void showInfo(Student student);
}

它看起来很正常，但是我发现Window很难单独测试，因为它需要一个真正的Student对象来调用该函数。因此，我尝试修改showInfo，使其不直接接受Student对象：

public void showInfo(int _id, String name, int age, float score);

以便更轻松地单独测试Window：

showInfo(123, "abc", 45, 6.7);

但是我发现修改后的版本还有另一个问题：

1. 修改学生（例如：添加新属性）需要修改showInfo的方法签名

2. 如果Student具有许多属性，则Student的方法签名将非常长。

因此，使用自定义对象作为参数或接受对象中的每个属性作为参数，哪个更可维护？

推荐使用自定义对象对相关参数进行分组。作为重构，它称为Introduce Parameter Object。

您的问题出在其他地方。首先，泛型Window对学生一无所知。相反，您应该StudentWindow对仅显示有所了解Students。其次，只要不包含任何会使的测试彻底复杂的复杂逻辑，创建Student实例进行测试就绝对没有问题。如果它确实具有该逻辑，则应首选接口并进行模拟。StudentWindowStudentStudentWindowStudent

你说是

单独测试不太容易，因为它需要一个真正的Student对象来调用该函数

但是您可以只创建一个学生对象以传递到您的窗口：

showInfo(new Student(123,"abc",45,6.7));

调用起来似乎并不复杂。

用外行的话来说：

• 您所谓的“自定义对象”通常简称为对象。
• 在设计任何非平凡的程序或API或使用任何非平凡的API或库时，都无法避免将对象作为参数传递。
• 将对象作为参数传递完全可以。看一下Java API，您将看到许多接口将对象作为参数接收。
• 您使用的库中的类是由像您和我这样的凡人编写的，因此我们编写的类不是“ custom”，而是“ custom”。

编辑：

正如@ Tom.Bowen89指出的那样，测试showInfo方法并不复杂：

showInfo(new Student(8812372,"Peter Parker",16,8.9));

1. 在您的学生示例中，我认为调用Student构造函数来创建要传递给showInfo的学生是微不足道的。因此没有问题。
2. 假设示例Student被故意琐碎地处理了这个问题，并且构造起来比较困难，那么您可以使用double检验。在Martin Fowler的文章中，有许多关于测试双打，模拟，存根等的选项可供选择。
3. 如果要使showInfo函数更通用，则可以遍历公共变量，或者遍历传入的对象的公共访问器，并对所有变量执行show逻辑。然后，您可以传递符合该合同的任何对象，并且它将按预期工作。这将是使用界面的好地方。例如，将Showable或ShowInfoable对象传递给showInfo函数，该函数不仅可以显示学生信息，还可以显示实现该接口的任何对象的信息（显然，这些接口需要更好的名称，具体取决于您希望将对象传递给哪个特定对象或通用对象是，以及学生是其子类）。
4. 通常，传递原语通常更容易，有时对于性能而言是必要的，但是将相似概念组合在一起的次数越多，代码通常就越容易理解。唯一需要提防的事情是尽量不要过度做，最终会引起企业的嗡嗡声。

Code Complete中的Steve McConnell解决了这个问题，讨论了将对象传递给方法而不是使用属性的优缺点。

如果我弄错了一些细节，请原谅我，这是从记忆中开始的工作，因为我已经有超过一年的时间了：

他得出的结论是，最好不要使用对象，而只发送该方法绝对必要的那些属性。该方法除了在操作中将要使用的属性之外，不必对对象有任何了解。同样，随着时间的流逝，如果曾经更改过对象，则可能会对使用该对象的方法产生意想不到的后果。

他还指出，如果最终得到的方法接受很多不同的参数，那么这可能表明该方法做得太多，应该分解为更多，更小的方法。

但是，有时有时确实需要很多参数。他给出的示例将是一种使用许多不同的地址属性来构建完整地址的方法（尽管您可以考虑使用字符串数组来解决此问题）。

如果通过整个对象，则编写和读取测试要容易得多：

public class AStudentView {
    @Test 
    public void displays_failing_grade_warning_when_a_student_with_a_failing_grade_is_shown() {
        StudentView view = aStudentView();
        view.show(aStudent().withAFailingGrade().build());
        Assert.that(view, displaysFailingGradeWarning());
    }

    private Matcher<StudentView> displaysFailingGradeWarning() {
        ...
    }
}

为了比较，

view.show(aStudent().withAFailingGrade().build());

如果您分别传递值，则可以写成一行：

showAStudentWithAFailingGrade(view);

实际的方法调用埋在某个地方

private showAStudentWithAFailingGrade(StudentView view) {
    int someId = .....
    String someName = .....
    int someAge = .....
    // why have been I peeking and poking values I don't care about
    decimal aFailingGrade = .....
    view.show(someId, someName, someAge, aFailingGrade);
}

确切地说，您不能在测试中放入实际的方法调用，这表明您的API不好。

您应该通过一些有意义的想法：

更容易测试。如果需要编辑对象，什么需要最少的重构？将此功能重新用于其他用途是否有用？实现此功能所需的最少信息量是多少？（通过分解它（它可能会让您重新使用此代码），请警惕落入创建此函数的设计漏洞，然后限制所有内容以独占使用此对象。）

所有这些编程规则只是引导您正确思考的指南。只是不要构建代码野兽-如果您不确定并且只需要继续，请在此处选择一个方向/您自己的建议或建议，如果您遇到了一个想法，那就是“哦，我应该做到这一点”方式”-然后，您可能可以轻松地对其进行重构。（例如，如果您有教师班级-它只需要设置与学生相同的属性，并且您可以更改功能以接受“人”表格的任何对象）

我最倾向于保留主要对象的传递-因为我将如何编码它，这将更容易地解释此函数的作用。

解决此问题的一种常见方法是在两个进程之间插入一个接口。

public class Student {

    public int id;
    public String name;
    public int age;
    public float score;
}

interface HasInfo {
    public String getInfo();
}

public class StudentInfo implements HasInfo {
    final Student student;

    public StudentInfo(Student student) {
        this.student = student;
    }

    @Override
    public String getInfo() {
        return student.name;
    }

}

public class Window {

    public void showInfo(HasInfo info) {

    }
}

有时这会有些混乱，但是如果您使用内部类，那么Java会变得有些混乱。

interface HasInfo {
    public String getInfo();
}

public class Student {

    public int id;
    public String name;
    public int age;
    public float score;

    public HasInfo getInfo() {
        return new HasInfo () {
            @Override
            public String getInfo() {
                return name;
            }

        };
    }
}

然后，您可以Window通过给它一个假HasInfo对象来测试该类。

我怀疑这是Decorator模式的示例。

添加

代码的简单性似乎引起了一些混乱。这是另一个可以更好地演示该技术的示例。

interface Drawable {

    public void Draw(Pane pane);
}

/**
 * Student knows nothing about Window or Drawable.
 */
public class Student {

    public int id;
    public String name;
    public int age;
    public float score;
}

/**
 * DrawsStudents knows about both Students and Drawable (but not Window)
 */
public class DrawsStudents implements Drawable {

    private final Student subject;

    public DrawsStudents(Student subject) {
        this.subject = subject;
    }

    @Override
    public void Draw(Pane pane) {
        // Draw a Student on a Pane
    }

}

/**
 * Window only knows about Drawables.
 */
public class Window {

    public void showInfo(Drawable info) {

    }
}

您已经有很多不错的答案，但是这里有一些其他建议可以使您看到替代解决方案：

• 您的示例显示了将Student（显然是模型对象）传递给Window（显然是视图级对象）的情况。如果您还没有中间Controller或Presenter对象，则可以从中将用户界面与模型隔离开来。控制器/演示者应提供一个可用于代替它进行UI测试的接口，并应使用该接口引用模型对象和视图对象，以便能够将其与两个对象隔离以进行测试。您可能需要提供一些抽象的方式来创建或加载这些方式（例如Factory对象，Repository对象或类似对象）。

• 当模型变得过于复杂时，将模型对象的相关部分转移到数据传输对象中是一种有用的接口方法。

• 您的学生可能违反了接口隔离原则。如果是这样，将其拆分为更易于使用的多个接口可能是有益的。

• 延迟加载可以使大型对象图的构建更加容易。

这实际上是一个体面的问题。这里真正的问题是使用通用术语“对象”，这可能有点含糊。

通常，在经典的OOP语言中，术语“对象”已表示“类实例”。类实例可能非常繁重-公共和私有属性（以及介于它们之间的属性），方法，继承，依赖关系等。您实际上并不想使用类似的东西来简单地传递一些属性。

在这种情况下，您正在使用一个对象作为仅包含一些基元的容器。在C ++中，诸如此类的对象被称为structs（它们仍然以C＃等语言存在）。实际上，结构是专为您所说的用途而设计的-当它们具有逻辑关系时，它们会将相关的对象和基元分组在一起。

但是，在现代语言中，编写代码时，结构和类之间实际上没有任何区别，因此可以使用对象。（但是，在幕后，您应该意识到一些差异，例如，结构是值类型，而不是引用类型。）基本上，只要您保持对象简单，就很容易手动测试。不过，现代语言和工具可以使您减轻很多（通过接口，模拟框架，依赖项注入等）。