design - rapidweaver - Interfaces y control de versiones

replica set example

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 la misma otra forma?

Answer 1

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

Sería mejor implementarlo como:

public interface ISomething

public class Something1 : ISomething
public class Something2 : ISomething

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

Answer 2

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

Si aún sientes que las interfaces cambiarán, y los cambios de las interfaces son pequeños (agregando elementos) y tienes el control de toda la base de códigos, entonces solo debes modificar la interfaz y corregir todos los errores de compilación.

Si su cambio es un cambio en la forma en que se utilizará la interfaz, entonces necesita crear una interfaz separada (muy probablemente con un nombre diferente) para respaldar ese patrón de uso alternativo.

Incluso si termina creando ISomething, ISomething2 y ISomething3, los consumidores de sus interfaces tendrán dificultades para descubrir cuáles son las diferencias entre las interfaces. ¿Cuándo deberían usar ISomething2 y cuándo deberían usar ISomething3? Luego tienes que seguir el proceso de obsolescencia de ISomething e ISomething2.

Answer 3

No sé por qué las personas rechazaron su publicación. Creo que las buenas pautas para el nombramiento son muy importantes.

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

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

Answer 4

Creo que estás sobrepasando las interfaces.

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

y luego Cwalina (et al) reiteró:

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

En general, las clases son la construcción preferida para exponer 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 han enviado. Siempre que el método no sea abstracto (es decir, siempre que proporcione una implementación predeterminada del método), las clases derivadas existentes seguirán funcionando sin cambios.

Answer 5

Estoy de acuerdo con Garo Yeriazarian , cambiar la 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 puede agregar ObsoleteAttribute .