лучшие практики / шаблоны проектирования, кроме перегрузки конструктора java

У меня есть класс с несколькими конструкторами. Каждый из них представляет разные варианты использования.

Тогда простой ответ: превратите каждый вариант использования в отдельный класс.

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

Любой класс или метод должны делать только одно. Итак, как уже было сказано: ответ - остановиться прямо здесь и вместо того, чтобы добавлять больше вещей в один класс: спросите себя, как вы могли бы осмысленно разорвать его на части.

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

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

Но при превышении определенного количества конструкторов (одни говорят 3, другие 5 ... некоторые экстремисты говорят даже 1) их определенно слишком много, и тогда вам следует рассмотреть фабричный шаблон, как предлагается здесь. Это следует обязательно учитывать - независимо от того, сколько у вас конструкторов - когда вы думаете о введении «фиктивных» параметров для решения проблем со стиранием. Преимущество фабричного шаблона в том, что сигнатура фабричного метода определяется не только списком параметров, вы также можете выбрать другое имя (ABC.ofIntList(), ABC.ofStringList() и так далее…).

Это зависит от того, что именно класс делает с параметрами, у нас нет точных деталей, но одна простая вещь, которую вы можете сделать для универсальных типов, - это сделать свой собственный класс универсальным (и, возможно, нет необходимости применять причудливый шаблон проектирования. в этом случае):

public class ABC<T> {
    public ABC(ArrayList<T> stringArray) {
       …
    }
    …
}


ArrayList<Integer> intList = Stream.of(1, 2, 3)
                                   .collect(Collectors.toCollection(ArrayList::new));
ArrayList<String> stringList = Stream.of("a", "b", "c")
                                   .collect(Collectors.toCollection(ArrayList::new));
ABC<Integer> abc1 = new ABC<>(intList);
ABC<String> abc2 = new ABC<>(stringList);

У меня есть сильное предчувствие, что, вероятно, наличие такого количества конструкторов - не лучший шаблон дизайна.

Это зависит.

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

Одной из альтернатив, которую следует рассмотреть, является Static Factory Methods. В последнее время многие авторы предлагают отдавать предпочтение статическим фабричным методам конструкторам.

Есть несколько причин, по которым вы можете захотеть отдать им предпочтение:

Они обеспечивают лучшую, понятную и интуитивно понятную читаемость.

Вы не можете давать имена конструкторам. Имя конструктора всегда совпадает с именем класса; однако вы можете найти полезным использовать именование, так как они обеспечат более четкую читаемость.

Вы можете создавать и возвращать подтипы

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

Если в вашем классе слишком много полей, я бы посоветовал вам плохой дизайн. Некоторые могут посоветовать использовать Шаблон Строителя. Но я думаю, что лучше проявлять больше уважения к ООП, поэтому я думаю, что лучше разбить свой класс на несколько классов и использовать Шаблон декоратора.

Да, наличие большого количества конструкторов может указать на то, что класс нарушает принцип единой ответственности. Согласен - информации недостаточно для принятия решения. Строитель может работать по шаблону или даже по абстрактной фабрике. Однако - рассмотрите возможность использования фабричного метода вместо конструкторов, как посоветовал Дж. Блох:

public ABC of(ArrayList<Integer> integerArray, boolean… sameErasureFlag) {

… }