Pautas de uso de la Interfaz Java - ¿Son malos los getters y setters en una interfaz?

No veo por qué una interfaz no puede definir getters y setters. Por ejemplo, List.size() es efectivamente un captador. Sin embargo, la interfaz debe definir el comportamiento en lugar de la implementación - no puede decir cómo manejarás el estado, pero puede insistir en que puedas obtenerlo y configurarlo.

Las interfaces de colección tienen que ver con el estado, por ejemplo, pero diferentes colecciones pueden almacenar ese estado de maneras radicalmente diferentes.

EDITAR: Los comentarios sugieren que getters y setters implican que se utiliza un campo simple para el almacenamiento de respaldo. Estoy vehementemente en desacuerdo con esta implicación. En mi opinión, hay una implicación de que es "razonablemente barato" para obtener/establecer el valor, pero no que se almacena como un campo con una implementación trivial.

EDITAR: Como se indica en los comentarios, esto se hace explícito en la especificación JavaBeans sección 7.1:

Por Lo tanto, incluso cuando un guionista tipos en algo como b.Label = foo hay todavía una llamada de método en el objeto de destino para establecer la propiedad, y el objeto de destino tiene completo control programático.

Así que las propiedades no tienen que ser simples campos de datos, que en realidad pueden ser valores calculados. Las actualizaciones pueden tener varios efectos secundarios programáticos. Para ejemplo, cambiar el fondo de un frijol la propiedad color también puede causar bean para ser repintado con el nuevo color."

Si la supuesta implicación fuera verdadera, podríamos tan bien exponer propiedades como campos directamente. Afortunadamente esa implicación no se sostiene: los getters y setters están perfectamente dentro de sus derechos para calcular las cosas.

Por ejemplo, considere un componente con

getWidth()
getHeight()
getSize()

¿Cree que hay una implicación de que hay tres variables allí? ¿No sería razonable tener:

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 (preferentemente IMO):

private Size size;

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

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

public Size getSize() {
    return size;
}

Aquí, la propiedad size o las propiedades height / width son para solo conveniencia, pero no veo que eso los haga inválidos de ninguna manera.

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

1. Tiendo a hacer mis objetos inmutables (en primera instancia) con respecto a los campos que contienen. ¿Por qué? Instancio la mayoría de las cosas durante la fase de construcción. Si quiero cambiar algo más tarde, entonces relajo esas restricciones. Así que mis interfaces tenderán a contener getters, pero no setters (hay otros beneficios - particularmente threading).
2. Quiero que mis objetos hagan cosas por mí , no al revés. Así que cuando uno de mis objetos adquiere una serie de captadores, empiezo a preguntar si ese objeto debería tener más funcionalidad en él, en lugar de exponer todos sus datos para otra cosa con la que trabajar. Vea esta respuesta para más detalles.

Estas son todas las directrices, nota.

No creo que un bean deba tener una interfaz encima, en general. Un javabean es una interfaz en el sentido más general. Una Interfaz especifica el contrato externo de algo más complejo. El contrato externo de un javabean y su representación interna son idénticos.

No diría que no deberías tener getters en una interfaz, sin embargo. Tiene mucho sentido tener una interfaz ReadableDataThingie implementada por DataThingieBean.

He oído a la gente decir que, como un regla general, una interfaz solo debe define el comportamiento y no el estado. Hacer esto significa que una interfaz no contener getters y setters?

Para empezar, al menos con Java y excluyendo declaraciones de excepción, no se puede definir un comportamiento completo sin estado. En Java, las interfaces no definen el comportamiento. Lo que definen son tipos; promesas de implementar un conjunto de firmas de características posiblemente con algunos post-condiciones wrt excepciones. Pero eso es todo. El comportamiento y el estado están definidos por las clases que implementan esas interfaces.

En segundo lugar, si los getters y setters están definidos en una interfaz, realmente no definen el comportamiento completo (otro que uno es para read y otro para write wrt a property.) Puede tener un comportamiento complejo detrás de los setters y getters, pero solo se pueden implementar en las clases reales. No hay nada en el lenguaje Java que nos permita definir libremente el comportamiento en interfaces excepto en los casos más restrictivos.

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

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

Ahora, si nos fijamos en getters y setters desde el punto de vista de implementando clases compatibles con las especificaciones de JavaBeans, entonces no necesita definir interfaces para ellas.

Pero si tiene cosas que requieren setters y getters, como un bean might, y que también se requiere que se conecten al tipo de compilación (no en tiempo de ejecución como un bean might), y para las que pueden existir múltiples implementaciones, entonces sí, esto requeriría una interfaz que defina getters y setters.

Espero que ayude.

Esto toca todo el tema Getter/Setters are evil que se aborda varias veces en este sitio y en otros lugares.

Tiendo a preferir no tener accesores en la interfaz, sino agregar colaboradores usando argumentos de constructor a la implementación.

El hecho de que la implementación directa de algo sea como un getter no debería impedir que esté en una interfaz si es necesario.

Para más información: Confesiones prácticas de Diseño de API de un Arquitecto de Marco de Java (Jaroslav Tulach, 2008, Apress).

Utilicé ese tipo de interfaces, por ejemplo, teníamos clases con campos beginDate, endDate. Esos campos estaban en muchas clases y tenía un caso de uso que necesito para obtener esas fechas para diferentes objetos, así que extraje la interfaz y estaba muy feliz:)

Básicamente si la respuesta a "¿Necesito saber el valor de [state, property, whateverThignAMaGit] para trabajar con una instancia de la misma ?"entonces sí... los accesores pertenecen a la interfaz.

Lista.size () de John es un ejemplo perfecto de un getter que necesita ser definido en una interfaz

Los getters se utilizan para consultar el estado de un objeto, lo que realmente puede evitar al diseñar su interfaz. Leer http://www.pragprog.com/articles/tell-dont-ask