Керування конструкторами з багатьма параметрами на Java

У деяких наших проектах є ієрархія класів, яка додає більше параметрів, коли йде по ланцюгу. Внизу деякі класи можуть мати до 30 параметрів, 28 з яких просто передаються в суперконструктор.

Я визнаю, що використання автоматичного DI через щось на зразок Guice було б непогано, але через деякі технічні причини ці конкретні проекти обмежуються Java.

Конвенція про упорядкування аргументів в алфавітному порядку за типом не працює, тому що якщо тип буде відновлено заново (Коло, яке ви передавали для аргументу 2, тепер є формою), воно може раптом вийти з ладу.

Це питання може бути конкретним і загрожує критикою "Якщо це ваша проблема, ви робите це неправильно на рівні дизайну", але я просто шукаю будь-які точки зору.

Модель дизайнера Builder може допомогти. Розглянемо наступний приклад

public class StudentBuilder
{
    private String _name;
    private int _age = 14;      // this has a default
    private String _motto = ""; // most students don't have one

    public StudentBuilder() { }

    public Student buildStudent()
    {
        return new Student(_name, _age, _motto);
    }

    public StudentBuilder name(String _name)
    {
        this._name = _name;
        return this;
    }

    public StudentBuilder age(int _age)
    {
        this._age = _age;
        return this;
    }

    public StudentBuilder motto(String _motto)
    {
        this._motto = _motto;
        return this;
    }
}

Це дозволяє нам писати подібний код

Student s1 = new StudentBuilder().name("Eli").buildStudent();
Student s2 = new StudentBuilder()
                 .name("Spicoli")
                 .age(16)
                 .motto("Aloha, Mr Hand")
                 .buildStudent();

Якщо ми залишимо обов'язкове поле (імовірно, ім'я обов'язкове), тоді ми можемо змусити конструктора Student винести виняток. І це дозволяє нам мати аргументи за замовчуванням / за бажанням без необхідності відстежувати будь-який порядок аргументів, оскільки будь-який порядок цих викликів буде працювати однаково добре.

Чи можете ви інкапсулювати пов'язані параметри всередині об'єкта?

наприклад, якщо параметри схожі

MyClass(String house, String street, String town, String postcode, String country, int foo, double bar) {
  super(String house, String street, String town, String postcode, String country);
  this.foo = foo;
  this.bar = bar;

тоді ви можете:

MyClass(Address homeAddress, int foo, double bar) {
  super(homeAddress);
  this.foo = foo;
  this.bar = bar;
}

Можливо, ви хочете зробити клас Builder. Тоді ви зробите щось подібне:

MyObject obj = new MyObjectBuilder().setXxx(myXxx)
                                    .setYyy(myYyy)
                                    .setZzz(myZzz)
                                    // ... etc.
                                    .build();

Див. Сторінку 8 та наступні презентації Josh Bloch (PDF) або цей огляд Ефективної Java

Що ж, використання шаблону будівельника може бути одним із рішень.

Але як тільки ви підійдете до 20 - 30 параметрів, я б припустив, що між параметрами існує висока залежність. Отже, (як це пропонується), вбудовувати їх у логічно здорові об'єкти даних, мабуть, має найбільш сенс. Таким чином об'єкт даних вже може перевірити обґрунтованість обмежень між параметрами.

Для всіх моїх проектів у минулому, коли я прийшов до того, що було занадто багато параметрів (а це було 8, а не 28!), Я зміг переосмислити код, створивши кращу модель моделювання даних.

Оскільки ви обмежені Java 1.4, якщо ви хочете, щоб DI, то весна була б дуже пристойним варіантом. DI корисний лише в місцях, де параметри конструктора - це послуги або щось, що не змінюється під час виконання.

Якщо у вас є всі ці різні конструктори через те, що ви хочете змінних варіантів того, як побудувати об’єкт, вам слід серйозно розглянути можливість використання шаблону Builder.

Найкраще рішення - не мати занадто багато параметрів у конструкторі. Тільки параметри, дійсно потрібні конструктору, - це парами, які потрібно правильно ініціалізувати об'єкт. Ви можете мати конструктори з декількома параметрами, але також мати конструктор лише з мінімальними параметрами. Додаткові конструктори називають цей простий конструктор і після цього сетером встановлюють інші параметри. Таким чином ви зможете уникнути проблеми з ланцюгом все більше і більше парам, а також мати деякі конструктори зручності.

Я дійсно рекомендую використовувати Immutables або POJOBuilder при використанні шаблону будівельника.

Рефакторинг для зменшення кількості параметрів та глибини ієрархії спадкування - це майже все, про що я можу придумати, тому що насправді нічого не допоможе зберегти 20-ти параметри прямо. Вам просто доведеться телефонувати на кожен дзвінок під час перегляду документації.

Одне, що можна зробити, - це згрупувати деякі логічно згруповані параметри у власний об'єкт вищого рівня, але у цього є свої проблеми.