Interfaces y herencia de clase abstracta, implementación en clases ampliadas

Question

En cada ejemplo que he visto, las clases extendidas implementan las interfaces de sus padres. Como referencia, el siguiente ejemplo:

interface MyInterface{ 
    public function foo(); 
    public function bar(); 
} 

abstract class MyAbstract implements MyInterface{ 
    public function foo(){ /* stuff */ } 
    public function bar(){ /* stuff */ } 
} 

// what i usually see 
class MyClass extends MyAbstract implements MyInterface{} 

// what i'm curious about 
class MyOtherClass extends MyAbstract{} 

es el fracaso para implementar una interfaz en un niño, que es implementado por un padre, considerada una mala práctica o algo? ¿Hay algún inconveniente técnico en omitir la implementación en el niño?

Answer 1

Considero que estás en el camino correcto. No es necesario que declare que está implementando la interfaz, al extender una clase que ya sea implements. Para mí es solo otra pieza de código para mantener si se necesita un cambio. Entonces, sí, ¡estás en lo correcto!

Answer 2

¿No se implementó una interfaz en un elemento secundario, que es implementada por un padre, se considera una mala práctica o algo así?

El niño siempre implementa la interfaz, no puede funcionar con esto.

No tengo ni idea si eso es una mala práctica o algo así. Yo diría que es una función de idioma.

¿Hay algún inconveniente técnico al omitir la implementación en el niño?

No se puede probar el reflejo de la clase abstracta para tener la interfaz, por ejemplo.

Sin embargo, la clase abstracta ya es una interfaz, por lo que técnicamente ellos mismos realmente no necesitan la interfaz, pero puede hacerlo para mantener las cosas dentro de la herencia.

Answer 3

es el fracaso para implementar una interfaz en un niño, que es implementado por un padre , considerado mala práctica o algo? ¿Hay algún inconveniente técnico en al omitir la implementación en el niño?

No puedo responder a su pregunta mejor que este tipo tiene:

Por su naturaleza, aunque a veces tienen un aspecto muy similar, abstracta clases e interfaces de clase servir fines muy distintos .

La interfaz de una clase se entiende como una herramienta para el "usuario" de esa clase. Una interfaz es una presentación pública para la clase, y debe anunciar, a cualquiera que esté pensando en usarla, qué métodos y constantes están disponibles y accesibles desde el exterior. Por lo tanto, como su nombre lo indica, siempre se encuentra entre el usuario y la clase que lo implementa.

Por otro lado, una clase abstracta es una herramienta destinada a ayudar a la "implementador" de las clases que se extienden .Es una infraestructura que puede imponer restricciones y directrices sobre cómo deberían ser las clases concretas de . Desde una perspectiva de diseño de clase , las clases abstractas son arquitectónicamente más importantes que las interfaces. En este caso, el implementador se encuentra entre la clase abstracta y la de concreto, construyendo esta última encima de la primera.

Reference

Por lo tanto, le toca a usted decidir, sobre la base de que se va a utilizar (instancias del mismo) sus clases, y quién va a escribirlos. Si eres el único usuario y escritor de tus clases, entonces, tal vez, solo tal vez, no los necesites a los dos. Pero, si desea darles a todos un modelo simplificado de bits centrales para el/los escritor (es) y los usuarios de la clase, entonces debería considerar usar tanto el resumen como la implementación.

Answer 4

Bueno, yo también estaba confundido, pero creo que debería usar este último, tiene razón, si implementa la interfaz en la clase abstracta, entonces no hay necesidad de escribir la interfaz, puede escribir el método en la interfaz todo en abstracto como métodos abstractos, porque extenderás la clase abstracta lo que sea, y tendrás que usar la clase abstracta como un tipo param cuando usas la clase en otro lugar, eso no es bueno, creo que un resumen la clase no debe usarse como un tipo param, mientras que una interfaz debe ser.