Hemos estado allí: primero una simple bandera booleana, luego un if anidado. Parece inofensivo, pero pronto la base de código se convierte en un enredo de condicionales. La clase Door abre y cierra. Fácil, ¿verdad?
En producción, lo que parecía intuitivo empieza a oler raro. En cuanto añadimos una función como un cerrojo, el elegante objeto de dos estados se transforma en una maraña de lógica condicional.
El planteamiento inicial suele ser así: una clase Door con una propiedad booleana IsOpen que empieza en false; un método Open que establece IsOpen en true y muestra un mensaje en consola; y un método Close que la pone en false y también informa por consola. Directo y sencillo.
Ahora imagina que añadimos el estado bloqueado. Hay que declarar otra bandera booleana IsLocked, modificar Open para que solo funcione si no está bloqueada, y además crear métodos nuevos como Lock y Unlock. Cada incorporación añade más condicionales a cada método.
¿Y si aparece un estado Rota, o cambiamos a una puerta corredera o de persiana? Podemos seguir apilando booleanos, pero cada nueva variación obliga a tocar múltiples métodos y a sumar if y else por todas partes. No escala, es frágil y crea mucho código repetitivo.
Pros del enfoque con banderas: es rápido de implementar y no requiere dependencias ni abstracciones externas. Contras: acoplamiento fuerte porque toda la lógica vive dentro de un solo objeto, mucho boilerplate por los if y else en cada cambio de estado, difícil de escalar cuando llegan nuevas características y costoso de mantener a medio plazo.
La solución típica con máquinas de estados finitos propone crear clases de estado específicas, por ejemplo DoorOpenState, DoorClosedState y DoorLockedState, todas implementando la interfaz IState con un genérico de contexto. La clase Door mantiene una referencia al estado actual. Este patrón es bastante común en libros y tutoriales.
Pero añadir un estado locked ya no es solo sumar una bandera: hay que crear la nueva clase de estado, modificar otras para permitir transiciones, y ajustar el contexto. Sigue habiendo boilerplate y cambios invasivos.
Pros habituales de muchas implementaciones de FSM: separación limpia de estados al aislar su lógica, transiciones validadas por el propio modelo, patrón conocido y consolidado, posibilidad de FSM jerárquicas para reducir complejidad, e incluso árboles de comportamiento o enfoques híbridos. Contras frecuentes: boilerplate para estados, transiciones y orquestación, dependencia del framework o motor elegido, diseño rígido y poco flexible en tiempo de ejecución, FSM jerárquicas que pueden complicar el entendimiento y el debug, árboles de comportamiento que son excesivos para estados simples, y el patrón State que puede multiplicar clases y dificultar cambios.
Una alternativa mejor: FSM_API y estado centralizado. FSM_API es una aproximación pensada para ser muy rápida, agnóstica del software y totalmente desacoplada de la lógica de tu aplicación. Es declarativa y orientada a datos: defines tu FSM una vez y la reutilizas donde la necesites.
La idea clave es que FSM_API opera sobre objetos POCO que implementan una interfaz IStateContext. Así se separa nítidamente la lógica de estados de los datos de la aplicación.
Refactorizando nuestra puerta con FSM_API, el contexto Door se convierte en un POCO con propiedades como IsOpen, IsLocked, Name e IsValid. La lógica de abrir, cerrar, bloquear y desbloquear ya no vive en la clase, sino en las máquinas de estados que definimos alrededor.
La gran ventaja es que podemos montar varias FSM independientes sobre el mismo contexto. Por ejemplo, separar el comportamiento de abrir y cerrar del de bloquear y desbloquear. Definimos un DoorFSM con estados Closed y Open, establecemos el estado inicial en Closed y creamos transiciones: de Closed a Open con una condición que verifica que IsLocked sea false, de Open a Closed sin condiciones, e incluso transiciones entre Closed y Locked y de Locked de vuelta a Closed cuando corresponda. Todo esto sin tocar la clase Door.
Como FSM_API permite redefinir máquinas de estados en tiempo de ejecución, podemos añadir estados y transiciones dinámicamente sin recompilar. Esta capacidad es potentísima para sistemas muy configurables o que necesitan actualización en vivo.
Resumen de pros y contras de FSM_API. Pros: estado centralizado y lógica separada de los datos; extremadamente ligera, con un ensamblado central de apenas 45 kb y un paquete NuGet en torno a 417.09 kb; redefinición en tiempo de ejecución; diseño ligero y performante con mínimas asignaciones; agnóstica de framework; segura para hilos con mutaciones diferidas; y tolerante a errores con diagnósticos integrados. Contras: curva de aprendizaje si vienes de FSM tradicionales y un enfoque minimalista que te anima a apoyarte en la documentación y guías rápidas.
Esto es solo un vistazo de lo que permite FSM_API. Puedes revisar el paquete en NuGet y la documentación en el repositorio de GitHub para comenzar cuanto antes: Paquete en NuGet y Repositorio en GitHub.
En Q2BSTUDIO ayudamos a transformar toda esta teoría en soluciones de negocio reales. Somos una empresa de desarrollo con foco en software a medida y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud AWS y Azure, servicios de inteligencia de negocio y power bi, automatización de procesos, ia para empresas y agentes IA. Diseñamos arquitecturas basadas en máquinas de estados finitos que conviven con microservicios, pipelines de datos y modelos de IA para ofrecer sistemas robustos, escalables y seguros.
Si quieres llevar tus productos al siguiente nivel con FSMs bien diseñadas, integraciones cloud y modelos de IA, habla con nuestro equipo. Descubre cómo abordamos proyectos de software a medida en desarrollo de aplicaciones y software multiplataforma y cómo incorporamos IA de forma práctica en soluciones de inteligencia artificial para empresas. Juntos podemos crear la base de tu próxima generación de productos, cuidando la seguridad, el rendimiento y la mantenibilidad desde el primer día.