Principios de diseño: fan-in y fan-out

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.

18 comentarios en «Principios de diseño: fan-in y fan-out»

  1. Que decir.. muy interesantes tus entradas sobre ingenieria del software.. te agradezco y te animo a que las sigas publicando.. gracias.

  2. O soy yo, o es la ingeniería de software la que falla…
    En la oficina hay alguien que se conoce todos los paradigmas y modelos, que este controlador, este es nuevo y utiliza la inversion del controlador, framework para esto, para aquello, y luego estamos los pica código, ese tipo de gente que somos depuradores humanos, pasamos 1 hora continua en un estado de cuasi nirvana viendo la pantalla y almacenando en las neuronas el estado de cada objeto. jaja Muy bueno el post me debo amigar con lo abstracto.

  3. Yo acabo teniendo un lío tremendo, y es que, de tanto modular, encapsular, etcétera termino teniendo fan-in alto, pero a su vez, el fan-out también me crece. Voy «troceando» tanto las cosas que al final es lo que me pasa, que para hacer ‘x’ consulta tengo que instanciar objetos, o para realizar otra operación, otro objeto de otra clase distinta. Y así sucesivamente.

    Igual mi contexto es peculiar, distintas empresas, distintos perfiles, distintas consultas, MISMOS MÓDULOS ¡taaaaacháááááááán!.

    Y lo del fan-out me molesta mucho, me genera muchas dependencias que tengo que cargar y las que ellas tengan a su vez. De momento está dentro de lo ideal 7+-2, porque va con 6 para la clase que más objetos utiliza internamente. Pero claro, como he dicho, estas también tienen dependencias.

    ¿Tiene solución? 😉

      1. Mmm… me he explicado mal. No me refiero a tener que modificar la clase, sino que, por hacer la descomposición de las acciones las voy delegando en distintas clases. Aunque, teniendo en cuenta que aquello que puede realizar un usuario nunca es inmutable…

        No busco la solución a esto, ya la tengo desarrollada, aunque estoy trabajando en ella para mejorarla (es un cambio de arquitectura brutal la que estoy haciéndole al portal) 😉 -> El problema es que, hay que dar solución al acceso a un mismo portal sea utilizado por distintas empresas, que a su vez tendrán distintos perfiles de usuario y en función de este perfil tendrán una consulta para búsquedas distinta de otros, una sentencia de alta de registros también distinta, etc.

        Mi problema es que creo que estoy cometiendo algún fallo al realizar la descomposición de las cosas, lo cuál hace que comience a tener un fan-out
        Esto hace que tenga que ir «encapsulando» en clases estas sentencias sql: sql para incidencias, sql para inventario, para xxx…

        Por ejemplo, ¿qué sería más adecuado?:

        a)Tener todas las sentencias sql de un mismo perfil de usuario en la misma clase, aunque esta pueda ser monstruosa.

        b)Tener en diferentes clases las sentencias sql de un mismo perfil debido a que, para poder formar esa sentencia, hay que ir creando dinámicamente los filtros.

        Hay que tener en cuenta que la clase «BusquedaIncidencia» tiene cerca de 360 lineas, la clase «AltaIncidencia» tiene cerca de 185 lineas, etc. Todas estas parten a su vez de otras clases abstractas y esto en PHP hace que al final tenga que cargar un montón de clases: ¡Horror!

        Menudo rollo que acabo de soltar 😉

        1. ¿Para cuándo el botón editar? jajaja 🙁 Sí, lo sé, debía haber repasado una y otra vez el texto.

          Quería poner esto:
          Mi problema es que creo que estoy cometiendo algún fallo al realizar la descomposición de las cosas, lo cuál hace que comience a tener un fan-out alto (6) al ir “encapsulando” en clases estas sentencias sql: sql para incidencias, sql para inventario, sql para xxx…

          1. ¿Estás usando MVC y una clase DAO por cada clase de dominio? ¿y el problema es que una acción del controlador tiene que operar sobre todas estas clases de dominio y sus DAOs?

  4. Una preguntica rápida, ¿no conocerás alguna herramienta de análisis que compute estos valores de forma automatizada? Tengo curiosidad por aplicar la valoración a mis proyectos, pero calcular a mano me da pereza 🙂

    Y gracias por la info, no lo conocía

    1. Depende del lenguaje que estés utilizando. Si buscas en Google «software metrics» seguro que aparece algo. Por ejemplo, checkstyle.

      De todas formas, lo que se lleva ahora es utilizar herramientas de integración contínua, como Jenkins, no usar montones de pequeñas herramientas de forma separada.

  5. Utilizaste el mismo concepto para definiar Fan-in y Fan-out??? (para referirse al numero de clases que hacen uso de la clase que estamos estudiando)
    Nadie se ha dado cuenta de eso?????

    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.

    ??????????????

Responder a Zootropo Cancelar respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.