Interfaz Java Directrices de uso - ¿Son captadores y definidores en una interfaz malo?

Question

¿Qué piensa la gente de las mejores directrices para utilizar en una interfaz? Lo que debe y no debe entrar en una interfaz?

la gente

He oído decir que, como regla general, una interfaz sólo debe definir el comportamiento y no estatal. ¿Significa esto que una interfaz No debe contener captadores y definidores?

Mi opinión: Tal vez no es así para los emisores, pero a veces pienso que captadores son válidos para ser colocado en una interfaz. Esto es simplemente para hacer cumplir las clases de implementación para poner en práctica esos captadores y de indicar que los clientes son capaces de llamar a los captadores de comprobar en algo, por ejemplo.

Answer 1

Creo que hay dos tipos de interfaces declaradas en general:

1. descripción del servicio . Esto podría ser algo así como CalculationService. No creo que los métodos getX debe estar en este tipo de interfaz, y sin duda no setX. Dan a entender con toda claridad los detalles de implementación, que no es el trabajo de este tipo de interfaz.
2. modelo de datos - existe solamente para abstraer la implementación de objetos de datos en el sistema. Estos podrían ser utilizados para ayudar en las pruebas o simplemente porque algunas personas tan viejo como yo recuerdan los días en que (por ejemplo) usando un framework de persistencia que atado a tener un superclasss particular (es decir que elegiría para implementar una interfaz en caso de que se cambiara su capa de persistencia). Creo que tener métodos JavaBean en este tipo de interfaz es totalmente razonable.

Nota: las clases de colecciones probablemente encajar en el tipo # 2

Answer 2

No veo por qué una interfaz no puede definir captadores y definidores. Por ejemplo, List.size() es efectivamente un getter. La interfaz debe definir el comportamiento en lugar de la aplicación sin embargo - no puede decir cómo va a manejar el estado, pero puede insistir en que lo puede conseguir y establecer a él.

interfaces Collection son todos acerca de estado, por ejemplo -. Pero diferentes colecciones se pueden almacenar en ese estado radicalmente diferentes maneras

EDIT: Las observaciones sugieren que los captadores y definidores implican un campo sencilla se usa para hacer copias de almacenamiento. Vehementemente en desacuerdo con esta implicación. Para mi mente hay una implicación de que es "razonablemente barato" para obtener / establecer el valor, pero no que se almacena como un campo con una aplicación trivial.

---

EDIT: Como se ha señalado en los comentarios, esto se hace explícito en el especificación JavaBeans sección 7.1:

  

Así, incluso cuando un guionista tipos   en algo como b.Label = foo   todavía hay una llamada a un método en el   Objeto de destino para establecer la propiedad, y   el objeto de destino tiene plena   control de programación.

     

Así propiedades no sólo necesitan ser simples   campos de datos, que puede ser en realidad   valores calculados. Las actualizaciones pueden tener   diversos efectos secundarios programáticos. por   ejemplo, cambiar el fondo de un grano   propiedad de color también puede hacer que el   frijol a ser repintado con el nuevo   de color ".

---

Si la supuesta implicación estaban cierto, que podría muy bien exponer propiedades como campos directamente. Afortunadamente esa implicación no de retención:. Captadores y definidores son perfectamente en su derecho de calcular cosas

Por ejemplo, considere un componente con

getWidth()
getHeight()
getSize()

¿Usted cree que hay una implicación de que hay tres variables de allí? ¿No sería razonable aplicar:

private int width;
private int height;

public int getWidth() {
    return width;
}

public int getHeight() {
    return height;
}

public Size getSize() {
    return new Size(width, height); // Assuming an immutable Size type
}

O (preferiblemente OMI):

private Size size;

public int getWidth() {
    return size.getWidth();
}

public int getHeight() {
    return size.getHeight();
}

public Size getSize() {
    return size;
}

A continuación, ya sea propiedad del tamaño o la altura / anchura propiedades son únicamente para conveniencia - pero no veo que eso les hace no válido en cualquier forma

.

Answer 3

No hay nada inherentemente malo en getters / setters. Sin embargo:

1. tiendo a hacer mis objetos inmutables (en primera instancia) con respecto a los campos que contienen. Por qué ? Me crear instancias de la mayoría de las cosas durante la fase de construcción. Si quiero cambiar algo más tarde, entonces me relajo esas restricciones. Así que mis interfaces tienden a contener captadores, pero no los emisores (hay otros beneficios - sobre todo enhebrar).
2. Quiero que mis objetos que se pueden hacer cosas para mí , y no al revés. Por eso, cuando uno de mis objetos adquiere una serie de captadores, comienzo a preguntar si ese objeto debe tener más funcionalidad en ella, en lugar de exponer todos sus datos para otra cosa que trabajar. Ver esta respuesta para obtener más detalles.

Estas son todas las directrices, nota.

Answer 4

No creo que un grano debe tener una interfaz en la parte superior de la misma, en general. Un JavaBean es una interfaz en el sentido más general. Una interfaz especifica el contrato externo de algo más complejo. contrato externo de un JavaBean y su representación interna son idénticos.

Yo no diría que no debería tener getters en una interfaz, sin embargo. Tiene todo el sentido de tener una interfaz ReadableDataThingie que es implementada por DataThingieBean.

Answer 5

  la gente

He oído decir que, como   regla general, una interfaz sólo deben   definir el comportamiento y no estatal. Hace   esto significa que una interfaz no debe   contener captadores y definidores?

Para empezar, al menos con Java y con exclusión de las declaraciones de excepción, no se puede definir el comportamiento completo sin estado. En Java, las interfaces no definen el comportamiento. Ellos no pueden. Lo que definen son tipos; promesas de la implementación de un conjunto de firmas de características posiblemente con algunas excepciones post-condiciones WRT. Pero eso es todo. Comportamiento y el estado son definidos por las clases que implementan dichas interfaces.

En segundo lugar, si los captadores y definidores se definen en una interfaz, no realmente el comportamiento de definición completa (otro que uno es para lectura y uno es para WRT escritura de una propiedad.) Puede tener un comportamiento complejo detrás de setters y getters, pero sólo pueden ser implementadas en las clases reales. No hay nada en el lenguaje Java que puede permitirnos definir libremente el comportamiento de las interfaces con excepción de las más restrictivas de los casos.

Con esto en consideración, no hay nada malo - sintácticamente y semánticamente -. Con tener setters y getters en las interfaces

Si la aplicación está bien modelado y el problema requiere que tenga una interfaz que define setters y getters, por qué no. Por ejemplo, echar un vistazo a la interfaz ServletResponse.

Ahora bien, si nos fijamos en los captadores y definidores desde el punto de vista de la implementación de clases que cumplen con las especificaciones JavaBeans, entonces no es necesario definir interfaces para ellos.

Pero si tiene cosas que requieren setters y getters, como un grano de potencia, y que también se requiere para ser conectado al tipo de compilación (no en tiempo de ejecución como un grano podrían), y para el que podrían existir múltiples implementaciones , entonces sí, esto exigiría una interfaz que define los captadores y definidores.

Espero que ayuda.

Answer 6

Esto afecta sobre todo el captadores / definidores son tema del mal que se aborda varias veces en este sitio y en otros lugares.

Me inclino a favor de no tener descriptores de acceso en la interfaz, pero para agregar colaboradores utilizando argumentos de constructor a la aplicación.

Answer 7

El hecho de que la aplicación directa de algo es como un captador no debe dejar que estar en una interfaz si necesita ser.

Answer 8

Para la lectura adicional:. API Práctica Diseño Confesiones de un arquitecto Marco de Java (Jaroslav Tulach, 2008, Apress)

Answer 9

He utilizado ese tipo de interfaces, por ejemplo, tuvimos clases con campos BeginDate, endDate. Esos campos eran en muchas clases y tuve un caso de uso que necesito para conseguir esas fechas para diferentes objetos, por lo que se extrae de interfaz y era muy feliz:)

Answer 10

Básicamente, si la respuesta a "¿Es necesario conocer el valor de [nombre del estado, propiedad, whateverThignAMaGit] con el fin de trabajar con una instancia de ella?" entonces sí ... los descriptores de acceso pertenecen a la interfaz.

List.size () de John anterior es un ejemplo perfecto de un captador que necesita ser definido en una interfaz

Answer 11

Compuestos absorbentes se utilizan para consultar el estado de un objeto - que se puede evitar realmente el diseño de su interfaz. Leer http://www.pragprog.com/articles/tell-dont-ask