2012-02-21 14 views
12

De alguna breve tocar el violín alrededor, encuentro que consigo un error al redefinir los métodos de superclase en una subclase cuando lo haga lo siguiente:¿Por qué PHP permite que los métodos protegidos y privados se hagan públicos mediante una anulación en subclases?

  • Anular un método de una clase protegida con un método de subclase privada
  • Anular una superclase pública método con un método de subclase protegida o privada

sin embargo, si lo hago en la otra dirección, se lanza ningún error:

  • Anulación de un método de una clase privada con un método protegido o subclase pública
  • Anulación de un método de una clase protegida con un método de subclase pública

Esto parece contra intuitivo para mí - me esperaba que trabajar al revés en orden para hacer cumplir la ocultación y el encapsulamiento de la información. Esto parece permitir un diseño deficiente al permitir que las partes internas se expongan de una manera que puede romper otros métodos y no puedo ver un caso cuando sería una buena idea. ¿Por qué se ha implementado de esta manera y qué me he perdido?

Además, ¿es esta práctica estándar en otros lenguajes de programación?

+0

¿Y por qué no debería? – YuS

+0

Quiero decir que para evitar que las dependencias se desarrollen entre componentes, es bueno apegarse a la cantidad mínima de métodos públicos expuestos. Permitir que los métodos privados se hagan públicos anima a otros desarrolladores a hacer uso de ellos y, por lo tanto, socava la capacidad de cambiar las clases utilizando polimorfismo. –

+1

Corrígeme si me equivoco: el lenguaje de programación debe ser una herramienta y debe ser lo más flexible posible; el diseño del código, los patrones y los comportamientos están en la conciencia del desarrollador. Ahora, si imaginamos que no está hablando de vulnerabilidades externas, ¿realmente está hablando de programadores de un equipo que sabotean el desarrollo? – YuS

Respuesta

15

Lo que usted llama "hacer cumplir la ocultación de información" es algo que puede romper las subclases, porque de repente las propiedades y los métodos pueden desaparecer. No se puede romper cosas al perder restricciones de esta manera.

Con private es un poco diferente: en este caso, la propiedad/método no existe desde el punto de vista de la clase infantil. Por lo tanto, no hay ninguna razón para que una subclase no pueda introducir una propiedad con ese nombre, ya que será una propiedad diferente de .

Tiene razón, esto puede conducir a un diseño deficiente, pero siempre puede crear una aplicación con un diseño deficiente.

+0

hm Estoy de acuerdo con matt. Esto no tiene sentido. para mí, solo debería haber una forma de guion: cada sublcaso debe respetar la visibilidad de las propiedades de la superclase (en todas las direcciones). – iRaS

+0

@iRaS lo que te estás perdiendo es que las propiedades/métodos privados no se tratan en absoluto de "ocultar información", sino de evitar que el comportamiento sea anulado o afectado por una clase secundaria. Si crea un nuevo método privado/público en una clase secundaria que tiene el mismo nombre que un método privado en la clase principal, la clase principal no llamará a ese método (a menos que utilice el enlace estático tardío para llamarlo) – Omn

8

No puede disminuir la visibilidad de los miembros de la clase, solo aumentarlos.

Imagina una clase A que tiene un método público, y una subclase B la convertiría en privada. B podría tratarse como un tipo A, para lo cual se supone que tiene ese método público.

+0

Sí, Veo lo que quiere decir, pero si lo hace de la otra manera seguramente surgirá un problema similar: ¿su código se vuelve dependiente de una función que B ha expuesto, que A todavía declara como privada? Supongo que estoy argumentando que público y privado/protegido no debe ser intercambiable a través de la herencia. –

+0

Podría romper la encapsulación de hecho. Yo personalmente no suelo hacer esto, si es que alguna vez lo hago. Pero todavía no afectaría a A, ya que A debería tratarse como A, no B. De hecho, no es el mejor diseño posible, diría yo. – fivedigit

0

Si una superclase expone un método públicamente, entonces todas sus subclases también deben exponer el mismo método (o una versión anulada), por lo tanto, reducir el acceso de un método es una subclase ilegal en PHP (y casi todas las clases basado en el lenguaje OO).

Lo contrario no es cierto, por lo que aumentar el acceso a los métodos en las subclases está perfectamente bien.

0

Si crees que exponer un método privado/protegido en una subclase representa un problema, simplemente haz que el método sea definitivo.

veo de esta manera: por NO hacer un último método, que está permitiendo a cualquier subclase anulando a voluntad; esto obviamente incluye aumentar su visibilidad.

Cuestiones relacionadas