Beyond Objects
Este artículo sostiene que el principio central de la orientación a objetos de mapear la funcionalidad del sistema directamente a los individuos del dominio del problema es inherentemente defectuoso y conduce a la fragmentación, proponiendo en su lugar abandonar la orientación a objetos en favor de un enfoque que desacople los individuos del dominio de los módulos funcionales.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
La Gran Idea: El error de "Talla Única para Todos"
Imagina que estás construyendo una casa. Durante los últimos 50 años, la regla estándar en la construcción de software ha sido: "Cada habitación de la casa debe ser gestionada por la persona que vive allí".
En el mundo del software, esto se llama Programación Orientada a Objetos (POO). La idea es que si tienes un "Usuario" en el mundo real, creas un "Objeto Usuario" en el código. Se supone que ese objeto debe contener todos los datos sobre ese usuario (su nombre, su contraseña) y realizar todo el trabajo relacionado con él (iniciar sesión, escribir reseñas, reservar mesas).
Daniel Jackson sostiene que esta regla es una trampa. Suena lógico, pero en la práctica, obliga al software a convertirse en un caos enredado. Él sugiere que dejemos de intentar meter cada trabajo dentro de la "persona" y, en su lugar, organicemos el software según lo que está sucediendo (las acciones), no según quién lo está haciendo (los individuos).
El Problema: La "Navaja Suiza" vs. la "Herramienta Especializada"
Jackson dice que forzar cada tarea sobre un único "Objeto Usuario" causa dos dolores de cabeza principales:
1. El problema de la "Navaja Suiza" (Conflación)
Imagina que un Objeto Usuario es una navaja suiza. Tiene una hoja, un destornillador, un sacacorchos y un palillo de dientes.
- El problema: Si quieres usar el sacacorchos (para gestionar la contraseña de un usuario), tienes que cargar con toda la pesada navaja. Si quieres cambiar la hoja (corregir un error en el sistema de reseñas), podrías romper accidentalmente el sacacorchos.
- En el software: Un objeto "Usuario" termina conteniendo la contraseña del usuario, su historial de reseñas, sus ajustes de notificación y su lógica de reservas, todo en un solo archivo gigante. Si quieres cambiar cómo funcionan las reseñas, tienes que buscar entre el código de las contraseñas. Es desordenado y difícil de arreglar.
2. El problema de "Demasiadas Manos" (Fragmentación)
Imagina una tarea como "Reservar una mesa".
- El problema: ¿Quién debe hacerlo? ¿El Usuario? ¿El Restaurante? ¿La Mesa? ¿La Reserva?
- En el software: Debido a que la regla dice "asigna el trabajo al objeto", el código se divide. El "Usuario" comprueba si tiene una reserva. El "Restaurante" comprueba si la mesa está libre. El objeto "Reserva" crea el ticket.
- El resultado: Para hacer una sola reserva, la computadora tiene que poner a correr a tres personas diferentes en tres habitaciones distintas y hacer que hablen entre sí. Si una persona olvida decirle algo a la otra, el sistema se rompe. Esto se llama fragmentación.
La Analogía: La Reserva de un Restaurante
Jackson utiliza un restaurante para explicar esto.
La Forma Antigua (Orientada a Objetos):
Tienes un objeto "Usuario" y un objeto "Restaurante".
- Cuando Alice quiere reservar una mesa, le pregunta a su objeto "Usuario".
- El objeto Usuario le pregunta al objeto "Restaurante" si hay una mesa libre.
- El objeto Restaurante le pregunta al objeto "Slot" (Espacio/Turno).
- Se crea el objeto "Reserva".
- El desorden: Si quieres cambiar la regla para que "Alice no pueda reservar dos mesas a la vez", tienes que actualizar el objeto Usuario, el objeto Restaurante y el objeto Reserva. Todos están enredados entre sí.
La Nueva Forma (Conceptos):
En lugar de preguntar "¿Quién es el dueño de esto?", preguntamos "¿De qué es este grupo de reglas?".
Jackson propone organizar el software en Conceptos. Piensa en un Concepto como un equipo especializado o un departamento en una empresa, en lugar de una persona.
- Concepto 1: "Reservar"
- Este equipo maneja todas las reglas sobre hacer compromisos. No le importa quién sea el usuario; solo le importa el acto de reservar. Contiene la lista de quién reservó qué.
- Concepto 2: "Disponibilidad"
- Este equipo maneja el acto de comprobar si un espacio está abierto. No le importa quién esté reservando; solo le importan los espacios/turnos.
- Concepto 3: "Autenticación de Usuario"
- Este equipo solo comprueba si la persona es quien dice ser.
Cómo trabajan juntos:
En lugar de que el objeto Usuario llame al objeto Restaurante, estos "Conceptos" se comunican a través de Sincronizaciones (como un semáforo).
- Regla: "Cuando llega una Solicitud, comprueba si la Disponibilidad dice 'Sí', y si la Autenticación dice 'Adelante', entonces Reservar puede realizar la reserva".
Por qué esto es mejor
- Sin nudos enredados: El equipo de "Reservar" no necesita saber cómo comprobar una contraseña. El equipo de "Autenticación" no necesita saber cómo comprobar una mesa. Son separados.
- Sin discusiones de "¿Quién es el dueño de esto?": No tienes que discutir si el botón de "cancelar" pertenece al Usuario o a la Reserva. Simplemente pones la lógica de "cancelar" en el Concepto que gestiona el estado de la reserva.
- Mapas más claros: Si miras el código, ves las reglas de negocio (Reservar, Disponibilidad) claramente, en lugar de un mapa confuso de quién es dueño de qué datos.
El "Concepto" frente al "Objeto"
- Objeto: Una pequeña máquina que intenta serlo todo (Datos + Lógica + Identidad). Es como una persona intentando ser chef, camarero y cajero al mismo tiempo.
- Concepto: Un módulo que maneja un trabajo o relación específica. Es como un departamento especializado. El "Departamento de Cocina" se encarga de cocinar; el "Departamento de Camareros" se encarga de servir. Se coordinan, pero no se fusionan en una sola persona.
La Conclusión
Jackson no dice que debamos desechar todo el software. Dice que la regla central de la Programación Orientada a Objetos —"Asigna cada trabajo a la persona a la que pertenece"— es la raíz del problema.
Al cambiar a los Conceptos, dejamos de intentar forzar al software a parecer una colección de personas. En su lugar, lo organizamos como una colección de reglas y relaciones. Esto hace que el código sea más fácil de leer, más fácil de arreglar y menos propenso a romperse cuando intentas cambiar una pequeña cosa.
Es un retorno a una forma de pensar más antigua y simple (como las bases de datos relacionales) pero actualizada para las necesidades del software moderno, permitiéndonos construir sistemas que sean menos frágiles y más lógicos.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.