Czy publiczne pola Javy są w tym momencie tragiczną wadą historycznego projektu? [Zamknięte]

Wydaje się, że w tym momencie ortodoksja Java nie powinna zasadniczo używać pól publicznych do określania stanu obiektu. (Niekoniecznie się zgadzam, ale to nie dotyczy mojego pytania.) Biorąc to pod uwagę, czy byłoby słuszne powiedzieć, że z miejsca, w którym jesteśmy dzisiaj, jasne jest, że publiczne pola Javy były błędem / wadą projektu językowego? A może istnieje racjonalny argument, że są one użyteczną i ważną częścią języka, nawet dzisiaj?

Dzięki!

Aktualizacja: Wiem o bardziej eleganckich podejściach, takich jak C #, Python, Groovy itp. Nie szukam bezpośrednio tych przykładów. Zastanawiam się tylko, czy w bunkrze jest jeszcze ktoś, mamrocząc o tym, jak wspaniałe są naprawdę publiczne pola i jak masy są tylko owcami itp.

Aktualizacja 2: Wyraźnie statyczne końcowe pola publiczne są standardowym sposobem tworzenia stałych publicznych. Odniosłem się bardziej do używania pól publicznych dla stanu obiektu (nawet stanu niezmiennego). Myślę, że wydaje się to błędem projektowym, w którym należy używać pól publicznych dla stałych, ale nie dla stanu… reguły języka powinny być egzekwowane naturalnie, przez składnię, a nie przez wytyczne.

Lubię je, o ile pole jest ostateczne i jest używane tylko wewnętrznie w aplikacji, a nie ujawniane w interfejsie API dla innych aplikacji. Dzięki temu kod jest krótszy i bardziej czytelny.

Nie należy ujawniać pól publicznych w interfejsie API, ponieważ ujawniając pola publiczne, narażasz także implementację. Jeśli getXXX()zamiast tego udostępnisz go jako metodę, możesz zmienić implementację bez zmiany interfejsu API. Na przykład możesz zmienić i uzyskać wartość ze zdalnej usługi, ale aplikacje korzystające z interfejsu API nie muszą o tym wiedzieć.

Jest to realny projekt dla public finalpól w niezmiennych klasach.

Z Effective Java :

Punkt 14: W klasach publicznych używaj metod akcesorów, a nie pól publicznych

... jeśli klasa jest prywatna dla pakietu lub jest prywatną klasą zagnieżdżoną, nie ma nic złego w ujawnianiu jej pól danych. Takie podejście generuje mniej bałaganu niż podejście oparte na metodzie akcesorium.

Chociaż nigdy nie jest dobrym pomysłem, aby klasa publiczna wystawiała pola bezpośrednio, jest mniej szkodliwe, jeśli pola są niezmienne.

Zobacz także Dlaczego nie powinienem używać niezmiennych POJO zamiast JavaBeans?

Zastosowanie par metod get / set jest tragiczną wadą historycznego projektu. Nie mogę wymyślić innego języka, który implementuje właściwości jako mówiony i nieefektywny.

Myślę, że publiczne pola są odpowiednie dla klasy, która jest zasadniczo typem wartości, takim jak liczba zespolona lub punkt, w którym klasa robi niewiele więcej niż grupowanie pierwotnych typów razem, takich jak struktura typu C i może definiować kilka operatorów.

Nadal przydatne jest definiowanie stałych publicznych. Na przykład

public static final int DAYS_IN_WEEK = 7;

Jednak nadal wolą enum tam , gdzie to możliwe. Na przykład

public enum Day {
    SUNDAY, MONDAY, TUESDAY, WEDNESDAY, 
    THURSDAY, FRIDAY, SATURDAY 
}

Przydaje się także do symulacji prostych klas struktur . Nie ma powodu, aby tworzyć getter i setter dla każdego pola, gdy i tak są one publiczne.

class Point
{
    public int x, y;
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

Zanim IDE stały się powszechne, upublicznienie wszystkich pól było potężnym narzędziem do szybkiego tworzenia prototypów / proofów koncepcji.

W dzisiejszych czasach jest bardzo niewiele wymówek, aby z nich korzystać, kiedy można wygenerować parę getter / setter za pomocą kliknięcia myszy.

Jest to subiektywne, ale moim zdaniem całe pojęcie publiczne / prywatne jest przestarzałe i zacofane.

W Pythonie nie ma publicznych / prywatnych; zasadniczo wszystko jest publiczne. Nie spowodował wielu problemów.

W Javie tworzysz bezcelowe programy pobierające / ustawiające dla każdego pola, aby uniknąć grzechu oznaczania ich jako „publicznych”. (IMHO, jeśli to robisz, powinieneś po prostu oznaczyć je jako publiczne).