Interfaces y versiones

Question

Estoy diseñando un nuevo sistema y tengo muchas interfaces que crecerán con el tiempo con el sistema.¿Cuál es la mejor práctica para nombrar estas interfaces?

ISomethingV01
ISomethingV02
etc

y hago esto

public interface ISomething{
      void method();
}

Entonces tengo que agregar el método 2. ¿Y ahora qué hago?

public interface ISomethingV2:ISomething{
      void method2();
}

o lo mismo de otra manera?

Answer 1

Idealmente, no deberías cambiar tus interfaces muy a menudo (si es que lo haces).Si necesita cambiar una interfaz, debe reconsiderar su propósito y ver si el nombre original todavía se aplica a ella.

Si todavía cree que las interfaces cambiarán, y los cambios en las interfaces son pequeños (agregar elementos) y tiene control de toda la base del código, entonces simplemente debe modificar la interfaz y corregir todos los errores de compilación.

Si su cambio es un cambio en cómo se usará la interfaz, entonces necesita crear una interfaz separada (probablemente con un nombre diferente) para admitir ese patrón de uso alternativo.

Incluso si terminas creando ISomething, ISomething2 e ISomething3, a los consumidores de tus interfaces les resultará difícil descubrir cuáles son las diferencias entre las interfaces.¿Cuándo deberían usar ISomething2 y cuándo deberían usar ISomething3?Luego hay que continuar con el proceso de obsolescencia de ISomething y ISomething2.

Answer 2

Creo que estás abusando de las interfaces.

Meyer y Martin nos dijeron:"¡Abierto para extensión pero cerrado para modificación!"

y luego Cwalina (et al) reiteró:

De las pautas de diseño del marco...

En general, las clases son la construcción preferida para exponer las abstracciones.El principal inconveniente de las interfaces es que son mucho menos flexibles que las clases cuando se trata de permitir la evolución de las API.Una vez que envía una interfaz, el conjunto de sus miembros se fija para siempre.Cualquier adición a la interfaz rompería los tipos existentes que implementan la interfaz.

Una clase ofrece mucha más flexibilidad.Puede agregar miembros a las clases que ya se han enviado.Mientras el método no sea abstracto (es decir, siempre que proporcione una implementación predeterminada del método), cualquier clases derivadas existentes continúa funcionando sin cambios.

Answer 3

estoy de acuerdo con Garo Yeriazarian, cambiar de interfaz es una decisión seria.Además, si desea promover el uso de la nueva versión de la interfaz, debe marcar la versión anterior como obsoleta.En .NET puedes agregar Atributo obsoleto.

Answer 4

El propósito de una interfaz es definir un patrón abstracto que el tipo debe implementar.

Sería mejor implementarlo como:

public interface ISomething

public class Something1 : ISomething
public class Something2 : ISomething

No se gana nada en forma de reutilización de código o diseño escalable al crear múltiples versiones de la misma interfaz.

Answer 5

No sé por qué la gente rechaza tu publicación.Creo que las buenas pautas para nombrar son muy importante.

Si necesita mantener la compatibilidad con el anterior.versión de la misma interfaz considere usar herencia.Si necesita introducir una nueva versión de la interfaz, considere la siguiente regla:

Intente agregar sufijo significativo a su interfaz.Si no es posible crear un nombre conciso, considere agregar el número de versión.