propiedades - Ausencia de sintaxis de propiedad en Java

propiedades de los objetos en java

Question

C # tiene sintaxis para declarar y usar propiedades. Por ejemplo, uno puede declarar una propiedad simple, como esta:

public int Size { get; set; }

También se puede poner un poco de lógica en la propiedad, así:

public string SizeHex
{
    get
    {
        return String.Format("{0:X}", Size);
    }
    set
    {
        Size = int.Parse(value, NumberStyles.HexNumber);
    }
}

Independientemente de si tiene lógica o no, una propiedad se usa de la misma manera que un campo:

int fileSize = myFile.Size;

No soy ajeno a Java ni a C #. He usado tanto y siempre he echado de menos la sintaxis de la propiedad en Java. He leído en esta pregunta que "es muy poco probable que se añada soporte de propiedad en Java 7 o tal vez", pero francamente me resulta demasiado trabajo cavar en discusiones, foros, blogs, comentarios y JSR para averiguar por qué.

Entonces mi pregunta es: ¿alguien puede resumir por qué Java no tiene la sintaxis de la propiedad?

• ¿Es porque no se considera lo suficientemente importante en comparación con otras posibles mejoras?
• ¿Hay limitaciones técnicas (por ejemplo, relacionadas con JVM)?
• ¿Es una cuestión de política? (por ejemplo, "he estado codificando en Java desde hace 50 años y ¡digo que no necesitamos propiedades steenkin ''!" )
• ¿Es un caso de bikeshedding ?

Answer 1

- ¿Es porque no se considera lo suficientemente importante en comparación con otras posibles mejoras?

Esa es mi suposición.

- ¿Hay limitaciones técnicas (por ejemplo, relacionadas con JVM)?

No

- ¿Es una cuestión de política? (por ejemplo, "he estado codificando en Java desde hace 50 años y digo: ¡no necesitamos propiedades steenkin ''!")

Más probable.

- ¿Es un caso de bikeshedding?

¿Uh?

Uno de los principales objetivos de Java era mantener el lenguaje simple.

De: Wikipedia

Java suprime varias características [...] para las clases con el fin de simplificar el lenguaje y evitar posibles errores y diseño antipatrón.

Answer 2

Aquí hay algunos pequeños fragmentos de lógica que, para mí, conducen a que no le gusten las propiedades en un idioma:

Algunas estructuras de programación se utilizan porque están ahí, incluso si admiten malas prácticas de programación.

Setters implican objetos mutables. Algo para usar escasamente.

Buen diseño de OO le pide a un objeto que haga algo de lógica comercial. Las propiedades implican que usted está solicitando datos y manipulando los datos usted mismo.

Aunque puede CAN anular los métodos en setters y getters, pocos lo hacen; también una variable pública final es EXACTAMENTE la misma que un getter. Entonces, si no tienes objetos mutables, es un punto discutible.

Si su variable tiene lógica comercial asociada, la lógica debería estar GENERALMENTE en la clase con la variable. Si no es así, ¿por qué en el mundo es una variable? debe ser "Datos" y estar en una estructura de datos para que pueda ser manipulado por código genérico.

Creo que Jon Skeet señaló que C # tiene un nuevo método para manejar este tipo de datos, los datos que deberían escribirse en tiempo de compilación, pero en realidad no deberían ser variables, pero dado que mi mundo tiene muy poca interacción con el mundo C #, Solo tomaré su palabra de que es genial.

Además, acepto totalmente que dependiendo de tu estilo y el código con el que interactúas, simplemente TIENES que tener una situación set / get de vez en cuando. Todavía promedié un setter / getter en cada clase o dos, pero no lo suficiente como para hacerme sentir que se justifica una nueva estructura de programación.

Y tenga en cuenta que tengo requisitos muy diferentes para el trabajo y para la programación en el hogar. Para el trabajo donde mi código debe interactuar con el código de otras 20 personas, creo que cuanto más estructurado y explícito, mejor. En casa, Groovy / Ruby está bien, y las propiedades serían geniales, etc.

Answer 3

Creo que es solo la filosofía general de Java hacia las cosas. Las propiedades son algo "mágicas", y la filosofía de Java es mantener el lenguaje central lo más simple posible y evitar la magia como la peste. Esto permite que Java sea una lingua franca que pueda ser comprendida por cualquier programador. También hace que sea muy fácil razonar sobre lo que está haciendo una pieza de código aislada y arbitraria, y permite un mejor soporte de herramientas. La desventaja es que hace que el lenguaje sea más detallado y menos expresivo. Esta no es necesariamente la forma correcta o la incorrecta de diseñar un idioma, es solo una compensación.

Answer 4

Durante 10 años más o menos, el sol se ha resistido a cualquier cambio significativo en el lenguaje tan duro como pudiera. En el mismo período, C # ha atravesado un desarrollo fascinante, y ha añadido una serie de nuevas funciones increíbles con cada lanzamiento.

Creo que el tren se fue en propiedades en Java hace mucho tiempo, habrían sido agradables, pero tenemos la especificación Java-Bean. Agregar propiedades ahora solo haría el lenguaje aún más confuso. Si bien la especificación javabean IMO no es ni de lejos tan buena, tendrá que hacer. Y en el esquema más grandioso de las cosas, creo que las propiedades no son tan relevantes. El código de hinchazón en java es causado por otras cosas que no sean getters y setters.

Hay cosas mucho más importantes para enfocarse, como obtener un estándar de cierre decente.

Answer 5

Es la misma razón por la que no cambian nada más en Java: compatibilidad con versiones anteriores.

Answer 6

La sintaxis de propiedad en C # no es más que azúcar sintáctica . No lo necesita, solo está allí para su conveniencia. A la gente de Java no le gusta el azúcar sintáctico. Eso parece ser razón suficiente para su ausencia.

Answer 7

Las propiedades parecen más como un factor limitante en mi opinión. No veo particularmente una necesidad de propiedades.

Answer 8

Posibles argumentos basados ​​en nada más que mi opinión desinformada

• la sintaxis de la propiedad en C # es un hack feo, ya que mezcla un patrón de implementación con la sintaxis del lenguaje
• No es realmente necesario, ya que es bastante trivial.
• Afectaría adversamente a cualquier persona que pagara según líneas de código.

De hecho, me gustaría que hubiera algún tipo de azúcar sintáctica para las propiedades, ya que toda la sintaxis tiende a saturar el código que es conceptualmente extremadamente simple. Ruby por uno parece hacer esto sin mucho alboroto.

En una nota al margen, en realidad he intentado escribir algunos sistemas de tamaño mediano (unas pocas docenas de clases) sin acceso a la propiedad, solo por la reducción del desorden y el tamaño de la base de código. Aparte de los problemas de diseño inseguros (que estaba dispuesto a fudge en ese caso) esto es casi imposible, ya que cada framework, cada biblioteca, todo en java descubre automáticamente las propiedades por los métodos get y set. Están con nosotros hasta el momento. fin de los tiempos, algo así como pequeñas ruedas de entrenamiento sintáctico.

Answer 9

Puede ser útil agregarlo a Java, pero probablemente no sea tan alto en la lista como los cierres.

Personalmente, encuentro que un IDE decente hace que este sea un punto discutible. IntelliJ puede generar todos los getters / setters para mí; todo lo que tengo que hacer es integrar el comportamiento que hiciste en los métodos. No creo que sea un factor decisivo.

Admitiré que no estoy bien informado sobre C #, por lo que tal vez aquellos que sí me ignorarán. Esta es sólo mi opinión.

Answer 10

Si tuviera que adivinar, diría que tiene menos que ver con una objeción filosófica al azúcar sintáctico (añadieron autoboxing, mejorado para bucles, importación estática, etc., todo azúcar) que con un problema de compatibilidad con versiones anteriores. Hasta ahora, al menos, los usuarios de Java han intentado diseñar las nuevas características del lenguaje de forma tal que se mantenga la compatibilidad hacia atrás del nivel de fuente (es decir, el código escrito para 1.4 seguirá compilando y funcionando, sin modificaciones en 5 o 6 o más allá).

Supongamos que introducen la sintaxis de las propiedades. ¿Qué significa lo siguiente?

myObj.attr = 5;

Dependerá de si se trata de un código escrito antes o después de la adición de la función de propiedades, y posiblemente de la definición de la clase en sí.

No digo que estos problemas no puedan resolverse, pero soy escéptico de que se puedan resolver de una manera que conduzca a una sintaxis limpia y sin ambigüedades, a la vez que se preserva la compatibilidad con las versiones anteriores.

La gente de Python puede salirse con la suya rompiendo el viejo código, pero esa no es la forma de Java ...

Answer 11

Yo diría que refleja la lentitud del cambio en el lenguaje. Como mencionó un comentarista anterior, con la mayoría de los IDE ahora, realmente no es tan importante. Pero no hay razones específicas de JVM para que no esté allí.

Answer 12

De acuerdo con el Volumen 2 de Core Java (Olvidó a los autores, pero es un libro muy popular), los diseñadores de idiomas pensaron que era una mala idea ocultar una llamada al método detrás de la sintaxis de acceso de campo, y así lo omitieron.

Answer 13

Es posible que no necesite los prefijos "get" y "set", para que se vea más como propiedades, puede hacerlo así:

public class Person {
    private String firstName = "";
    private Integer age = 0;

    public String firstName() { return firstName; } // getter
    public void firstName(String val) { firstName = val; } // setter

    public Integer age() { return age; } // getter
    public void age(Integer val) { age = val; } //setter

    public static void main(String[] args) {
        Person p = new Person();

        //set
        p.firstName("Lemuel");
        p.age(40);

        //get
        System.out.println(String.format("I''m %s, %d yearsold",
            p.firstName(),
            p.age());
    }
}