В каком порядке определяются геттеры и сеттеры? [закрыто]

Есть ли лучшая практика для заказа, чтобы определить геттеры и сеттеры в? Кажется, есть две практики:

• пары геттер / сеттер
• сначала геттеры, потом сеттеры (или наоборот)

Чтобы проиллюстрировать это различие, приведем пример Java-пары для получения / установки:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public int getVar2() {
    return var2;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

И вот пример Java для первых получателей, затем установщиков:

public class Foo {
    private int var1,
    var2,
    var3;

    public int getVar1() {
    return var1;
    }

    public int getVar2() {
    return var2;
    }

    public int getVar3() {
    return var3;
    }

    public void setVar1(int var1) {
    this.var1 = var1;
    }

    public void setVar2(int var2) {
    this.var2 = var2;
    }

    public void setVar3(int var3) {
    this.var3 = var3;
    }
}

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

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

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

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

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

Это также может зависеть от языка. В Java нет никакого реального преимущества для любого порядка, но в C #, например, у вас есть понятие «свойства», которые группируют геттер и сеттер вместе, так что это как бы навязывает этот порядок. В языке, подобном C ++, где вам может потребоваться различная видимость для методов получения и установки (например, частный установщик, открытый метод получения), вы, вероятно, поступите противоположным образом, поскольку модификатор видимости дается один раз для нескольких методов, а не индивидуально для каждого. ,

Насколько я знаю, нет единого соглашения. В разделе Oracle Java Code Conventions по организации файлов явно не упоминается размещение методов получения и установки, но в нем говорится:

Эти методы должны быть сгруппированы по функциональности, а не по объему или доступности.

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

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

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

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

Лучшее решение - просто согласовать файлы в проекте. Найдите стандарт, задокументируйте его и придерживайтесь его.

Сгруппируйте геттер и сеттер для одного поля попарно.

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

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

Всегда Java IDE может генерировать геттеры и сеттеры для вас. Просто используйте эту функциональность и оставьте порядок тех методов, которые были созданы в IDE. Это сгенерированный код, не трогайте его без необходимости.