¿Está bien que las interfaces dependan de clases concretas?

Estoy creando una interfaz en Java para el controlador de errores personalizado.

Quiero pasar un objeto de error de argumento pero necesito que sea hijo de Exceptionclase.

¿Está bien usar mi nombre de clase definido en una interfaz?

¿No será menos una interfaz en términos de no depender de ninguna implementación?

Intento hacer algo como esto:

public class CustomException {
    /* ... Implementation ... */
}

public interface Interface {

    void onError(CustomException ex);

}

— nikachx
fuente

¿Estás tratando de preguntar si está bien heredar otra clase en una interfaz?

— Snoop

@StevieV No. Edité la pregunta, mira.

— nikachx

@AndresF. Es solo un ejemplo y se puede aplicar a cualquier lenguaje OO sobre el uso de clases en interfaces.

— nikachx

Dime: ¿es CustomExceptionparte de la implementación o parte de la interfaz?

— user253751

@nikachx No entiendo lo que quieres decir con "seguro". ¿De qué maneras es Stringmás seguro que CustomException? ¿Por qué importa si CustomException, a su vez, tiene otras dependencias?

— Andres F.

Respuestas:

Primero tengo que señalar el hecho de que CustomExceptionno se extiende, Exceptionpor lo que no es realmente un Exception.

Eso dijo:

Si no le importa el Principio de inversión de dependencia , déjelo como está. Está perfectamente bien que una interfaz dependa de clases concretas, por ejemplo, muchas interfaces dependen Stringo Objectcuáles son clases concretas . La cuestión es que tendemos a creer que las clases que pertenecen al SDK de Java son más estables (menos propensas a cambios de descifrado de código) que las que escribimos.

Por otra mano:

Si desea seguir el DIP (que tiene innumerables beneficios y es mi recomendación), debe hacer una de dos cosas:

Opción 1

Hacer CustomExceptionresumen
Mantener void onError(CustomException ex)como es

opcion 2

Hacer CustomExceptionuna interfaz
Mantener void onError(CustomException ex)como es

Con cualquiera de esas opciones, se conformaría con el DIP, ya que la interfaz no dependería de ninguna clase concreta, solo de abstracciones.

En una aplicación directa de inversión de dependencia, los resúmenes son propiedad de las capas superiores / políticas. Esta arquitectura agrupa los componentes superiores / de política y los resúmenes que definen los servicios inferiores juntos en el mismo paquete. Las capas de nivel inferior se crean por herencia / implementación de estas clases o interfaces abstractas . Martin, Robert C. (2003).

Desarrollo de software ágil, principios, patrones y prácticas. Prentice Hall. pp. 127-131. ISBN 978-0135974445.

— Tulains Córdova
fuente

No hay mucha diferencia entre aceptar una clase abstracta o una clase concreta (no final), y la diferencia con una interfaz no es mucho más que eso. Mientras la instancia se pase como un parámetro y no esté codificada en su implementación, tendrá las bases para DI.

— Jacob Raihle

@JacobRaihle ¿Qué quieres decir con pasar una instancia codificada en la implementación?

— Tulains Córdova

Dije "siempre y cuando sea aprobado y no codificado". Lo que quiero decir es que, dado que la Interfaceinterfaz acepta a CustomExceptiony deja que la persona que llama proporcione una, la persona que llama es libre de proporcionar cualquier clase que se extienda, CustomExceptionincluso si se CustomExceptiontrata de una clase concreta, lo que no hubiera sido posible si de Interfacealguna manera fuera responsable de crear eso. Esta inversión de control, más que trabajar con interfaces (aunque eso ciertamente ayuda), es de lo que creo que se trata DI.

— Jacob Raihle

@JacobRaihle "En una aplicación directa de inversión de dependencia, los resúmenes son propiedad de las capas superiores / políticas. Esta arquitectura agrupa los componentes superiores / políticas y los resúmenes que definen los servicios inferiores juntos en el mismo paquete. Las capas de nivel inferior se crean por herencia / implementación de estas clases abstractas o interfaces ". Martin, Robert C. (2003). Desarrollo de software ágil, principios, patrones y prácticas. Prentice Hall. pp. 127-131. ISBN 978-0135974445.

— Tulains Córdova

¿Cuál es el punto de una clase abstracta si puede proporcionar un valor predeterminado razonable? ¿Qué pierdes al proporcionar eso? No solo cite libros, piense.

— Jacob Raihle

Tulains tiene razón: las interfaces dependen de clases concretas todo el tiempo. Solo tienen la intención de crear un contrato para sus propias preocupaciones. Ese contrato puede implicar tomar y devolver cualquier tipo de datos.

Recuerde que en los lenguajes de nivel superior, incluso los tipos primitivos no son tan primitivos. ¡Así que estás trabajando con tipos concretos de todos modos!

— Sava B.
fuente

Supongo que por nombre te refieres a la clase en sí misma. Si está intentando especificar el nombre real de la clase de excepción para inicializar la excepción correspondiente a través de Reflection, este no es el camino correcto.

Si desea usar una clase personalizada en una interfaz, puede, por supuesto, usar sus propias clases en sus propias interfaces. Las clases se convierten en partes de la interfaz pública de su biblioteca / API. Las estructuras de datos y las excepciones son un buen ejemplo de las clases que suelen utilizar las interfaces.

Si necesita utilizar diferentes excepciones según el contexto, puede estar interesado en usar genéricos.

— Arseni Mourzenko
fuente

No, no me refiero a la reflexión. Sí, como mencionas, las excepciones y las estructuras de datos se pueden usar en las interfaces porque solo contienen datos y no son plataformas ni dependen de otras clases. Gracias.

— nikachx

Respuestas que hacen las preguntas de OP ... Simplemente haga un comentario, luego proporcione su respuesta.

— Snoop

@StevieV: El primer párrafo fue más una pregunta retórica. Y como lo muestra el comentario del OP, en realidad respondí la pregunta del OP.

— Arseni Mourzenko