Использование публичного финала, а не частных получателей

Я вижу большинство неизменных POJO, написанных так:

public class MyObject {
    private final String foo;
    private final int bar;

    public MyObject(String foo, int bar) {
        this.foo = foo;
        this.bar = bar;
    }

    public String getFoo() {
        return foo;
    }

    public int getBar() {
        return bar;
    }
}

Тем не менее, я склонен писать их так:

public class MyObject {
    public final String foo;
    public final int bar;

    public MyObject(String foo, int bar) {
        this.foo = foo;
        this.bar = bar;
    }
}

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

Единственный недостаток, который я вижу, - если вы хотите изменить реализацию getFoo()в будущем, чтобы сделать что-то сумасшедшее, вы не можете. Но на самом деле этого никогда не происходит, потому что Объект неизменен; Вы можете проверить во время создания экземпляра, создать неизменные защитные копии во время создания экземпляра (см., ImmutableListнапример, Guava ) и получить объекты fooили, barготовые к getвызову.

Есть ли недостатки, которые я пропускаю?

РЕДАКТИРОВАТЬ

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

Четыре недостатка, о которых я могу подумать:

1. Если вы хотите иметь доступную только для чтения и изменяющуюся форму одной и той же сущности, общий шаблон - иметь неизменяемый класс Entity, который предоставляет только методы доступа с защищенными переменными-членами, а затем создает MutableEntity, который расширяет его и добавляет сеттеры. Ваша версия предотвращает это.
2. Использование методов получения и установки придерживается соглашения JavaBeans. Если вы хотите использовать свой класс в качестве bean-компонента в технологиях, основанных на свойствах, таких как JSTL или EL, вам необходимо предоставить открытые методы получения.
3. Если вы когда-нибудь захотите изменить реализацию для получения значений или поиска их в базе данных, вам придется реорганизовать клиентский код. Подход аксессора / мутатора позволяет вам только изменить реализацию.
4. Наименьшее удивление - когда я вижу общедоступные переменные экземпляра, я сразу же ищу, кто может изменить его, и беспокоюсь, что я открываю ящик Пандоры, потому что инкапсуляция потеряна. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

Тем не менее, ваша версия определенно более краткая. Если бы это был специализированный класс, который используется только в определенном пакете (может быть, здесь полезна область действия пакета), то я мог бы рассмотреть это для разовых предложений. Но я бы не стал раскрывать такие основные API.

Избавьтесь от добытчиков / сеттеров тоже, и вы в порядке!

Это очень спорная тема среди Java-программистов.

В любом случае, есть две ситуации, где я использую публичные переменные вместо (!) Методов получения / установки:

1. Публичный финал Для меня это сигнал «я неизменный» гораздо лучше, чем просто добытчик. Большинство IDE будут указывать окончательный модификатор с буквой «F» во время автозаполнения. В отличие от геттеров / сеттеров, где вы должны искать отсутствие setXXX.
2. Публичный не финал, я люблю это для классов данных. Я просто выставляю все поля публично. Нет добытчиков, сеттеров, конструкторов. Нет, ничего. Меньше, чем Пойо. Для меня это сразу же сигнализирует: «Послушай, я тупой. Я держу данные, вот и все. Твоя работа - поместить в меня нужные данные». Gson / JAXB / и т.д.. справиться с этими классами просто отлично. Они блаженство, чтобы написать. Там нет сомнений относительно их цели или возможностей. И самое главное: вы знаете, что нет никаких побочных эффектов при изменении переменной. ИМХО, это приводит к очень кратким моделям данных с небольшим количеством неоднозначностей, тогда как геттеры и сеттеры сталкиваются с этой огромной проблемой, когда внутри них иногда происходит волшебство.

По словам непрофессионала:

• Вы нарушаете инкапсуляцию , чтобы сохранить несколько строк кода. Это побеждает цель ООД.
• Код клиента будет жестко связан с именами ваших учеников. Сцепление это плохо. Вся цель OOD - предотвращение связи.
• Вы также уверены, что ваш класс никогда не будет изменчивым. Вещи меняются. Изменение - единственное, что постоянно.

Один возможный недостаток, который я могу видеть, заключается в том, что вы привязаны к внутреннему представлению данных в классе. Это, вероятно, не так уж и сложно, но если вы используете сеттеры и решаете, что foo и bar будут возвращены из какого-то другого класса, определенного где-то еще, то для классов, потребляющих MyObject, не потребуется изменять. Вам нужно будет только коснуться MyObject. Тем не менее, если вы используете открытые значения, то вам придется касаться везде, где я использовал MyObject.