tutorial - ¿Por qué Java no tiene propiedades automáticas como C#?

que es c sharp

Question

C # tiene propiedades automáticas que simplifican enormemente su código:

public string Name { get; set; }
public string MiddleName { get; set; }
public string LastName { get; set; }

Mientras que Java te hace escribir tanto código:

private String name;
private String middleName;
private String LastName;

public String Name(){
   return this.name;
}

etc..

¿Hay alguna razón particular por la cual Java no haya implementado algo como esto?

Answer 1

.net llegó después de Java, y uno de sus objetivos era interoperar con COM. COM tenía propiedades, probablemente a la VB, por lo que .net tenía que agregarlas para hacer que los idiomas fueran interoperables. (Eso, y fueron una idea bastante elegante).

Java no tenía tal necesidad, y sus creadores probablemente no quisieron contaminar el significado de "=" o hacer que las llamadas a funciones parezcan variables miembro. (Son, o al menos lo fueron, en algún momento, lo importante para mantener el lenguaje lo más limpio posible). En su lugar, fueron las especificaciones del bean Java, que especificaban una convención de nomenclatura para captadores y definidores. Los IDE que conocen la especificación pueden más o menos modificar la vista del captador y del configurador como una "propiedad" única para propósitos de diseño.

Answer 2

Las propiedades automáticas se basan en las propiedades.

Las propiedades en C # son una característica del lenguaje, en Java son una convención (los métodos que comienzan con get o set a menudo son considerados propiedades por las personas que hablan sobre el código, pero para el compilador no es diferente de foo o bar).

.NET y sus lenguajes asociados se basaban en muchos aspectos en COM (a veces en el ejemplo siguiente, a veces en no hacer deliberadamente algo en COM que era por alguna razón u otra impopular).

COM tiene un concepto de propiedades que en VB estaba respaldado por características de lenguaje (en C ++ estaba respaldado por convenciones).

Las primeras versiones de VB, especialmente en contextos en los que se usaba para proporcionar acceso programático básico a modelos de objetos proporcionados de otros lugares, tenían como objetivo simplificar los modelos de objetos presentados a los usuarios para hacer la distinción entre un campo y un método que se obtiene o establece (tal vez con trabajo adicional, quizás no) poco importante (considere que aunque difieren de alguna manera importante del exterior en .NET, el acceso sintáctico a una propiedad y a un campo público es lo mismo). Cuando VB y COM (y antes de eso OLE) crecieron, crecieron juntos.

Así que en general, mientras que C # comparte una herencia de C / C ++ con Java, también tiene una herencia que Java no comparte, lo que hace que las propiedades parezcan una buena idea para los creadores de C #, pero no para las de Java.

Edit: Al principio dije:

Personalmente, creo que las propiedades automáticas son realmente una solución a una falla en las propiedades, en lugar de una manera de simplificar su código. Las propiedades "parecen" sintácticamente a los campos públicos, pero no lo son completamente (intente usar DataBinder.Eval para recuperar un campo). Si una propiedad era totalmente pública y no tenía ninguna funcionalidad adicional en getter o setter (que es el caso de las propiedades automáticas), preferiría tener un campo público (la encapsulación no es un argumento aquí, ya que la expone totalmente públicamente por pasa eso de todos modos), pero las diferencias entre los campos y las propiedades funcionan en contra de eso.

Retiro esa afirmación. Hacer campos exactamente como propiedades requeriría que los campos de estructuras simples de datos antiguos funcionaran como propiedades, lo que sería una pérdida de rendimiento. Conceptualmente, me gustaría que se parecieran más, pero cada vez que pienso en ello (y he pasado de molestarme a ir a "oh, espera", como aquí más de una vez), es mejor como está.

Answer 3

No es tan fácil agregar nuevas funciones a un lenguaje de programación existente, especialmente si le importa la compatibilidad con versiones anteriores. Sun siempre ha sido extremadamente cuidadoso al agregar nuevas características a Java, porque querían estar absolutamente seguros de que cualquier nueva característica de lenguaje no interrumpiría los millones de programas Java que se han escrito a lo largo de los años.

Entonces, no es solo una cuestión de agregar esto al lenguaje; tienes que pensar con mucho cuidado y probarlo para descubrir si no hay problemas sutiles de compatibilidad con versiones anteriores con cualquier característica nueva que desees agregar.

Ha habido propuestas para agregar soporte para propiedades de una forma u otra en Java, pero parece que para Java 7 (la próxima versión que viene) no es una característica que se esté considerando.

Es posible que desee echar un vistazo al Proyecto Lombok , que es un tipo de extensión para Java, que usa anotaciones, para hacer posible escribir código más conciso (por ejemplo, puede generar captadores y definidores para campos).

Answer 4

Por la misma razón, el C # 2.0 o inferior no tiene esto. Es más o azúcar sintáctica más que una característica del lenguaje. Hay muchas características como esta que podrían agregarse a cualquier idioma, pero nadie sabe por qué no son el idioma.

Answer 5

Sí, porque no lo tiene. Como dice el dicho, todas las características comienzan sin ser implementadas.