2010-04-15 8 views
6

En general, crear una API fluida es algo que hace felices a todos los programadores; Tanto para los creadores que escriben la interfaz como para los consumidores que programan en su contra. Mirando más allá de las convenciones, ¿por qué es que prefijamos todos nuestros captadores con la palabra "obtener". Omitirlo generalmente da como resultado un conjunto de instrucciones más fluido y fácil de leer, que finalmente conduce a la felicidad (por pequeña o pasiva que sea). Considera este ejemplo muy simple. (pseudo código)¿Por qué los getters llevan el prefijo "get"?

convencional:

person = new Person("Joey") 
person.getName().toLower().print() 

alternativa:

person = new Person("Joey") 
person.name().toLower().print() 

Por supuesto, esto sólo se aplica a los idiomas en los getters/setters son la norma, pero no se dirige a cualquier específica idioma. ¿Fueron estas convenciones desarrolladas alrededor de limitaciones técnicas (desambiguación), o simplemente a través de la búsqueda de un tipo de interfaz de sentimiento intencional más explícito, o tal vez este es solo un caso de norma de goteo lento? ¿Cuáles son tus pensamientos? Y cómo los cambios simples a estas convenciones afectarán su felicidad/actitudes diarias hacia su oficio (aunque sean mínimas).

Gracias.

+4

Algunos de nosotros no escribimos getters. O creemos en "APIs fluidas". –

+1

No estoy de acuerdo con eso person.name() 'es un conjunto más fluido y fácil de leer conjunto de instrucciones, ya que creo que el método realmente le asigna un nombre, o un apodo, a esta persona. Y, sinceramente, si tiene la intención de usarlo en ese contexto, 'person.name.whatever' se ve y se lee mucho más fácilmente como ahora,' name' se convierte en una propiedad (legible/asignable) en lugar de un método. –

+2

así que cuando tenga IDE con el código completado, puede escribir "obtener" y ver todos los captadores – colinjwebb

Respuesta

10

Porque, en los idiomas sin propiedades, name() es una función. Sin embargo, sin más información, no es necesariamente específico sobre lo que está haciendo (o lo que va a devolver).

Las funciones/métodos también se supone que son verbos porque están realizando alguna acción. name() obviamente no se ajusta a la factura porque no le dice nada acerca de qué acción está realizando.

getName() le informa sin lugar a dudas que el método devolverá un nombre.

En los idiomas con propiedades, el hecho de que algo sea una propiedad expresa el mismo significado que tenerlo o adjuntarlo. Simplemente hace que las cosas se vean un poco más ordenadas.

+0

De acuerdo. Esto cae en el caso que mencioné como explícito sobre las cosas intencionalmente en cuanto a no crear ningún tipo de ambigüedad. Sin embargo, estoy convencido de que una API bien diseñada usaría los nombres correctos para oscurecer cualquier ambigüedad de esa manera. Como desafío, ¿puedes darme un ejemplo en el que la falta del prefijo te haga pensar que no sabes qué está pasando? – Joey

+0

@Joey: El problema con su arreglo de nombres no son los nombres sino los parens. Los parens sugieren ejecutar una acción, en lugar de devolver el valor de una propiedad. Es por eso que se necesita el prefijo 'get'. –

+0

@robert punto muy válido. En situaciones en las que dicho lenguaje no tiene ningún mecanismo para implementar los descriptores de acceso a la propiedad, o después de que el hecho cambie a una implementación de propiedad, el uso de parers en torno al nombre desnudo es realmente la única situación. – Joey

1

En la escuela nos enseñaron a utilizar llegar a distinguir los métodos de las estructuras de datos. Nunca entendí por qué los parens no serían un indicio. Soy de la opinión personal de que el uso excesivo de los métodos get/set puede ser una terrible pérdida de tiempo, y es una fase en la que veo a muchos programadores orientados a objetos después de que comienzan.

+2

Su escuela no lo hizo bien, IMO. –

+1

Por otro lado, apruebo su opinión personal. –

+0

Vea aquí para el uso apropiado de getters y setters: http://stackoverflow.com/questions/565095/java-are-getters-and-setters-evil –

4

La mejor respuesta que he escuchado para el uso de los prefijos set/get es como tal:

Si no se utilicen, tanto el descriptor de acceso y mutador (get y set) tendría el mismo nombre; por lo tanto, estarían sobrecargados. En general, solo debe sobrecargar un método cuando cada implementación del método realiza una función similar (pero con entradas diferentes).

En este caso, tendría dos métodos con el mismo nombre que desempeñaron funciones muy diferentes, y que podrían ser confusos para los usuarios de la API.

+1

buena observación. Los setters, creo, merecen con razón el prefijo, ya que cambian algún tipo de estado. No es un juego de suma cero, librarse del "obtener" no conduce necesariamente a librar al "conjunto". ¿Qué pasa si solo se utilizó el conjunto, y así evitar la sobrecarga? – Joey

+0

@Joey: Eso suena como más ruido que simplemente usar 'get' y' set', ya que uno no se parece al otro. Y todavía tiene el problema con parens sugiriendo una acción para ser ejecutada, en lugar de una propiedad para ser recuperada. –

+0

Estaría bien si la convención fuera que cada método que no tenía un verbo en su nombre era un descriptor de acceso. – danben

0

Personalizado.

Además, en C++, si devuelve una referencia, que proporciona posibles pérdidas de información en la propia clase.

+0

¿De verdad? ¿Crees que el operador [] de std :: string (por ejemplo) causa una fuga de este tipo? –

+0

Neil: No significa per se fugas de memoria. –

+0

No quise decir ni mencionar filtraciones de memoria. Quise decir su propio concepto de "fuga". –

3

¿Qué pasa con el caso en que una propiedad lleva el nombre de un verbo?

object.action() 

¿Esto puede el tipo de acción a realizar, o ejecutar la acción ... La adición get/set/do elimina la ambigüedad que siempre es una buena cosa ...

object.getAction() 
object.setAction(action) 
object.doAction() 
+0

Gracias por la respuesta curiosa. ¿Puede darme un ejemplo en el que una propiedad con el nombre de un verbo también podría usarse lógicamente como un getter? – Joey

+0

"acción" no es un verbo, por lo que este es un mal ejemplo. En general, las propiedades siempre se nombran después de sustantivos, no de verbos. –

4

Siempre aprecio el prefijo get/set consistente cuando trabajo con una nueva API y su documentación. La agrupación automática de getters y setters cuando todas las funciones están enumeradas en su orden alfabético, ayuda enormemente a distinguir entre el acceso simple a los datos y la funcionalidad avanzada.

Lo mismo es cierto cuando se usa intellisense/autocompletado dentro del IDE.

+0

Este es un punto muy bueno, tal vez el más fuerte en mi opinión. – Joey

0

Puede que no escriba mucho Objective-C, pero desde que lo aprendí me encantan sus convenciones. Lo que está preguntando es addressed por el idioma.

+1

@jsumners muchos círculos alrededor de apple realmente no usan esta convención. (* a través del estilo de webkit gudie *). "Precede setters con la palabra" set ". Use palabras simples para getters. Setter y getter nombres deben coincidir con los nombres de las variables que se establecen/getten". http://webkit.org/coding/coding-style.html. Por supuesto, ciertos lenguajes han abandonado tales convenciones porque tienen convenciones o construcciones de lenguaje para evitarlos. El kilometraje puede variar. – Joey

+0

Bueno, tengo que usar C# en el trabajo. C# tiene propiedades, pero son molestas (como se aludió en la pregunta original). Por ejemplo, esto no funcionará:

 public class MyClass { private int foo; public int foo { get { return this.foo; } set { this.foo = value; } } } 
En su lugar, usted tiene que hacer:
 public class MyClass { private int _foo; public int foo { get { return this._foo; } set { this._foo = value; } } } 
Sólo pienso en Objective-C es un poco menos molesto en este sentido. –

+1

Impresionante. Los comentarios no son compatibles con el marcado. –

1

Aquí hay una respuesta de Smalltalk que me gusta más. Uno tiene que conocer algunas reglas sobre Smalltalk BTW. campos solo son accesibles en los que están definidos. Si no escribe "acceso", no podrá hacer nada con ellos.

La convención no está teniendo una variable (por no hablar de ANME que instVar1 continuación, se escribe una función instVar1 la que sólo devuelve instVar1 y instVar:.. Que establece el valor

me gusta esta convención mucho más que cualquier otra cosa Si ves un: en algún lugar puedes apostar que es un "setter" en uno u otro sentido.

Cuestiones relacionadas