Подтвердить что ты не робот

Соглашения Setter в Java (return void или this)

Я пишу Java уже почти год, и я видел 2 разных соглашения о том, как люди реализуют свои сеттеры.

Чтобы проиллюстрировать это, приведены примеры обеих конвенций. (Я хотел бы также знать краткие имена этих двух паттеров)

Классы, используя первое соглашение, ничего не возвращают из своих методов 'set'. Например:

public class Classic{
    private double _x;
    private double _y;
    public Classic(){
        x = 0;
        y = 0;
    }
    public void setX(double d){//or boolean with a type check on input
        x = d;
    }
    public void sety(double d){
        y = d;
    }
}

Классы, использующие альтернативное соглашение, возвращаются из своих методов настройки. Например:

public class Alternative{
    private double _x;
    private double _y;
    public Alternative(){
        x = 0;
        y = 0;
    }
    public Alternative setX(double d){
        x = d;
        return(this);
    }
    public Alternative sety(double d){
        y = d;
        return(this);
    }
}

Разница заключается в том, что с синтаксисом альтернативного подхода, например

Alternative NewAlt(double x,double y){
     return(new Alternative()
                .setX(x)
                .setY(y));
}

Возможно, в то время как с классической настройкой такой же метод factory выглядят так.

Classic NewAlt(double x,double y){
     Classic temp = new Classic();
     temp.setX(x);
     temp.setY(x);
     return(temp);
}

Это спорно, какой из них является более удобным для чтения/годным к употреблению.

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

Если нет разницы в производительности, какая из них считается лучшей практикой?

4b9b3361

Ответ 1

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

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

Ответ 2

Вариант, который вы используете в классе Alternative, является тем, что я знаю из "шаблона Builder". Там задача состоит в том, чтобы создать определенный объект, похожий на builder.setX().setY().build().

Лично я использую вариант Classic, если для варианта Alternative нет специального использования.

(Как примечание, я бы не использовал скобки для return)

Ответ 3

Установщик в Java чаще всего связан с понятием JavaBeans, хотя мы теперь используем эту концепцию, не называя ее так, но ее часто используют, не будучи явно названной так, иногда люди называют их сущностями (даже без контекст ORM).

В JavaBean есть свойства, а те свойства - комбинация частного поля и (сеттер и/или получатель).

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

Если вы посмотрите, что делает какая-либо IDE, реализация по умолчанию для сеттера - это void.

В этом отношении я бы всегда шел по объектам void -way для значений (они называются JavaBeans, Entity, Dto и т.д.) и никогда не используют цепочку. Вы спрашиваете о лучшей практике, void -way - лучшая практика для объектов ценности.

Для инструментов, таких как сборщики, dsl, services, streams, я могу использовать цепочку только в том случае, если она действительно имеет смысл и добавляет что-то и не слишком громоздка.

Мой короткий совет - использовать void для объектов значений и делать то, что вы хотите для остальных. Получайте удовольствие от разработки своих классов.;)