¿Es útil mi interfaz?

Empecemos por ver la definición de interfaz, que aunque es muy antigua, contiene mucha influencia en la programación «moderna» (IoC, DI, TDD, APIs, etc.) “Una interfaz es un contrato donde se especifican todos los términos y especificaciones que se deben cumplir para realizar y concretar algo”.

Olvidemos por un momento que hablamos de una interfaz y resaltemos algunas palabras claves en esta definición:

– Contrato
– Términos
– Especificaciones
– Cumplir
– Concretar

El contrato contiene términos y especificaciones, quien lo firme, las tendrá que cumplir y concretar. Un contrato podrá cambiar en el tiempo, pero será un cambio demandado y acordado por ambas partes y siempre se deberá entender como una evolución del mismo.

Volvamos a la interfaz e imaginemos la siguiente situación:

Día 1:
public interface IA
{
void M1();
}

Día 2:
public interface IA
{
void M1(int p1);
}

Día 3:
public interface IA
{
void M1(int p1, int p2);
}

Día 4:
public interface IA
{
int M1(int p1, int p2);
}

Se ha definido una interfaz porque necesitamos que todo aquel que la implemente, cumpla con todos sus términos y especificaciones. El problema aquí es que día tras día esta interfaz ha sufrido modificaciones que implican un cambio del contrato.

Esto por muchos motivos “obvios” no es bueno y las dos razones principales por lo que esto sucede son:

1- No tenemos claro los términos y a medida que vamos desarrollando nos damos cuenta de que tenemos que cambiarlos
2- No hemos recibido las especificaciones que dicho contrato debe cubrir y durante el proceso de desarrollo nos van cambiando.

¿Esto quiere decir que tengo que tener en mi cabeza todos los términos y especificaciones antes de escribir mi contrato? NO. Al principio comentamos que una interfaz puede cambiar, y un ejemplo claro es cuando ampliamos los términos para cubrir más especificaciones.

public interface IA
{
void M1();
}

Si necesitamos ampliar las especificaciones de esta interfaz, modificar la misma sería un error, ya que obligamos a que todos los firmantes tengan que cambiar para soportar las nuevas especificaciones. En este caso lo más correcto sería no afectar a quienes ya implementan esta interfaz y crear las nuevas especificaciones en una nueva interfaz que herede de la ya definida.

public interface IAA : IA
{
void M2(int p1, int p2);
}

La interfaz en un API 🙂

La documentación de un API es un contrato que contiene términos y especificaciones inviolables si no se quiere afectar a quienes nos consumen. Sería un error que con la documentación de un API ocurra lo mismo que con la interfaz IA, y esta cambie constantemente. Las causas son exactamente las mismas: no tenemos claro el flujo lógico de nuestra API y los términos cambian constantemente o, las especificaciones nos llegan a cuenta gotas.

Para decir que estamos listos para escribir la interfaz IA o la documentación de un API, hay que tener claro los términos de la mínima unidad funcional que vamos a llevar a cabo. No tiene que ser toda la lógica, ni siquiera tiene por qué ser la mitad o un tercio, simplemente tiene que ser lo mínimo necesario para que aquello que vamos a desarrollar, podamos plasmarlo en la interfaz o en la documentación.

¿Y cuando quiera ampliar las especificaciones en el caso de un API? Aquí es donde entra el versionado, que irá cambiando en cada modificación del contrato. El versionado de un API no es algo que se tiene en cuenta una vez puesta en producción, sino que va unido a cada paso que da el equipo durante el tiempo de desarrollo.

Imaginemos por último que además de modificar constantemente un contrato, no avisamos a los firmantes. Así, te enteras luego de una semana o un mes, que has estado trabajando por mucho menos de lo pactado o que tu hipoteca se ha incrementado en un 500%… ¿un caos verdad? ¿Qué pensarías de tu empresa o banco? ¿Qué pensarías del equipo que desarrolla la interfaz o el API?

Saludos

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *