2012-01-28 10 views
19

Duplicar posibles:
Protected in Interfacesmétodos de interfaz no puede haber protegidas

En Java por qué no puedo yo he protegido métodos en una interfaz?

Puesto que de acuerdo a las especificaciones Java

acceso protegido (denotado por la palabra clave protegida) - un campo o método accesible para cualquier tipo en el mismo paquete, y para las subclases en cualquier paquete.

Si tengo que usar la interfaz, voy a implementarla y anular los métodos. Entonces, si voy a implementar donde la clase tiene acceso a esos métodos, desde el método accesible en cualquier paquete. Entonces, ¿cuál es el daño al declarar el método como protegido en la interfaz?

+4

Muy buena pregunta. Para casi cualquier otra cosa en Java, he encontrado una razón real para las elecciones realizadas, pero para esta no lo he hecho. Tiene mucho sentido para mí definir un método protegido en una interfaz que permita que otra clase dentro del mismo paquete use este método en un objeto de implementación sin necesidad de exponer ese método, que no debe ser invocado por nadie más que el miembros del paquete, para el resto del mundo. –

+0

@MarkusA., +1, también vea http://stackoverflow.com/questions/5376970/protected-in-interfaces#comment-39795200 – Pacerier

Respuesta

11

Los métodos protegidos están diseñados para compartir la implementación con las subclases. Las interfaces no tienen nada que ofrecer en lo que respecta al uso compartido de la implementación, porque no tienen implementación en absoluto. Por lo tanto, todos los métodos en las interfaces deben ser públicos.

+24

Aunque entiendo su punto aquí, ¿no obliga un método "público" en una interfaz a la clase implementadora a compartir también ese método con el resto del mundo? Si se utiliza una interfaz para hacer que las partes internas de una API sean más modulares, eso no significa que, de repente, el desarrollador quiera exponer sus componentes internos al resto del mundo. Con esta limitación, un método que tiene una implementación y está destinado a ser 'package-protected' (predeterminado) se fuerza a convertirse en' public' debido a la 'interface' que está cumpliendo. Entonces, aunque tiene sentido para 'protected', no parece para 'default' – jbx

+1

@jbx Tiene razón: las interfaces de paquete privado crean un problema interesante. Sin embargo, creo que podría abordarse a nivel de compilador al permitir que los métodos de paquete privado proporcionen implementaciones de interfaces de paquete privado. – dasblinkenlight

+1

En realidad, creo que la interfaz en sí misma puede ser de paquete privado, por lo que en realidad lo que esta restricción está haciendo es aplicar un enfoque de todo o nada. No puede tener la mitad de los métodos 'public' y la mitad de ellos protegidos por paquete. Puede ver la 'interfaz' con todos sus métodos, o no puede. Tal vez eso es lo que los creadores más poderosos pretendían después de todo :). Sin embargo plantea el problema anterior de todos modos. Una clase 'public' que implemente una' interface' protegida por paquetes tendrá que tener los métodos que implementan la interfaz 'public'. – jbx

-1

Si hay daño o no es inmaterial. Su punto es discutible si el compilador no lo permite. Los diseñadores de idiomas decidieron requerir que todos ellos sean públicos, y sería imposible cambiarlo ahora sin romper mucho código.

+0

Ha explicado el punto. Podría haber sido diferente. De alguna manera, el mecanismo de amistad está cerca de tener métodos protegidos en las interfaces, es una manera de definir los contratos pero también una forma de limitar a las personas que pueden confiar en el contrato. Pero en Java, las interfaces se han diseñado para permitir solo los métodos públicos, y hasta ahora, no hay limitaciones reales para eso, la comunidad de programadores de Java siempre encontró soluciones a esta situación y Java permite lograr algunas de las cosas más grandes que pudimos en IT ... más que nada porque proporciona una manera limpia de hacer programas. – Snicolas

+2

Coulda, woulda, shoulda, así va el mundo. No he escrito el software perfecto todavía. Y no veo esto como un defecto fatal en el lenguaje. No estoy de acuerdo en que sea un gran problema. – duffymo

+1

En realidad, me parece una pregunta muy interesante cuál sería el daño.Para casi todas las demás decisiones tomadas por los diseñadores de Java, he encontrado una razón que tiene sentido lógico. Incluso cosas complicadas como http://stackoverflow.com/questions/197190/why-cant-i-use-a-type-argument-in-a-type-parameter-with-multiple-bounds (vea el punto 2 en el segundo responder). No para este. –

5

La interfaz de un objeto es la parte de ese objeto que es visible para los usuarios externos de esa clase. Por el contrario, los métodos (y campos) protegidos y privados pertenecen a la clase interna. Están encapsulados dentro de la clase y un usuario de la clase no debería estar al tanto de ellos.

Por lo tanto, dado que interface se usa para definir interfaces (sin juego de palabras), es razonable que no contengan métodos protegidos.

Uno no quiere pensar en aplicación al definir un interface

Cuestiones relacionadas