Datos, contexto e interacción

Datos, contexto e interacción ( DCI ) es un paradigma utilizado en 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;
• Para separar claramente el código para un comportamiento del sistema que cambia rápidamente (qué hace un sistema ) del conocimiento del dominio que cambia lentamente (qué es un sistema ), en lugar de combinar ambos en una interfaz de clase;
• Para ayudar a los desarrolladores de software a razonar sobre el estado y el comportamiento a nivel del sistema en lugar de solo sobre el estado y el comportamiento de los objetos;
• Apoyar un estilo de pensamiento basado en objetos que se acerque a los modelos mentales de los programadores, en lugar del estilo de pensamiento basado en clases que eclipsó el pensamiento basado en objetos al principio de la historia 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 a modelo-vista-controlador (MVC). MVC como lenguaje de patrones todavía se utiliza para separar los datos y su procesamiento de la presentación.

Los datos siguen siendo "lo que es el sistema ". ^[1] La parte de datos de la arquitectura DCI es su modelo de datos (relativamente) estático con relaciones. El diseño de datos suele estar codificado como clases convencionales que representan la estructura básica del dominio del sistema. Estas clases son apenas datos inteligentes, ^{[1] [2]} y carecen explícitamente de la funcionalidad que es peculiar para soportar cualquier caso de uso particular . Estas clases comúnmente encapsulan el almacenamiento físico de los datos. Estos datos implementan una estructura de información que proviene del modelo mental de los usuarios finales, expertos en el dominio, programadores y otras personas en el sistema. Pueden corresponder estrechamente a los objetos del modelo de MVC. ^[1]

Un ejemplo de un objeto de datos podría ser una cuenta bancaria. Su interfaz tendría operaciones básicas para aumentar y disminuir el saldo y para consultar el saldo actual. La interfaz probablemente no ofrecería operaciones que involucren transacciones o que de alguna manera involucren otros objetos o cualquier interacción del usuario. Por lo tanto, por ejemplo, si bien una cuenta bancaria puede ofrecer una primitiva para aumentar el saldo, no tendría ningún método llamado deposit. Tales operaciones pertenecen en cambio a la parte de interacción de DCI. ^[1]

Los objetos de datos son instancias de clases que pueden provenir de un diseño impulsado por el dominio , y dichas clases pueden usar relaciones de subtipificación para organizar los datos del dominio. Aunque al final se reduce a clases, DCI refleja un modelo computacional dominado por el pensamiento de objetos en lugar del pensamiento de clases. Por lo tanto, cuando se piensa en "datos" en DCI, significa pensar más en las instancias en tiempo de ejecución que en las clases a partir de las cuales se crearon. ^[3]

El contexto es la clase (o su instancia) cuyo código incluye los Roles para un algoritmo, escenario o caso de uso determinado, así como el código para mapear estos Roles en objetos en tiempo de ejecución y para implementar el caso de uso. Cada Rol está vinculado a exactamente un objeto durante la implementación de cualquier caso de uso determinado; sin embargo, un solo objeto puede desempeñar simultáneamente varios Roles. ^[4] Un contexto se instancia al comienzo de la implementación de un algoritmo, escenario o caso de uso. En resumen, un contexto comprende casos de uso y algoritmos en los que se utilizan objetos de datos a través de Roles específicos. ^[1]

Cada contexto representa uno o más casos de uso. ^[1] Se crea una instancia de un objeto de contexto para cada implementación de un caso de uso del que es responsable. Su función principal es identificar los objetos que participarán en el caso de uso y asignarles los roles que llevan a cabo el caso de uso a través de sus responsabilidades. Un rol puede incluir métodos, y cada método es una pequeña parte de la lógica de un algoritmo que implementa un caso de uso. Los métodos de rol se ejecutan en el contexto de un objeto que el contexto selecciona para desempeñar ese rol en la implementación del caso de uso actual. Las vinculaciones de rol a objeto que tienen lugar en un contexto se pueden contrastar con el polimorfismo de la programación orientada a objetos vernácula. ^[5] La funcionalidad empresarial general es la suma de redes complejas y dinámicas de métodos descentralizados en múltiples contextos y sus roles.

Cada contexto es un ámbito que incluye identificadores que corresponden a sus Roles. ^[1] Cualquier Rol que se ejecute dentro de ese contexto puede hacer referencia a los otros Roles en ese contexto a través de estos identificadores. ^[1] Estos identificadores han llegado a llamarse RoleMethods . ^[5] En el momento de la implementación del caso de uso, todos y cada uno de estos identificadores se vinculan a un objeto que desempeña el Rol correspondiente para este contexto.

Un ejemplo de contexto podría ser una transferencia bancaria entre dos cuentas, donde los modelos de datos (las cuentas bancarias) se utilizan a través de roles denominados SourceAccount y DestinationAccount.

La interacción es "lo que hace el sistema ". ^[1] La interacción se implementa como Roles que son desempeñados por objetos en tiempo de ejecución. Estos objetos combinan el estado y los métodos de un objeto de datos (dominio) con métodos (pero sin estado, ya que los Roles no tienen estado ^[6] ) de uno o más Roles. ^[1] En un buen estilo DCI, un Rol se dirige a otro objeto solo en términos de su Rol (sin método). Hay un Rol especial llamado selfque se vincula al objeto que desempeña el Rol actual. El código dentro de un método de Rol puede invocar un método en selfy, por lo tanto, invocar un método de la parte de datos del objeto actual. Un aspecto curioso de DCI es que se garantiza que estos enlaces estén en su lugar solo en tiempo de ejecución (usando una variedad de enfoques y convenciones; se pueden usar plantillas de C++ para garantizar que los enlaces tendrán éxito ^[7] ). Esto significa que las interacciones, los métodos de Rol, son genéricos . De hecho, algunas implementaciones de DCI usan genéricos o plantillas para Roles.

Un Rol es una construcción de programación sin estado que corresponde al modelo mental del usuario final de alguna entidad en el sistema. ^[3] Un Rol representa una colección de responsabilidades. Mientras que la programación orientada a objetos vernácula habla de objetos o clases como una multiplicidad de responsabilidades, DCI los atribuye a Roles. Un objeto que participa en un caso de uso tiene responsabilidades: aquellas que asume como resultado de desempeñar un Rol particular. La mayoría de los lenguajes de programación modernos tienen una forma de expresar Roles y de expresar la inyección de métodos de Rol en objetos, y las técnicas de implementación varían según el lenguaje. La inyección puede ser completamente dinámica en tiempo de ejecución en lenguajes como Ruby y Python ; es más estática en lenguajes como Smalltalk - Squeak , Scala y C++ . El entorno de programación Qi4j ofrece una forma de expresar la inyección de métodos de Rol en objetos Java. ^[8] El método predeterminado de Java 8 en las interfaces se puede utilizar para implementar Roles de una manera segura para los tipos.

En el caso de uso de transferencia de dinero mencionado anteriormente, por ejemplo, los métodos Role en SourceAccount y DestinationAccount ejecutan la transferencia real.

La DCI limita todas las redes permisibles de objetos en comunicación a redes que comparten topologías comunes, una para cada caso de uso. ^{[9] [3]} Estas redes son explícitas en las interacciones entre Roles de DCI, mientras que en la orientación clásica a objetos 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 de tiempo de ejecución de un sistema. ^[10]

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

En DCI, estas diferentes vistas se factorizan en Roles. En tiempo de ejecución, el Rol es la identidad del objeto. ^[5] Durante la promulgación de un caso de uso (como Serve the Wine ) el Rol Waiter identifica inequívocamente un solo objeto en un momento dado. ^[4] Se podría argumentar que puede haber varios Waiters 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 Role HeadWaiter y Busboy. Incluso si sus responsabilidades son idénticas, aún se describirían como Waiter-1 y Waiter-2, o como elementos individuales (nombrados) de un vector Waiter, si alguien tuviera la intención de escribir software para ellos. Entonces, un Rol como HeadWaiter se convierte en el identificador, el identificador, por 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 alias para sus objetos pero nunca son objetos separados en sí mismos; eso causaría esquizofrenia personal . 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 surge en las identidades de Rol que forman parte de la faceta de Interacción de DCI. Estas son la parte (generalmente más interesante) de qué-hace-el-sistema. Sin embargo, en DCI, solo hay un único objeto que lleva ambas perspectivas en tiempo de ejecución. Estas perspectivas se pueden agrupar de manera diferente en el momento de la codificación. El código está dominado por la estructura del caso de uso , que abarca todos los objetos y que también es parte de la faceta de Interacción de DCI.

DCI permite que un objeto asuma uno o más Roles durante la implementación de un caso de uso . En otras palabras, un objeto se vuelve a vincular a identificadores de Roles en cada implementación de un caso de uso . ^[4] Estos Roles infieren una interfaz, denominada tipo de Rol. Cada objeto se "reestructura" (en el sentido teatral) nuevamente 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 objeto único 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: ^{[1] [10]}

• El modelo de datos refleja la estructura del dominio en lugar de particiones de su comportamiento;
• Los objetos asumen roles dinámicamente durante la ejecución de casos de uso ;
• Cada rol de un caso de uso es desempeñado 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 el momento de la codificación) es la misma que la red correspondiente de objetos en el momento de la ejecución;
• Estas redes se recrean potencialmente en cada caso de uso ;
• Los roles entran y salen del alcance con la duración de los casos de uso , pero los objetos que pueden desempeñar estos roles pueden persistir durante múltiples duraciones de casos de uso y potencialmente pueden desempeñar muchos roles durante su propia duración.

Se puede pensar en DCI como un paradigma de programación impulsado por eventos , donde algún evento (como un gesto humano en una arquitectura modelo-vista-controlador (MVC)) activa un caso de uso . ^[3] El caso de uso puede ser de corta o larga duración. Los eventos se denominan activadores y se manejan en el entorno en el que está integrado 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 producirá, en función de la información sobre el disparador o el estado del sistema o ambos. Por ejemplo, un cajero automático puede tener clases de contexto independientes para transferencia de dinero, retiro, depósito, consulta de saldo, etc. Una vez que el entorno crea una instancia del objeto de contexto, invoca su método disparador para iniciar la ejecución del caso de uso. ^[4]

Como se describió anteriormente, cada contexto proporciona un alcance de diseño para los roles que participan en la implementación del caso de uso . La tarea del contexto es asignar objetos para desempeñar estos roles. ^[5]

1. El contexto primero busca los objetos que van a participar en la implementación de este caso de uso . Estos objetos pueden estar en cualquier parte del entorno, en una base de datos o pueden crearse sobre la marcha; DCI no restringe estos objetos. Dentro de un contexto, hay como máximo una instancia que desempeña un rol determinado en un momento determinado.
2. En segundo lugar, el Contexto asigna un único objeto para desempeñar cada uno de sus Roles (aunque un único objeto a menudo desempeña múltiples Roles en un único Contexto). En lenguajes fuertemente dinámicos (Ruby, Python) el Contexto inyecta los métodos de Rol en el objeto. En la mayoría de los lenguajes dinámicos, se puede pedir a cualquier objeto existente que desempeñe cualquier Rol en cualquier momento (aunque algunas combinaciones de objeto-Rol pueden, por supuesto, no tener sentido; las combinaciones sin sentido de objetos y Roles conducirían a MESSAGE NOT UNDERSTOODun tiempo de ejecución si se invocara el método Rol). En lenguajes con tipos más estáticos (Scala, C++) tiene que haber habido algún arreglo previo para que el objeto admita los métodos de Rol. Por ejemplo, Scala crea una clase anónima que combina la lógica rudimentaria de una clase de dominio con la lógica de caso de uso del rasgo utilizado para implementar un Rol; los Roles se asignan efectivamente a objetos de dominio cuando se instancian.
3. En tercer lugar, el Contexto invoca un método Rol 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 llevar a cabo el caso de uso . Un método de Roles puede invocar un método selfque, de hecho, es manejado por el objeto que actualmente desempeña el Rol. Así es como los Roles invocan las operaciones de datos rudimentarias de los objetos que los están desempeñando en ese momento.

La 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 . ^[3]

Las técnicas de implementación difieren entre los lenguajes de programación. Lo que es común a muchos enfoques es que los Roles están representados por construcciones tales 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 orientada a objetos y más comúnmente usando clases. El código de cada Rol se inyecta en el objeto de dominio que lo reproducirá durante la promulgación del caso de uso . Para implementar Roles , generalmente se necesita la inyección de métodos. Los rasgos son una técnica común del lenguaje de programación para admitir la inyección de métodos. Algunos lenguajes, como Scala , tienen soporte nativo para rasgos , mientras que otros lenguajes (por ejemplo, Ruby y Python ) permiten la inyección de métodos en tiempo de ejecución. En Java , se necesitan trucos de precompilador basados ​​en anotaciones para admitir DCI. Haxe usa su función de macro en tiempo de compilación para transformar la semántica de DCI al código del lenguaje de destino.

Existen varias implementaciones de ejemplo en el sitio fulloo.info mantenido por los creadores de DCI.

El DCI fue inventado por Trygve Reenskaug , también inventor de MVC. La formulación actual del DCI es en su mayor parte obra de Reenskaug y James O. Coplien . ^{[1] [3] [9]}

DCI surgió en gran medida como resultado del trabajo de Trygve Reenskaug sobre el modelado basado en roles. ^[11] Trygve había reconocido desde hacía tiempo que los roles desempeñaban un papel central en la forma en que los programadores pensaban sobre los objetos, y que la progresión basada en clases de la tecnología de lenguajes de programación eliminaba gran parte de la motivación para pensar sobre los objetos en un programa. Eso, a su vez, dificultaba razonar sobre el programa en tiempo de ejecución. Además, el hecho de que los lenguajes de programación orientados a objetos ofrecieran solo clases para expresar la lógica del programa dejaba al programador a merced de la disposición estructural de los datos para delinear el comportamiento, lo que es poco natural en comparación con un comportamiento delineante en los límites de los roles. Esto, a su vez, hacía que el comportamiento del programa fuera más difícil de razonar que, por ejemplo, en un programa procedimental en Fortran . ^{[ cita requerida ]}

Trygve consideró que era importante crear estructuras de programas sobre las que se pudiera razonar, y comenzó a socializar estas ideas ya en el año 2000. En 2006 ya contaba con un modelo de diseño funcional, y su descubrimiento en 2008 del trabajo de Schärli sobre Traits proporcionó la piedra angular que proporcionaría una expresión natural de lenguaje de programación de estas ideas. Prototipó las ideas en el entorno de programación Baby, escrito en Squeak. James Coplien se unió a Trygve en este esfuerzo en 2007 aproximadamente y a mediados de 2008 ya 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 aproximadamente con el marco Qi4j. ^[8] Muchas adaptaciones de lenguaje adicionales siguieron a 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 creado con soporte nativo para DCI. Marvin fue pensado principalmente como una prueba de concepto para mostrar la idea de "DCI sin inyección". La mayoría de las implementaciones anteriores modificaron los objetos de los jugadores de rol de una manera que fuera visible fuera del contexto. James Coplien creó el lenguaje trygve basado en la misma idea, el primer lenguaje creado desde cero para soportar DCI.

Los diferentes 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 funciones específicas de lo que hace el sistema en forma cerrada; sin embargo, no existe un mecanismo consistente para vincular múltiples mixins en una unidad a nivel de un caso de uso . Se pueden emplear para implementar el concepto de Rol en DCI, aunque no en un sentido estricto. ^{[ cita requerida ]}
• El envío múltiple fue un intento temprano de separar más completamente un algoritmo de los objetos que estaban involucrados en su ejecución, lo que se puede complementar con la separación de DCI de algoritmos recurrentes comunes de fragmentos de código que podrían localizarse individualmente en objetos individuales. DCI conduce conceptualmente a una reutilización más amplia de un único algoritmo en forma cerrada en muchos conjuntos de objetos de tipos ampliamente heterogéneos. El objeto Context de DCI actúa como un despachador explícito e inteligente que es análogo a los mecanismos de despacho de lenguajes con envío múltiple. ^{[ cita requerida ]}
• Los verdaderos lenguajes de programación orientados a objetos como Self intentan romper la dicotomía entre los dominios de la programación con clases y la ejecución con 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 los contextos y en las relaciones estáticas entre los métodos de roles. ^[1]
• La inyección de dependencia es un enfoque de larga data para cambiar la funcionalidad de un objeto en tiempo de ejecución al permitirle "subcontratar" parte de su ejecución a un objeto externo que puede volver a vincularse a voluntad. La mayoría de las implementaciones ^{[ ¿cuáles? ]} de la inyección de dependencia conducen al problema de la esquizofrenia propia , ^[12] que las implementaciones de DCI abordan adecuadamente. Sistemas como Elmo utilizan este enfoque, que aporta complejidad adicional para resolver la ambigüedad de los métodos y los nombres de miembros de datos duplicados. ^{[13] [ se necesita cita completa ]}
• El diseño multiparadigma ^[14] intenta separar el comportamiento de la estructura al asociar 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. ^[15]

Los desafíos de la programación orientada a objetos también pueden afrontarse abordando sus problemas a nivel de paradigma.

• La programación orientada a aspectos (AOP) 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 fuerte soporte de herramientas para proporcionar una buena comprensión del comportamiento del software en cualquier punto de corte determinado . La principal diferencia es que en DCI, la estructura del algoritmo es primaria, con un fuerte énfasis en su aislamiento del código fuera de sí mismo, mejorando la legibilidad del código. En AOP, el punto de corte y el consejo tienen la misma importancia y, aunque físicamente disjuntos, deben entenderse juntos para comprender el código, porque el consejo es invasivo en el punto de corte . Mientras que AOP proporciona una agrupación administrativa de una colección relacionada de modificaciones locales individuales que juntas atraviesan la estructura primaria del código, DCI es una expresión semántica de un algoritmo con una posición de análisis de primera clase que invoca métodos de objetos existentes. DCI puede considerarse como una forma de tomar un gran consejo y permitir que partes de él se inyecten en una serie de puntos de corte regularizados . ^{[ cita requerida ]}
• La programación orientada a roles reúne ideas de la programación orientada a aspectos , el modelado conceptual ^[16] y más. Los primeros intentos (1991) definieron los roles de manera independiente ^[17] , pero los enfoques más recientes (2002 en adelante) convergen en enfatizar que los roles dependen del contexto (también "equipos" ^[18] o "instituciones" ^[19] ). 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-rol 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 , donde el énfasis está en aumentar la expresividad de un lenguaje de programación y permitir más diseños. En comparación, DCI tiene un enfoque más fuerte en el método de cómo se deben capturar los modelos mentales, definiendo este método en parte como restricciones sobre lo que se debe considerar un diseño legal correspondiente a DCI. Por ejemplo: Los autores de DCI tienden a desalentar algún uso de la herencia (por ejemplo, "dentro de DCI no se heredan roles" ^[20] ), mientras que la programación orientada a roles adopta (e incluso mejora) la herencia como un concepto central de la programación orientada a objetos, apoyando la combinación libre con otros conceptos. DCI enfatiza que se debe evitar la esquizofrenia propia , mientras que la programación orientada a roles afirmaba gestionar los objetos divididos de tal manera que la esquizofrenia ya no fuera un problema ^[21] sino un facilitador para diseños más flexibles. Un artículo posterior de los autores de DCI afirma que la autoesquizofrenia sigue siendo un problema en la programación orientada a roles utilizando un contraejemplo basado en una implementación modificada del algoritmo de Dijkstra . ^[22] Como tal, 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 de los peligros con sus ventajas populares.

Un estudio de 2017 realizado por Héctor Valdecantos et. al. mostró que “el análisis de corrección muestra que los programadores del grupo DCI se desempeñaron mejor que los programadores del grupo OOjava. Esto está en línea con las teorías detrás de DCI y debería alentar investigaciones más sistemáticas sobre las posibilidades de este paradigma”. ^[15]

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

• 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 de composición de objetos con varias implementaciones tempranas de DCI por parte de individuos
• Los contextos son los nuevos objetos de Rickard Öberg