Zarządzanie konstruktorami z wieloma parametrami w Javie

W niektórych naszych projektach istnieje hierarchia klas, która dodaje więcej parametrów w miarę postępu w łańcuchu. Na dole, niektóre klasy mogą mieć do 30 parametrów, z których 28 jest właśnie przekazywanych do super konstruktora.

Przyznam, że używanie automatycznego DI przez coś takiego jak Guice byłoby fajne, ale z pewnych przyczyn technicznych te konkretne projekty są ograniczone do Javy.

Konwencja porządkowania argumentów alfabetycznie według typu nie działa, ponieważ jeśli typ jest refaktoryzowany (koło, które przekazałeś jako argument 2, jest teraz kształtem), może nagle przestać działać.

To pytanie może być zbyt szczegółowe i najeżone krytyką „Jeśli to twój problem, robisz to źle na poziomie projektowania”, ale ja szukam po prostu jakichkolwiek punktów widzenia.

Może pomóc wzorzec projektowy Builder. Rozważmy następujący przykład

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;
    }
}

To pozwala nam pisać kod taki jak

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

Jeśli pominiemy wymagane pole (przypuszczalnie nazwa jest wymagana), możemy poprosić konstruktora Studenta o zgłoszenie wyjątku. I pozwala nam mieć domyślne / opcjonalne argumenty bez konieczności śledzenia jakiejkolwiek kolejności argumentów, ponieważ każda kolejność tych wywołań będzie działać równie dobrze.

Czy możesz hermetyzować powiązane parametry wewnątrz obiektu?

np. jeśli parametry są podobne

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;

zamiast tego możesz mieć:

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

Prawdopodobnie chcesz mieć klasę budowniczego. Następnie zrobiłbyś coś takiego:

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

Zobacz stronę 8 i następne tej prezentacji Josha Blocha (PDF) lub tę recenzję Effective Java

Cóż, użycie wzorca konstruktora może być jednym z rozwiązań.

Ale kiedy dojdziemy do 20 do 30 parametrów, myślę, że istnieje duża zależność między parametrami. Tak więc (jak sugerowano) pakowanie ich w logicznie rozsądne obiekty danych ma prawdopodobnie największy sens. W ten sposób obiekt danych może już sprawdzić ważność ograniczeń między parametrami.

W przypadku wszystkich moich projektów w przeszłości, kiedy doszedłem do punktu, w którym miałem zbyt wiele parametrów (a było to 8, a nie 28!), Byłem w stanie wyczyścić kod, tworząc lepszy model danych.

Ponieważ jesteś ograniczony do języka Java 1.4, jeśli chcesz DI, Spring byłby bardzo przyzwoitą opcją. DI jest pomocne tylko w miejscach, w których parametry konstruktora są usługami lub czymś, co nie zmienia się w czasie wykonywania.

Jeśli masz wszystkie te różne konstruktory ze względu na fakt, że potrzebujesz zmiennych opcji dotyczących konstruowania obiektu, powinieneś poważnie rozważyć użycie wzorca Builder.

Najlepszym rozwiązaniem jest brak zbyt wielu parametrów w konstruktorze. Jedynymi parametrami naprawdę potrzebnymi w konstruktorze są parametry potrzebne do poprawnej inicjalizacji obiektu. Możesz mieć konstruktory z wieloma parametrami, ale także konstruktor z minimalnymi parametrami. Dodatkowe konstruktory wywołują ten prosty konstruktor, a następnie ustawiają inne parametry. W ten sposób możesz uniknąć problemu z łańcuchem z coraz większą liczbą parametrów, ale także mieć kilka wygodnych konstruktorów.

Mogę naprawdę polecić użyciu Immutables lub POJOBuilder przy użyciu wzorca Builder.

Refaktoryzacja w celu zmniejszenia liczby parametrów i głębokości hierarchii dziedziczenia to prawie wszystko, o czym mogę pomyśleć, ponieważ nic tak naprawdę nie pomoże w utrzymaniu równych 20 parametrów. Będziesz musiał po prostu odebrać każdą rozmowę podczas przeglądania dokumentacji.

Jedną rzeczą, którą możesz zrobić, jest zgrupowanie niektórych logicznie pogrupowanych parametrów w ich własny obiekt wyższego poziomu, ale wiąże się to z własnymi problemami.