Должны ли мы избегать пользовательских объектов в качестве параметров?

Предположим, у меня есть пользовательский объект, студент :

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 был бы очень длинным.

Итак, если использовать пользовательские объекты в качестве параметра или принять каждое свойство в объектах в качестве параметра, какое из них более приемлемо?

Использование настраиваемого объекта для группировки связанных параметров на самом деле является рекомендуемым шаблоном. В качестве рефакторинга он называется « Ввести объект параметров» .

Ваша проблема лежит в другом месте. Во-первых, универсальный Windowничего не должен знать о студенте. Вместо этого вы должны иметь какой-то вид, StudentWindowкоторый знает только об отображении Students. Во-вторых, нет абсолютно никаких проблем с созданием Studentэкземпляра для тестирования, StudentWindowесли только Studentон не содержит сложной логики, которая может значительно усложнить тестирование StudentWindow. Если у него есть Studentтакая логика, то создание интерфейса и насмешка должны быть предпочтительными.

Вы говорите, что это

не так-то просто проверить индивидуально, потому что для вызова функции нужен настоящий объект Student

Но вы можете просто создать объект ученика для передачи в ваше окно:

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

Это не кажется более сложным, чтобы позвонить.

С точки зрения непрофессионала:

• То, что вы называете «пользовательским объектом» , обычно просто называется объектом.
• Вы не можете избежать передачи объектов в качестве параметров при разработке любой нетривиальной программы или API или использовании любого нетривиального API или библиотеки.
• Это нормально, чтобы передавать объекты в качестве параметров. Взгляните на Java API, и вы увидите множество интерфейсов, которые получают объекты в качестве параметров.
• Классы в библиотеках, которые вы используете, написаны простыми смертными, такими как вы и я, так что те, которые мы пишем, не "обычай" , а просто так.

Редактировать:

Как утверждает @ Tom.Bowen89, протестировать метод showInfo не намного сложнее:

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

1. В вашем примере со студентом я предполагаю, что тривиально вызвать конструктор Student, чтобы создать студента для передачи в showInfo. Так что проблем нет.
2. Если предположить, что пример Student намеренно упрощен для этого вопроса, и его сложнее построить, тогда вы можете использовать двойной тест . Есть несколько вариантов тестовых двойников, макетов, заглушек и т. Д., О которых говорится в статье Мартина Фаулера.
3. Если вы хотите сделать функцию showInfo более общей, вы можете сделать так, чтобы она перебирала открытые переменные или, возможно, передавала открытые методы доступа к объекту и выполняла логику показа для всех них. Затем вы можете передать любой объект, который соответствует этому контракту, и он будет работать, как ожидалось. Это было бы хорошим местом для использования интерфейса. Например, передайте объект Showable или ShowInfoable в функцию showInfo, которая может отображать не только информацию об учениках, но и информацию о любом объекте, который реализует интерфейс (очевидно, эти интерфейсы нуждаются в лучших именах в зависимости от того, насколько конкретным или универсальным вы хотите передать объект, в который вы можете передать быть и что ученик подкласс).
4. Часто проще обойти примитивы, а иногда это необходимо для производительности, но чем больше вы можете группировать сходные концепции, тем более понятным будет ваш код. Единственное, на что нужно обратить внимание, это попытаться не переусердствовать и в конечном итоге получить корпоративный fizzbuzz .

Стив Макконнелл из Code Complete рассмотрел эту проблему, обсудив преимущества и недостатки передачи объектов в методы вместо использования свойств.

Простите, если я ошибаюсь в некоторых деталях, я работаю по памяти, так как прошло больше года с тех пор, как у меня был доступ к книге:

Он приходит к выводу, что лучше не использовать объект, а отправлять только те свойства, которые абсолютно необходимы для метода. Метод не должен знать ничего об объекте за пределами свойств, которые он будет использовать как часть своих операций. Кроме того, со временем, если объект когда-либо изменяется, это может иметь непредвиденные последствия для метода, использующего объект.

Также он обратился к тому, что если в итоге вы получите метод, который принимает множество различных аргументов, то это, вероятно, признак того, что метод делает слишком много и должен быть разбит на более мелкие методы.

Однако иногда, иногда вам действительно нужно много параметров. В качестве примера он привел бы метод, который строит полный адрес, используя множество различных свойств адреса (хотя это можно обойти, используя строковый массив, когда вы об этом думаете).

Тесты гораздо проще писать и читать, если вы пройдете весь объект:

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 плох.

Вы должны передать то, что имеет смысл, некоторые идеи:

Проще проверить. Если объект (ы) необходимо отредактировать, что требует наименьшего рефакторинга? Полезно ли повторно использовать эту функцию для других целей? Какое наименьшее количество информации мне нужно, чтобы эта функция выполнялась? (Разбивая его - он может позволить вам повторно использовать этот код - будьте осторожны, чтобы не упасть в конструктивную дыру создания этой функции, а затем ограничить все возможности исключительно для использования этого объекта.)

Все эти правила программирования - всего лишь руководство, которое поможет вам мыслить в правильном направлении. Просто не создавайте зверя с кодом - если вы не уверены и вам просто нужно продолжить, выберите направление / ваше собственное или предложение здесь, и если вы достигли точки, когда вы думаете: «О, я должен был сделать это так» путь »- тогда вы, вероятно, сможете вернуться и довольно легко изменить его. (Например, если у вас есть класс Teacher - ему просто нужно установить то же свойство, что и для Student, и вы измените свою функцию для принятия любого объекта формы Person)

Я был бы наиболее склонен к тому, чтобы основной объект передавался - потому что, как я кодирую, легче объяснить, что делает эта функция.

Один из распространенных способов обойти это - вставить интерфейс между двумя процессами.

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объект.

Я подозреваю, что это пример шаблона декоратора .

добавленной

Кажется, есть некоторая путаница, вызванная простотой кода. Вот еще один пример, который может продемонстрировать технику лучше.

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 может быть полезен, если у вас его еще нет, что позволяет вам изолировать ваш пользовательский интерфейс от вашей модели. Контроллер / презентатор должен предоставлять интерфейс, который можно использовать для его замены для тестирования пользовательского интерфейса, и должен использовать интерфейсы для обращения к объектам модели и просмотра объектов, чтобы иметь возможность изолировать его от обоих для тестирования. Вам может понадобиться какой-то абстрактный способ их создания или загрузки (например, объекты Factory, объекты Repository или аналогичные).

• Перенос соответствующих частей ваших объектов модели в объект передачи данных является полезным подходом для взаимодействия, когда ваша модель становится слишком сложной.

• Может случиться так, что ваш ученик нарушает принцип разделения интерфейса. Если это так, может быть полезно разделить его на несколько интерфейсов, с которыми проще работать.

• Ленивая загрузка может упростить построение больших графов объектов.

Это на самом деле достойный вопрос. Настоящая проблема здесь заключается в использовании общего термина «объект», который может быть немного двусмысленным.

Как правило, в классическом языке ООП термин «объект» стал означать «экземпляр класса». Экземпляры классов могут быть довольно тяжелыми - общедоступные и частные свойства (и промежуточные), методы, наследование, зависимости и т. Д. На самом деле вы не захотите использовать что-то подобное для простой передачи некоторых свойств.

В этом случае вы используете объект в качестве контейнера, который просто содержит некоторые примитивы. В C ++ такие объекты были известны как structs(и они все еще существуют в таких языках, как C #). Структуры, на самом деле, были разработаны именно для использования, о котором вы говорите - они группировали связанные объекты и примитивы вместе, когда у них были логические отношения.

Однако в современных языках нет никакой разницы между структурой и классом, когда вы пишете код , так что вы можете использовать объект. (Однако за кулисами есть некоторые отличия, о которых вы должны знать - например, структура - это тип значения, а не ссылочный тип.) В основном, если вы сохраняете свой объект простым, это будет легко проверить вручную. Современные языки и инструменты позволяют вам немного смягчить это (через интерфейсы, макеты, внедрение зависимостей и т. Д.)