¿Cuál es la mejor práctica para usar & # 8220; get & # 8221; en nombres de métodos?

Question

He notado en muchos lugares de Java (C # incluido), que muchos "getter" los métodos tienen como prefijo " get " mientras que muchos otros no lo son. Nunca noté ningún tipo de patrón que Sun parece estar siguiendo. ¿Cuáles son algunas pautas o reglas para usar " get " en nombres de métodos getter?

Answer 1

Todo se reduce a la semántica. Sí, C # tiene '' propiedades '' que le dan un stub de 'método' get / set ... pero funciones (... '' métodos '' ...) en .NET Framework que comienzan con '' Obtener '' se supone que debe dar pistas al desarrollador sobre el hecho de que está ocurriendo alguna operación con el único propósito de obtener algunos resultados.

Puede pensar que es extraño y decir "¿por qué no usar el tipo de retorno para dar pistas a las personas?", y la respuesta es simple. Piense en los siguientes métodos:

public Person CreatePerson(string firstName, string lastName) {...}

Simplemente por el nombre de ese método, probablemente pueda darse cuenta de que habrá actividad de la base de datos involucrada, y luego una "persona" recién creada será devuelto.

pero, ¿qué pasa con esto:

public Person GetPerson(string firstName, string lastName) {...}

Con solo ese nombre del método, probablemente pueda suponer que un 100% "Seguro" se está realizando la recuperación de una persona de una base de datos.

Nunca llamarías al " CreatePerson " varias veces ... pero debería sentirse seguro para llamar a "GetPerson" todo el tiempo. (no debería afectar el "estado" de la aplicación).

Answer 2

" obtener " y " establecer " El par de prefijos en Java se usa originalmente como una convención para denotar java bean. Más tarde, se convirtió en una simple convención de encapsulación, ya que Java, a diferencia de C #, no tiene las propiedades adecuadas.

Answer 3

La mejor práctica en Java es usar los prefijos get y set para las propiedades.

Frameworks, bibliotecas de etiquetas, etc. buscarán métodos con esos prefijos y los usarán como propiedades.

Entonces, si tienes una clase java como esta ...

public class User{
    private String name;
    public String getName(){ return name;}
    public void setName(String name){ this.name = name; }
}

.. con struts-tags (o cualquier otra biblioteca de etiquetas basada en ognl) accederá a la propiedad de nombre con user.name .

El framework Spring también usa esta convención en los archivos de configuración xml.

Answer 4

Java (todavía) no admite propiedades. Getters y setters son una forma de evitar esto. Otros lenguajes, incluido C #, admiten propiedades y debería utilizarlos en su lugar. Esto no es solo una "mejor práctica" o bien: la serialización en C # dependerá de las propiedades, no de getters & amp; establecedores, por lo que no usar propiedades podría ocasionar todo tipo de problemas en el futuro si necesita serializar sus clases.

La ventaja de las propiedades es que hacen que el código sea más legible. Algo como

obj.setX(10);

en Java, se convierte en

obj.X = 10;

Sin embargo, detrás de escena, X es un método, en lugar de ser una variable, por lo que puede realizar una verificación de entrada sucia, etc.

Answer 5

Personalmente me gusta la siguiente regla:

• Utilice el prefijo get siempre que el valor sea directamente modificable con un método set correspondiente
• Suelte el prefijo get en situaciones donde el valor es algo que no puede establecer directamente como una propiedad (es decir, no hay un método setXXX equivalente)

La razón para el segundo caso es que si el valor no es realmente una "propiedad" configurable por el usuario como tal, entonces no debería necesitar un par de métodos get / set. Una implicación es que si se sigue esta convención y ve un método getXXX, también puede asumir la existencia de un método setXXX.

Ejemplos:

• String.length () : como las cadenas son inmutables, la longitud es un valor de solo lectura
• ArrayList.size () : el tamaño cambia cuando se agregan o eliminan elementos, pero no se puede configurar directamente

Answer 6

Ciertamente solía ocurrir que las API a menudo exponían propiedades de solo lectura sin el prefijo get : String.length () e incluso el más nuevo Buffer.capacity () siendo ejemplos razonables.

La ventaja de esto es que hay menos pelusa involucrada. La desventaja es que cualquier cosa que intente determinar propiedades automáticamente en función de las convenciones no las descubrirá. Personalmente, tiendo a errar al incluir el prefijo.

Por supuesto, en C # es sobre todo irrelevante ya que hay "real" propiedades de todos modos :)

Answer 7

Depende. A menudo es información redundante, incluso en idiomas sin propiedades.

En C ++, en lugar de un par getAttr () / setAttr (), es común proporcionar dos sobrecargas de una función Attr (): Attr nulo (Foo f); // El acomodador Foo Attr (); // El captador

En Java, es una práctica común prefijar get / set. Debo decir que la mejor práctica es ir con lo que es estándar en su idioma. En Java, la gente espera ver prefijos get / set, por lo que omitirlos podría confundir a las personas, aunque no sean estrictamente necesarios.

Answer 8

Objective C 2.0 también usa propiedades, usando la misma sintaxis de puntos.

Antes de eso, utilizaba un esquema de nomenclatura ligeramente diferente para captadores y definidores (que, naturalmente, todavía se puede usar con propiedades o para atributos antiguos simples).

value = [obj attr];

[obj setAttr:value];

[obj getAttr:&value];

Es decir, get se usa de una manera diferente. No devuelve un valor, pero almacena el resultado en la variable pasada.

El getter típico tiene el mismo nombre que el atributo, el setter es el atributo prefijado por set (según la convención de Java). Estas convenciones son utilizadas por el sistema KVO (Key-Value Observation), por lo que deben cumplirse.

Answer 9

Solo un pequeño apéndice: otra convención es que los captadores de campos booleanos tengan el prefijo '' es '' en lugar de "obtener", p. bool isEnabled () {return habilitado; }