Fan-in (abanico de entrada) es un término utilizado en la Ingeniería del Software para referirse al número de clases que hacen uso de la clase que estamos estudiando. Por otro lado, fan-out (abanico de salida) hace referencia al número de clases que utiliza la clase que estamos estudiando. Estos conceptos, originarios de la electrónica digital, también pueden utilizarse en el resto de niveles del diseño conceptual, para hablar de subsistemas, paquetes o funciones.

Un buen diseño suele tener un fan-in alto, porque eso implica que estamos reutilizando código que de otra forma habría dado lugar a duplicidades en multitud de clases. El fan-in es una medida de reutilización.

Al contrario, un buen diseño cuenta con un fan-out bajo, idealmente de 7±2, que es, según George Miller, uno de los mayores exponentes de la psicología cognitiva, el número máximo de elementos que una persona normal puede almacenar en su memoria a corto plazo. Con un fan-out bajo nos aseguramos de que la clase es lo bastante sencilla para que no nos resulte difícil trabajar con ella. El fan-out es una medida de complejidad, muy relacionado con el Principio de Responsabilidad Única.

Los requisitos cambian. Es algo con lo que todos tenemos que lidiar cada día. De esto se desprende que, independientemente del tiempo que hayas invertido en la captura de requisitos y de las muchas funcionalidades extra que hayas podido implementar (en contra de lo que dicta YAGNI), tu aplicación va a tener que cambiar. Será mejor que estés preparado ello.

Una forma de estarlo es seguir los 5 principios básicos de la programación orientada a objetos, explicados en “Agile Software Development: Principles, Patterns, and Practices” por uno de los grandes exponentes de la artesanía del software, el famoso “Uncle Bob” (Robert C. Martin)

[Pulsa para continuar]