Używanie publicznego finału zamiast prywatnych pobierających

Widzę najbardziej niezmienne POJO napisane w ten sposób:

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

Mimo to mam tendencję do pisania ich w ten sposób:

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

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

Zauważ, że odniesienia są ostateczne, więc Obiekt jest nadal niezmienny. Pozwala mi pisać mniej kodu i umożliwia krótszy (o 5 znaków: dostęp geti ()).

Jedyną wadą, jaką widzę, jest to, że jeśli chcesz zmienić implementację w getFoo()dół drogi, aby zrobić coś szalonego, nie możesz. Ale realistycznie to się nie zdarza, ponieważ Obiekt jest niezmienny; możesz zweryfikować podczas tworzenia instancji, tworzyć niezmienne kopie obronne podczas tworzenia instancji (patrz ImmutableListna przykład Guava ) i przygotować obiekty foolub barobiekty na getwezwanie.

Czy brakuje mi wad?

EDYTOWAĆ

Przypuszczam, że kolejną wadą, której mi brakuje, są biblioteki serializacji wykorzystujące refleksję nad metodami zaczynającymi się od getlub is, ale to dość okropna praktyka ...

Cztery wady, o których mogę myśleć:

1. Jeśli chcesz mieć tę samą jednostkę tylko do odczytu i można ją modyfikować, wspólnym wzorcem jest posiadanie niezmiennej klasy encji, która udostępnia tylko akcesory z chronionymi zmiennymi składowymi, a następnie utwórz MutableEntity, który ją rozszerza i dodaje ustawiające. Twoja wersja temu zapobiega.
2. Korzystanie z metod pobierających i ustawiających jest zgodne z konwencją JavaBeans. Jeśli chcesz wykorzystać swoją klasę jako fasolę w technologiach opartych na właściwościach, takich jak JSTL lub EL, musisz ujawnić publiczne programy pobierające.
3. Jeśli kiedykolwiek chcesz zmienić implementację, aby uzyskać wartości lub sprawdzić je w bazie danych, musisz ponownie kodować kod klienta. Podejście typu akcesor / mutator umożliwia jedynie zmianę implementacji.
4. Najmniej zdumienie - kiedy widzę zmienne instancji publicznej, od razu szukam, kto może je mutować i martwię się, że otwieram pudełko pandory, ponieważ utracono enkapsulację. http://en.wikipedia.org/wiki/Principle_of_least_astonishment

To powiedziawszy, twoja wersja jest zdecydowanie bardziej zwięzła. Gdyby to była klasa specjalistyczna, która jest używana tylko w ramach określonego pakietu (być może zakres pakietu jest tutaj dobrym pomysłem), to mogę rozważyć to jednorazowo. Ale nie ujawniłbym takich głównych API.

Pozbądź się również pobierających / ustawiających i wszystko w porządku!

Jest to bardzo kontrowersyjny temat wśród programistów Java.

W każdym razie istnieją dwie sytuacje, w których używam zmiennych publicznych zamiast (!) Getters / setters:

1. publiczny finał To dla mnie oznacza, że ​​„jestem niezmienny” o wiele lepiej niż po prostu getter. Większość IDE wskaże ostateczny modyfikator z literą „F” podczas automatycznego uzupełniania. W przeciwieństwie do getters / setters, w których musisz szukać nieobecności setXXX.
2. public non-final Uwielbiam to dla klas danych. Po prostu ujawniam publicznie wszystkie pola. Żadnych pobierających, ustawiających, konstruktorów. Nie nic. Mniej niż pojo. Dla mnie to natychmiast sygnalizuje „słuchaj, jestem głupi. Trzymam dane, to wszystko. Twoim zadaniem jest umieszczenie we mnie właściwych danych”. Gson / JAXB / itp. poradzić sobie z tymi klasami w porządku. Są błogosławieństwem do napisania. Nie ma wątpliwości co do ich celu lub możliwości. A co najważniejsze: wiesz, że po zmianie zmiennej nie występują żadne skutki uboczne. IMHO powoduje to bardzo zwięzłe modele danych z kilkoma niejednoznacznościami, podczas gdy osoby pobierające i ustawiające mają ten ogromny problem, w którym czasami dzieje się w nich magia.

Słowami laika:

• Naruszasz enkapsulację , aby zapisać kilka wierszy kodu. To przeczy celowi OOD.
• Kod klienta będzie sztywno powiązany z nazwiskami członków twojej klasy. Sprzężenie jest złe. Głównym celem OOD jest zapobieganie sprzężeniu.
• Jesteś również bardzo pewien, że twoja klasa nigdy nie będzie musiała być zmienna. Rzeczy się zmieniają. Zmiana jest jedyną stałą rzeczą.

Jedną z możliwych wad, którą widzę od razu, jest to, że jesteś przywiązany do wewnętrznej reprezentacji danych w klasie. To chyba nie jest wielka sprawa, ale jeśli użyjesz seterów i zdecydujesz, że foo i bar zostaną zwrócone z innej klasy zdefiniowanej gdzie indziej, klasy zużywające MyObject nie będą musiały się zmieniać. Wystarczy dotknąć MyObject. Jeśli jednak użyjesz nagich wartości, musisz dotknąć wszędzie tego, z którego korzystałem MyObject.