Antipatrones de desarrollo de software: Functional Decomposition

Este antipatrón, es bueno en un entorno de desarrollo procedural. Incluso resulta útil para comprender la naturaleza modular de una aplicación a gran escala.
Desafortunadamente, no se traslada directamente a una jerarquía de clases y aquí es donde comienza el problema.
El antipatrón es el resultado de experimentados desarrolladores, no orientados a objetos, quienes diseñan e implementan una aplicación en un lenguaje orientado a objetos. Cuando los desarrolladores están cómodos con una rutina "principal" que llama a numerosas subrutinas, pueden tener la tendencia de hacer todas subrutinas de una clase, ignorando por completo la jerarquía de clases (y practicamente ignorando por completo la orientación a objetos).
El código resultante se asemeja a un lenguaje estructural como pascal o FORTRAN en la estructura de una clase. Puede ser increíblemente complejo, como inteligentes desarrolladores procedurales idean formas muy inteligentes de replicar sus métodos probados en el tiempo en una arquitectura orientada a objetos.

Síntomas y consecuencias

• Clases con nombre de "funciones" como: Calcular_Interes o Mostrar_Tabla pueden indicar la existencia de este antipatrón.
• Una arquitectura increíblemente degenerada que pierde completamente el punto de una arquitectura orientada a objeto.
• Absolutamente ningún aprovechamiento de los principios de la orientación a objetos como la herencia o el polimorfismo. Esto puede ser extremadamente costoso de mantener (nunca se debe subestimar el ingenio de un programador de edad que poco a poco va perdiendo la carrera con la tecnología).
• No hay manera de documentar claramente (o explicar) cómo funciona el sistema. Los modelos de clase no tienen ningún sentido.
• No hay esperanzas de obtener jamás reutilización del software.
• Frustración y desesperación por parte de los testers.

Causas típicas

• La falta de entendimiento de la orientación a objetos. Los implementadores no la "comprenden". Esto es bastante común cuando los desarrolladores cambian de programar en un lenguaje que no es orientado a objetos a uno que sí lo es. Debido a que hay cambios en la arquitectura, diseño e implementación del paradigma, la orientación a objetos le puede tomar hasta tres años a una empresa para lograrlo plenamente.
• La falta de aplicación de la arquitectura. Cuando los implementadores no tienen ni idea sobre la orientación a objetos, no importa cuan bien diseñada esté la arquitectura; ellos simplemente no entienden lo que están haciendo. Y sin la supervisión adecuada, por lo general, encontrarán la manera de esquivar algo utilizando las técnicas que ellos conocen.
• Desastre específico. A veces, aquellos que generan las especificaciones y requerimientos, no necesariamente tienen verdadera experiencia con sistemas orientados a objetos. Si el sistema que se especifica asume compromisos arquitectónicos antes del análisis de los requisitos, puede, y a menudo la hace, llevar a antipatrones tales como Functional Decomposition.

Excepciones conocidas

Está bien visto cuando una solución que no sea orientada a objetos es necesaria. Esta excepción puede ser extendida para tratar con soluciones que son puramente funcionales en naturaleza, pero son envueltas (wrapped) para proporcionar una interfaz orientada a objetos al código de implementación.

Solución refactorizada

Si aun es posible determinar cuáles son los requisitos básicos para el software, definir un modelo de análisis para el mismo, para explicar las características críticas desde el punto de vista del usuario. Esto es esencial para descubrir la motivación subyacente para muchos de los fabricantes de software en una base de código en particular, la cual ha sido perdida en el tiempo. Para todos los pasos en la solución del antipatrón Functional Decomposition, proporciona documentación detallada de los procesos usados como base de los esfuerzos de mantenimientos futuros.
A continuación, formular un diseño que incorpore las piezas esenciales del sistema existente. Sin hacer foco en mejorar el diseño, pero si en establecer una base para explicar del sistema tanto como sea posible.
Idealmente, el diseño justifica, o al menos racionaliza, la mayoría de los módulos del software. Desarrollar un modelo de diseño para código existente es esclarecedor; proporciona una visión de cómo todo el sistema encaja. Es razonable esperar que muchas partes del sistema existen por razones desconocidas y para los cuales no hay especulaciones razonables que puedan intentarse.
Examinar el diseño y encontrar subsistemas familiares. Son candidatos a ser reusados. Como parte del mantenimiento del programa, se debe participar de la refactorización del código para reutilizar código entre subsistemas familiares.

Soluciones relacionadas

Si demasiado trabajo ya ha sido invertido en un sitema plagado por Functional Decomposition, aun se pueden salvar cosas mediante la adopción de un enfoque similar al enfoque alternativo abordado en el antipatrón The Blob.
En lugar de un refactoring de abajo hacia arriba de toda la jerarquía de clase, se podría extender la clase "rutina principal" hacia una clase "Coordinator" que gestione toda o la mayoría de la funcionalidad.
Las clases de funciones pueden ser acomodadas dentro de clases cuasi orientadas a objetos, combinándolas y reforzándolas para llevar a cabo su propio proceso en la dirección de la modificada clase Coordinator. Este proceso puede resultar en una jerarquía de clase que es más "trabajable".

Aplicabilidad a otros puntos de vista y escalas

Ambos puntos de vista, el arquitectónico y el administrativo, juegan un rol clave tanto en la prevención inicial como en la vigilancia contínua contra el antipatrón Functional Decomposition. Si una correcta arquitectura orientada a objetos fue planeada inicialmente y el problema ocurre en etapas de desarrollo, entonces el desafío es administrativo hacer cumplir la arquitectura inicial.
Igualmente, si la causa fue una falta general de una incorrecta arquitectura inicial, sigue siendo un reto administrativo el reconocer esto, activar los frenos y obtener ayuda de un arquitecto. Cuanto antes, más barato.

Por Juan Barrionuevo