Al mirar la base de código (madura) en mi nuevo trabajo, hay una interfaz, y solo una clase la implementa (hasta donde yo sé). ¿Puedo/debería deshacerme de la interfaz?¿Hay algún punto para una interfaz si solo una clase lo implementa?
¡De ninguna manera! No tiene ningún efecto dañino y un día alguien puede cambiar una implementación sin tener que refactorizar toneladas de código.
Por "toneladas de código", ¿quiere decir que podría escribirse otra clase con una implementación diferente de la interfaz, y podría pasarse a métodos esperando una variable que implementa esa interfaz sin cambiar las firmas de método?¿Algún otro ejemplo de refactorización que podría evitarse manteniendo la interfaz e implementando una nueva clase? – user343587
@ user343587 Sí, pero ¿y si necesita dos implementaciones diferentes de esa interfaz y tiene que cambiarlas en tiempo de ejecución? Seguro, podrías resumirlo pero luego estarás en el mismo bote. – jfar
Sí, hay un punto para las interfaces, ya que podría haber más de una implementación en el futuro. Por supuesto, puede ir por la borda aquí y crear interfaces para todo, por lo que hay un equilibrio que se puede encontrar.
Hoy, no. ¿Seis meses después de que el proyecto se haya multiplicado por diez en complejidad? Quién sabe. A su entender, si se trata de un código heredado, la interfaz que se implementa una vez tiene poco valor, pero tampoco tiene sentido pasar por la refactorización necesaria para eliminarla. "Si funciona, no lo arregles".
Tidier, código menos confuso? ¿No es ese un punto de refactorización? – user343587
¿La interfaz sirve para organizar, documentar o identificar? Si es así, ¡déjalo en paz! Si solo está desordenado, entonces la refactorización podría estar en orden. –
No sé qué podría ser tan confuso. Tengo toneladas de interfaces de uso único en mi código. – jfar
Además de las razones dadas en las otras respuestas, solo la implementación de una interfaz permite interceptar métodos construyendo proxies sin usar instrumentación. Esto se usa para registrar, encapsular operaciones en una transacción, etc. Es utilizado por varios marcos.
Incluso si las personas no están de acuerdo con el número de errores por cada 1000 líneas de código, esas dos parecen correlacionadas (https://stackoverflow.com/questions/862277/what-is-the-industry-standard-for-bugs-per-1000-lines-of-code). Menos líneas == menos errores.
Además, cambiar el nombre de la implementación para el nombre de la interfaz debe ser todo lo que hay que hacer aquí.
Si el esfuerzo de refactorización es mínimo y reduce el código, prefiero la supresión de la interfaz.
Como mencionas una base madura, me gustaría mencionar otro ejemplo del mundo real: la sesión de Hibernate.
Session es una interfaz implementada solo por una clase: SessionImpl. Sin embargo, si usó hibernación en el pasado o leyó su código fuente, probablemente haya notado cómo se usa Session en todas partes, en lugar de SessionImpl.
¿Es este diseño incorrecto? Definitivamente no. Se llama 'El principio de sustitución', o 'programación hacia interfaces'. Significa que mediante el uso de la interfaz en lugar de la implementación, puede extender su código sin ningún esfuerzo, solo instanciando sus nuevas clases en consecuencia, pero siempre usando la interfaz. ¿Seguirá siendo incorrecto si nadie crea una nueva sesión de implementación de clase? No, todavía no está mal.
Mis dos centavos.
Además de las buenas respuestas ya proporcionadas, si en algún momento en el futuro una clase tiene que ser burlada para fines de prueba, ¡es mucho más fácil hacerlo cuando ya hay una interfaz disponible!
Yo diría que depende, pero en la mayoría de los casos una interfaz es una buena idea en ciertas clases. La burla se hace más fácil usando interfaces y cuando se usa un contenedor IoC, las interfaces comienzan a tener mucho sentido, especialmente cuando comienzas a implementar servicios compartidos en el contenedor. A continuación, podrá desacoplar la implementación del servicio de la clase que necesita el servicio.
Parece que necesita voltear una moneda :) –