¿Son los campos públicos de Java solo una trágica falla de diseño histórico en este momento? [cerrado]

Parece ser la ortodoxia de Java en este punto que básicamente nunca se deben usar campos públicos para el estado del objeto. (No estoy necesariamente de acuerdo, pero eso no es relevante para mi pregunta). Dado eso, ¿sería correcto decir que desde donde estamos hoy, está claro que los campos públicos de Java fueron un error / falla del diseño del lenguaje? ¿O hay un argumento racional de que son una parte útil e importante del lenguaje, incluso hoy?

¡Gracias!

Actualización: conozco los enfoques más elegantes, como en C #, Python, Groovy, etc. No busco directamente esos ejemplos. Realmente me pregunto si todavía hay alguien en el fondo de un búnker, murmurando sobre lo maravillosos que son realmente los campos públicos, y cómo las masas son solo ovejas, etc.

Actualización 2: los campos públicos finales claramente estáticos son la forma estándar de crear constantes públicas. Me refería más al uso de campos públicos para el estado del objeto (incluso el estado inmutable). Estoy pensando que parece un defecto de diseño que uno debe usar campos públicos para constantes, pero no para el estado ... las reglas de un lenguaje deben aplicarse de manera natural, por sintaxis, no por pautas.

Me gustan, siempre que el campo sea final y solo se use internamente en la aplicación, no expuesto en una API para otras aplicaciones. Esto mantiene su código más corto y más legible.

No debe exponer los campos públicos en una API porque al exponer los campos públicos, también expone la implementación. Si lo expones como un getXXX()método, puedes cambiar la implementación sin cambiar la interfaz API. Por ejemplo, podría cambiar y obtener el valor de un servicio remoto, pero las aplicaciones que usan la API no necesitan saberlo.

Este es un diseño viable para public finalcampos en clases inmutables .

De Java efectivo :

Elemento 14: en clases públicas, use métodos de acceso, no campos públicos

... si una clase es privada de paquete o es una clase privada anidada, no hay nada intrínsecamente incorrecto en exponer sus campos de datos. Este enfoque genera menos desorden que el enfoque del método de acceso.

Si bien nunca es una buena idea que una clase pública exponga los campos directamente, es menos dañino si los campos son inmutables.

Consulte también ¿Por qué no debería usar POJO inmutables en lugar de JavaBeans?

El uso de pares de métodos get / set es la trágica falla de diseño histórico. No puedo pensar en otro lenguaje que implemente propiedades de forma vergonzosa e ineficiente.

Creo que los campos públicos están bien para una clase que es esencialmente un tipo de valor como un número complejo o un punto, donde la clase hace poco más que agrupar tipos primitivos juntos como una estructura de estilo C y tal vez definir algunos operadores.

Para definir constantes públicas todavía es útil. P.ej

public static final int DAYS_IN_WEEK = 7;

Sin embargo, todavía prefiero enum's donde sea posible. P.ej

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

Para simular clases simples de estructura también es útil. No hay razón para crear un getter y setter para cada campo, cuando todos son públicos de todos modos.

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

Antes de que los IDE se generalizaran, hacer públicos todos sus campos era una herramienta poderosa para crear prototipos / pruebas de conceptos rápidamente.

Hoy en día hay muy pocas excusas para usarlos, cuando puedes generar un par getter / setter con un clic del mouse.

Esto es subjetivo, pero mi opinión es que toda la noción pública / privada está desactualizada y al revés.

En python no hay público / privado; todo es público básicamente. No ha causado muchos problemas.

En Java, tiende a crear captadores / establecedores sin sentido para cada campo para evitar el pecado de marcarlos como "públicos". (En mi humilde opinión, si te encuentras haciendo eso, solo debes marcarlos como públicos).