Datos, contexto e interacción

Datos, contexto e interacción ( DCI ) es un paradigma utilizado en el software informático para programar sistemas de objetos que se comunican . Sus objetivos son:

• Mejorar la legibilidad del código orientado a objetos otorgando al comportamiento del sistema un estatus de primera clase;
• Separar claramente el código para el comportamiento del sistema que cambia rápidamente (lo que hace un sistema ) frente al conocimiento del dominio que cambia lentamente (lo que es un sistema ), en lugar de combinar ambos en una única interfaz de clase;
• Para ayudar a los desarrolladores de software a razonar sobre el estado y el comportamiento a nivel de sistema en lugar de solo sobre el estado y el comportamiento de los objetos;
• El objetivo es fomentar un estilo de pensamiento orientado a objetos que se acerque a los modelos mentales de los programadores, en lugar del estilo de pensamiento basado en clases que eclipsó el pensamiento orientado a objetos en los inicios de los lenguajes de programación orientados a objetos.

El paradigma separa el modelo de dominio (datos) de los casos de uso (contexto) y los roles que desempeñan los objetos (interacción). DCI es complementario al modelo-vista-controlador (MVC). MVC, como lenguaje de patrones ^{[ 1 ],} todavía se utiliza para separar los datos y su procesamiento de la presentación.

DCI limita todas las redes permisibles de objetos comunicantes a redes que comparten topologías comunes, una para cada caso de uso. ^{[ 10 ] [ 4 ]} Dichas redes son explícitas en las interacciones entre los roles de DCI, mientras que en la orientación a objetos clásica son emergentes. Un rol es un nodo en dicha topología; es una clasificación parcial de los comportamientos de todos los objetos que pueden ocupar este nodo. La topología es una descripción de la estructura en tiempo de ejecución de un sistema. ^{[ 11 ]}

Un programa orientado a objetos es una red compleja y dinámica de objetos, del mismo modo que las relaciones entre objetos del mundo real son complejas y dinámicas. Consideremos a un camarero en un restaurante. El camarero en sí es un objeto complejo que puede verse de muchas maneras: como mi camarero (por ejemplo, quien describe el menú de esta noche y toma mi pedido), como empleado del restaurante (con un salario y un horario de trabajo determinados) y como persona en el restaurante (que tiene un aforo limitado a 150 personas). Si se escribiera una clase `Camarero` para capturar la esencia del mundo real de los camareros (que es de lo que trata realmente la orientación a objetos), tendría que ser muy compleja para soportar todas estas perspectivas.

En DCI, estas diferentes perspectivas se incorporan a los Roles. En tiempo de ejecución, el Rol es la identidad del objeto. ^{[ 6 ]} Durante la ejecución de un caso de uso (como Servir el vino ), el Rol Camarero identifica inequívocamente un único objeto en cualquier momento dado. ^{[ 5 ]} Podría argumentarse que puede haber varios Camareros en la mesa. Sin embargo, es probable que difieran en sus responsabilidades dentro de un caso de uso , como se encuentra en los nombres de Rol Jefe de Camareros y Ayudante de Camarero. Incluso si sus responsabilidades son idénticas, aún se describirían como Camarero-1 y Camarero-2, o como elementos individuales (nombrados) de un vector de Camareros, si alguien pretendiera escribir software para ellos. Así, un Rol como Jefe de Camareros se convierte en el identificador, el manejador, mediante el cual los objetos se refieren entre sí en un caso de uso .

DCI reconoce al Camarero como un objeto en lugar de, por ejemplo, una composición de una parte de Empleado, una parte de Camarero y una parte de Persona. El objeto tiene su propia identidad independiente del caso de uso ; esta es la faceta de Datos de DCI. Los Roles son nombres alternativos para sus objetos, pero nunca son objetos separados en sí mismos; eso causaría una auto-esquizofrenia . En este sentido, cada Camarero es un homo sapiens . Esta es la parte rudimentaria de qué es el sistema del Camarero. El objeto tiene muchas identidades posibles dependiendo del caso de uso en el que esté involucrado; esto se manifiesta en las identidades de Role que forman parte de la faceta de Interacción de DCI. Esta es la parte (generalmente más interesante) de qué hace el sistema. Sin embargo, en DCI, solo hay un objeto que lleva ambas perspectivas en tiempo de ejecución. Estas perspectivas pueden agruparse de manera diferente en tiempo de codificación. El código está dominado por la estructura del caso de uso , que atraviesa los objetos y que también forma parte de la faceta de Interacción de DCI.

DCI permite que un objeto asuma uno o más Roles durante la ejecución de un caso de uso . En otras palabras, un objeto se vuelve a vincular a identificadores de Rol en cada ejecución del caso de uso . ^{[ 5 ]} Estos Roles infieren una interfaz, denominada tipo de Rol. Cada objeto se "reconfigura" (en el sentido teatral) de nuevo en cada caso de uso . Aunque un Rol está vinculado solo a un único objeto, un objeto puede desempeñar varios Roles. Por ejemplo, un Jefe de Camareros puede participar en un caso de uso para contar a todos los ocupantes del restaurante durante una inspección de incendios, y desempeñará el Rol de Persona así como el Rol de Jefe de Camareros. El único objeto admite los comportamientos de ambos Roles necesarios para llevar a cabo el caso de uso .

En resumen, las arquitecturas DCI tienden a caracterizarse por las siguientes propiedades: ^{[ 2 ] [ 11 ]}

• El modelo de datos refleja la estructura del dominio en lugar de particiones de su comportamiento;
• Los objetos asumen roles de forma dinámica durante la ejecución de los casos de uso ;
• Cada función de un caso de uso es desempeñada por un objeto determinado por el contexto al inicio de la ejecución del caso de uso ;
• La red de interacciones entre roles en el código (es decir, en tiempo de codificación) es la misma que la red correspondiente de objetos en tiempo de ejecución;
• Estas redes pueden recrearse en cada ejecución de un caso de uso ;
• Los roles entran y salen del ámbito de aplicación según la duración de los casos de uso , pero los objetos que pueden desempeñar estos roles pueden persistir a lo largo de múltiples ciclos de vida de casos de uso y potencialmente desempeñar muchos roles a lo largo de su propia vida útil.

DCI puede considerarse un paradigma de programación orientado a eventos , donde algún evento (como un gesto humano en una arquitectura modelo-vista-controlador (MVC)) desencadena un caso de uso . ^{[ 4 ]} El caso de uso puede ser de corta o larga duración. Los eventos se denominan disparadores y se gestionan en el entorno en el que se integra DCI. Este entorno puede ser el controlador de una arquitectura MVC convencional o cualquier otro código a nivel de sistema.

El disparador hace que el entorno cree una instancia de un objeto de contexto . El tipo de objeto se elige según el tipo de caso de uso que se vaya a producir, basándose en la información sobre el disparador, el estado del sistema o ambos. Por ejemplo, un cajero automático podría tener clases de contexto separadas para transferencia de dinero, retiro, depósito, consulta de saldo, etc. Una vez que el entorno crea la instancia del objeto de contexto, invoca su método de disparador para iniciar la ejecución del caso de uso. ^{[ 5 ]}

Como se describió anteriormente, cada Contexto proporciona un alcance de diseño para los Roles que participan en la ejecución del caso de uso . Es tarea del Contexto asignar objetos para desempeñar estos Roles. ^{[ 6 ]}

1. El Contexto primero identifica los objetos que participarán en la ejecución de este caso de uso . Estos objetos pueden estar en cualquier parte del entorno, en una base de datos o crearse sobre la marcha; DCI no impone restricciones a estos objetos. Dentro de un Contexto, existe como máximo una instancia que desempeña un rol determinado en un momento dado.
2. En segundo lugar, el Contexto asigna un único objeto para desempeñar cada uno de sus Roles (aunque un solo objeto suele desempeñar varios Roles en un mismo Contexto). En lenguajes fuertemente dinámicos (Ruby, Python), el Contexto inyecta los métodos Role en el objeto. En la mayoría de los lenguajes dinámicos, se puede pedir a cualquier objeto existente que desempeñe cualquier Role en cualquier momento (aunque algunas combinaciones objeto-Rol pueden, por supuesto, carecer de sentido; combinaciones sin sentido de objetos y Roles darían lugar a errores MESSAGE NOT UNDERSTOODen tiempo de ejecución si se invocara el método Role). En lenguajes con tipado más estático (Scala, C++), debe haber existido algún arreglo previo para que el objeto admita los métodos Role. Por ejemplo, Scala crea una clase anónima que combina la lógica rudimentaria de una clase de dominio con la lógica del caso de uso del rasgo utilizado para implementar un Role; los Roles se asignan efectivamente a los objetos de dominio cuando se instancian.
3. En tercer lugar, el Contexto invoca un método Role en el primer objeto que participa en el caso de uso .
4. A partir de ese momento, los roles invocan los métodos de los demás para ejecutar el caso de uso . Un método de rol puede invocar un método selfque, de hecho, es gestionado por el objeto que actualmente desempeña dicho rol. Así es como los roles invocan las operaciones de datos básicas de los objetos que los desempeñan en ese momento.

DCI depende de un proceso de diseño que separa los casos de uso del modelo de datos. El modelo de datos suele basarse en un análisis de dominio informal . Los roles que caracterizan el modelo de funcionalidad del sistema del usuario final provienen de los casos de uso . ^{[ 4 ]}

Las técnicas de implementación difieren entre los lenguajes de programación. Lo que tienen en común muchos enfoques es que los roles se representan mediante construcciones como genéricos, plantillas, clases o rasgos . El código para la lógica básica del dominio se implementa por separado, siguiendo la práctica convencional de la programación orientada a objetos y, por lo general, utilizando clases. El código de cada rol se inyecta en el objeto de dominio que lo ejecutará durante la ejecución del caso de uso . Para implementar roles , normalmente se necesita la inyección de métodos . Los rasgos son una técnica común en los lenguajes de programación para admitir la inyección de métodos . Algunos lenguajes, como Scala , tienen soporte nativo para rasgos , mientras que otros (por ejemplo, Ruby y Python ) permiten la inyección de métodos en tiempo de ejecución. En Java , se necesitan trucos de precompilación basados ​​en anotaciones para admitir DCI. Haxe utiliza su característica de macro en tiempo de compilación para transformar la semántica de DCI en código del lenguaje de destino.

En el sitio web fulloo.info , mantenido por los creadores de DCI, existen varios ejemplos de implementación.

DCI fue inventado por Trygve Reenskaug , también inventor de MVC. La formulación actual de DCI es principalmente obra de Reenskaug y James O. Coplien . ^{[ 2 ] [ 4 ] [ 10 ]}

DCI surgió en gran medida como resultado del trabajo de Trygve Reenskaug sobre el modelado basado en roles. ^{[ 12 ]} Trygve había reconocido desde hacía tiempo que los roles desempeñaban un papel central en la forma en que los programadores piensan sobre los objetos, y que la progresión basada en clases de la tecnología de los lenguajes de programación eliminó gran parte de la motivación para pensar en los objetos de un programa. Esto, a su vez, dificultó el razonamiento sobre el programa en tiempo de ejecución. Además, el hecho de que los lenguajes de programación orientados a objetos solo ofrecieran clases para expresar la lógica del programa dejó al programador a merced de la estructura de los datos para delimitar el comportamiento, lo cual es antinatural en comparación con la delimitación del comportamiento en los límites de los roles. Esto, a su vez, hizo que el comportamiento del programa fuera más difícil de razonar que en, por ejemplo, un programa procedimental en Fortran .

Trygve consideró importante crear estructuras de programas sobre las que se pudiera razonar, y comenzó a compartir estas ideas ya en el año 2000. Para 2006, tenía un modelo de diseño funcional, y su descubrimiento en 2008 del trabajo de Schärli sobre Traits proporcionó la piedra angular que daría lugar a una expresión natural de estas ideas en el lenguaje de programación. Prototipó las ideas en el entorno de programación Baby, escrito en Squeak. James Coplien se unió a Trygve en este esfuerzo alrededor de 2007 y, a mediados de 2008, tenía un prototipo funcionando en C++ . Steen Lehmann, Rickard Öberg y Niclas Hedhman aceleraron la adaptación de estas ideas a Ruby y Java durante el año siguiente con el framework Qi4j. ^{[ 9 ]} Muchas adaptaciones adicionales de lenguajes surgieron tras una sesión en la conferencia JaOO en Dinamarca en septiembre de 2008. En 2010, Rune Lund-Søltoft creó el lenguaje Marvin. Fue el primer lenguaje construido con soporte nativo para DCI. Marvin se concibió principalmente como una prueba de concepto para demostrar la idea de la "intervención de datos en el dominio sin inyección". La mayoría de las implementaciones anteriores modificaban los objetos del jugador de rol de forma que resultaran visibles fuera del contexto. James Coplien creó el lenguaje trygve basándose en la misma idea; fue el primer lenguaje desarrollado desde cero para soportar la interacción de datos en el dominio.

Los distintos enfoques adoptados para la evolución de la programación orientada a objetos, tanto a nivel de lenguaje como de patrones , coinciden en diversos grados con DCI:

• Los mixins son una forma de encapsular código para funcionalidades específicas del sistema de manera cerrada; sin embargo, no existe un mecanismo consistente para vincular varios mixins en una unidad a nivel de caso de uso . Se pueden emplear para implementar el concepto de rol en DCI, aunque no en un sentido estricto.
• El despacho múltiple fue un intento inicial de separar completamente un algoritmo de los objetos involucrados en su ejecución, lo cual se complementa con la separación que DCI ofrece entre algoritmos recurrentes comunes y fragmentos de código que pueden ubicarse individualmente en objetos específicos. Conceptualmente, DCI permite una mayor reutilización de un único algoritmo en forma cerrada en diversos conjuntos de objetos de tipos muy heterogéneos. El objeto Contexto de DCI actúa como un despachador explícito e inteligente, análogo a los mecanismos de despacho de lenguajes con despacho múltiple.
• Los lenguajes de programación verdaderamente orientados a objetos, como Self, intentan romper la dicotomía entre los dominios de la programación con clases y la ejecución orientada a objetos, lo que ayuda a los programadores a centrarse en los objetos en tiempo de ejecución. DCI restaura el conocimiento a nivel de código sobre las relaciones entre ellos en Contextos y en las relaciones estáticas entre los métodos Role. ^{[ 2 ]}
• La inyección de dependencias es un enfoque de larga data para cambiar la funcionalidad de un objeto en tiempo de ejecución, permitiéndole "externalizar" parte de su ejecución a un objeto externo que puede ser reasignado a voluntad. La mayoría de las implementaciones de inyección de dependencias conducen al problema de la auto-esquizofrenia , ^{[ 13 ]} que las implementaciones de DCI abordan adecuadamente. Sistemas como Elmo utilizan este enfoque, lo que añade complejidad para resolver la ambigüedad de métodos y los nombres duplicados de miembros de datos. ^{[ 14 ]}
• El diseño multiparadigma ^{[ 15 ]} intenta separar el comportamiento y la estructura asignando el comportamiento a un diseño procedimental y el componente estructural a objetos, permitiendo el libre acceso entre ellos, de acuerdo con los principios de diseño de C++. El enfoque DCI puede mejorar la expresión de la relación entre las partes procedimentales y estructurales del diseño y la cohesión general. ^{[ 16 ]}

Los retos de la programación orientada a objetos también pueden superarse abordando sus problemas a nivel de paradigma.

• La programación orientada a aspectos (POA) es quizás el pariente histórico más cercano de DCI. La mayor parte del uso de aspectos está estrechamente ligado a la perspectiva del programador y requiere un sólido soporte de herramientas para proporcionar una buena comprensión del comportamiento del software en cualquier punto de corte dado . La principal diferencia es que en DCI, la estructura del algoritmo es primordial, con un fuerte énfasis en su aislamiento del código externo, lo que mejora la legibilidad del código. En POA, el punto de corte y el consejo tienen la misma importancia y, aunque físicamente separados, deben entenderse juntos para entender el código, porque el consejo es invasivo en el punto de corte . Mientras que POA proporciona una agrupación administrativa de una colección relacionada de modificaciones locales individuales que, en conjunto, atraviesan la estructura primaria del código, DCI es una expresión semántica de un algoritmo con estatus de análisis de primera clase que invoca métodos de objetos existentes. DCI puede pensarse como una forma de tomar un consejo extenso y permitir que partes de él se inyecten en una serie de puntos de corte regularizados .
• La programación orientada a roles reúne ideas de la programación orientada a aspectos , el modelado conceptual ^{[ 17 ]} y más. Los primeros intentos (1991) definieron los roles de forma independiente, ^{[ 18 ]} pero los enfoques más recientes (2002 en adelante) convergen en enfatizar que los roles dependen del contexto (también "equipos" ^{[ 19 ]} o "instituciones" ^{[ 20 ]} ). En la programación orientada a roles, los roles se definen con respecto a alguna entidad intrínseca (o base), que corresponde a la dicotomía datos-roles en DCI. El concepto de contexto es esencialmente el mismo en ambos enfoques. Ambos enfoques enfatizan la interacción entre un grupo de roles.

Se pueden identificar varias diferencias. La programación orientada a roles se centra en añadir soporte para roles a los lenguajes de programación orientados a objetos , haciendo hincapié en aumentar la expresividad del lenguaje y permitir más diseños. En comparación, DCI se centra más en el método de captura de modelos mentales, definiendo este método, en parte, como restricciones sobre lo que se considera un diseño válido en DCI. Por ejemplo: los autores de DCI tienden a desaconsejar el uso de la herencia (p. ej., «en DCI no se heredan roles» ^{[ 21 ]} ), mientras que la programación orientada a roles adopta (e incluso mejora) la herencia como concepto central de la programación orientada a objetos, permitiendo la combinación libre con otros conceptos. DCI enfatiza que debe evitarse la « esquizofrenia del yo» , mientras que la programación orientada a roles afirmaba gestionar los objetos divididos de tal manera que la esquizofrenia dejara de ser un problema ^{[ 22 ]} y se convirtiera en un facilitador de diseños más flexibles. Un artículo posterior de los autores de DCI afirma que la auto-esquizofrenia sigue siendo un problema en la programación orientada a roles, utilizando un contraejemplo basado en una implementación modificada del algoritmo de Dijkstra . ^{[ 23 ]} De este modo, DCI sacrifica las ventajas de la herencia para evitar por completo sus deficiencias, mientras que la Programación Orientada a Roles adopta un enfoque de mitigación, otorgando importancia al equilibrio entre los peligros y sus ventajas populares.

Un estudio realizado en 2017 por Héctor Valdecantos et al. mostró que "El análisis de corrección muestra que los programadores del grupo DCI tuvieron un mejor desempeño que los programadores del grupo OOjava. Esto concuerda con las teorías que sustentan DCI y debería alentar investigaciones más profundas y sistemáticas sobre las posibilidades de este paradigma". ^{[ 16 ]}

Según los investigadores Bluemke y Stepień del Instituto de Ciencias de la Computación de la Universidad Tecnológica de Varsovia , "los sistemas basados ​​en DCI son mucho más flexibles que los tradicionales, esto se debe a que las partes estáticas (datos) y dinámicas (contexto, interacción) del sistema están separadas y la separación de responsabilidades es una estrategia muy poderosa para dominar la complejidad". ^{[ 24 ]}

• Sitio web oficial
• La arquitectura DCI: una nueva visión de la programación orientada a objetos, por Trygve Reenskaug y James O. Coplien.
• Grupo de Google object-composition con varias implementaciones iniciales de DCI por parte de particulares.
• Los contextos son los nuevos objetos de Rickard Öberg.