Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Данные, контекст и взаимодействие ( DCI ) - это парадигма, используемая в компьютерном программном обеспечении для программирования систем взаимодействующих объектов . Его цели:

  • Улучшить читаемость объектно-ориентированного кода, придав поведению системы первоклассный статус;
  • Для чисто отдельного кода для быстрого изменения поведения системы (то , что система делает ) по сравнению с медленно меняющимся знанием домена (то , что система является ), вместо того , комбинируя оба в одном классе интерфейсе;
  • Чтобы помочь разработчикам программного обеспечения рассуждать о состоянии и поведении на уровне системы, а не только о состоянии и поведении объекта;
  • Поддерживать объектный стиль мышления, близкий к ментальным моделям программистов, а не классовый стиль мышления, который затмил объектное мышление на ранних этапах истории объектно-ориентированных языков программирования.

Парадигма отделяет модель предметной области (данные) от вариантов использования (контекст) и ролей, которые объекты играют (взаимодействие). DCI дополняет модель-представление-контроллер (MVC). MVC как язык шаблонов все еще используется для разделения данных и их обработки от представления.

Описание [ править ]

Данные [ редактировать ]

Остатки данных « что система является » . Данные часть архитектуры DCI является (относительно) моделью данных статических отношений. Дизайн данных обычно кодируется как обычные классы, которые представляют основную структуру предметной области системы. Эти классы едва ли представляют собой интеллектуальные данные, и им явно не хватает функциональности, характерной для поддержки того или иного конкретного варианта использования . Эти классы обычно инкапсулируют физическое хранилище данных. Эти данные реализуют информационную структуру, которая исходит из ментальной модели конечных пользователей, экспертов в предметной области, программистов и других людей в системе. Они могут близко соответствовать модельным объектам MVC.

Примером объекта данных может быть банковский счет. В его интерфейсе будут базовые операции для увеличения и уменьшения баланса, а также для запроса текущего баланса. Интерфейс, скорее всего, не будет предлагать операции, связанные с транзакциями, или которые каким-либо образом связаны с другими объектами или каким-либо взаимодействием с пользователем. Так, например, хотя банковский счет может предлагать примитив для увеличения баланса, он не будет иметь вызываемого метода deposit. Вместо этого такие операции принадлежат части взаимодействия DCI.

Объекты данных - это экземпляры классов, которые могут появиться в результате проектирования , управляемого предметной областью , и такие классы могут использовать отношения подтипов для организации данных предметной области. Хотя в конечном итоге DCI сводится к классам, DCI отражает вычислительную модель, в которой преобладает объектное мышление, а не классовое мышление. Следовательно, когда мы думаем о «данных» в DCI, это означает больше думать об экземплярах во время выполнения, чем о классах, из которых они были созданы.

Контекст [ править ]

Контекст - это класс (или его экземпляр), код которого включает роли для данного алгоритма, сценария или варианта использования, а также код для сопоставления этих ролей с объектами во время выполнения и для реализации варианта использования. Каждая роль привязана ровно к одному объекту во время применения любого конкретного варианта использования; однако один объект может одновременно играть несколько ролей. Контекст создается в начале реализации алгоритма, сценария или варианта использования. Таким образом, контекст включает варианты использования и алгоритмы, в которых объекты данных используются через определенные роли.

Каждый контекст представляет один или несколько вариантов использования. Объект контекста создается для каждого применения варианта использования, за который он отвечает. Его основная задача - идентифицировать объекты, которые будут участвовать в сценарии использования, и назначить их для исполнения ролей, которые выполняют сценарий использования через свои обязанности. Роль может содержать методы, и каждый метод является небольшой частью логики алгоритма, реализующего вариант использования. Методы ролей выполняются в контексте объекта, который выбран контекстом для воспроизведения этой роли для текущего применения варианта использования. Привязки ролей к объекту, которые имеют место в контексте, можно противопоставить полиморфизму народного объектно-ориентированного программирования. Общая бизнес-функциональность - это сумма сложных динамических сетей методов, децентрализованных в различных контекстах, и их ролей.

Каждый контекст - это область, которая включает идентификаторы, соответствующие его ролям. Любая роль, выполняемая в этом контексте, может ссылаться на другие роли в этом контексте через эти идентификаторы. Эти идентификаторы стали называть бездетными ролями . Во время принятия варианта использования каждый из этих идентификаторов становится привязанным к объекту, играющему соответствующую роль для этого контекста.

Примером контекста может быть банковский перевод между двумя учетными записями, где модели данных (банковские счета) используются через роли с именами SourceAccount и DestinationAccount.

Взаимодействие [ править ]

Взаимодействие - это «то, что делает система ». Взаимодействие реализовано в виде ролей, которые играют объекты во время выполнения. Эти объекты объединяют состояние и методы объекта данных (домена) с методами (но без состояния, поскольку роли не имеют состояния) из одной или нескольких ролей. В хорошем стиле DCI роль обращается к другому объекту только с точки зрения его (бездетной) роли. Называется специальная роль, selfкоторая привязывается к объекту, играющему текущую роль. Код внутри метода роли может вызывать метод selfи, таким образом, вызывать метод части данных текущего объекта. Один любопытный аспект DCI заключается в том, что эти привязки гарантированно присутствуют только во время выполнения (с использованием различных подходов и соглашений; шаблоны C ++может использоваться для гарантии успешной привязки). Это означает, что взаимодействия, методы ролей, являются общими . Фактически, некоторые реализации DCI используют универсальные шаблоны или шаблоны для ролей.

Роль - это программная конструкция без сохранения состояния, которая соответствует ментальной модели конечного пользователя некоторого объекта в системе. Роль представляет собой набор обязанностей. В то время как обычное объектно-ориентированное программирование говорит об объектах или классах как о множестве обязанностей, DCI приписывает их ролям. У объекта, участвующего в варианте использования, есть обязанности: те, которые он берет на себя в результате выполнения определенной роли. В большинстве современных языков программирования есть способ выражать роли и выражать внедрение методов ролей в объекты, а методы реализации различаются в зависимости от языка. Инъекция может быть полностью динамической во время выполнения в таких языках, как Ruby и Python ; он более статичен на таких языках, как Smalltalk -Squeak , Scala и C ++ . Среда программирования Qi4j предлагает способ выразить внедрение метода роли в объекты Java. [1] Метод Java 8 по умолчанию для интерфейсов может использоваться для реализации ролей безопасным способом.

В приведенном выше варианте использования денежного перевода, например, методы Role в SourceAccount и DestinationAccount осуществляют фактический перевод.

Отличительные черты DCI [ править ]

DCI ограничивает все допустимые сети взаимодействующих объектов сетями с общими топологиями, по одной для каждого варианта использования. Такие сети явны во взаимодействиях между ролями DCI, тогда как в классической объектной ориентации они возникают. Роль - это узел в такой топологии; это частичная классификация поведения всех объектов, которые могут занимать этот узел. Топология - это описание структуры времени выполнения системы.

Объектно-ориентированная программа - это сложная и динамичная сеть объектов в том же смысле, что отношения между объектами реального мира сложны и динамичны. Рассмотрим официанта в ресторане. Сам официант представляет собой сложный объект, который можно рассматривать по-разному: как моего официанта (например, который описывает сегодняшнее меню и принимает мой заказ), как сотрудника ресторана (с определенной зарплатой и рабочим временем) и как Человек в ресторане (ограничение по вместимости - 150 человек). Если бы класс Waiter был написан так, чтобы уловить реальную сущность Waiters (именно в этом и состоит суть объектной ориентации), было бы очень сложно поддерживать все эти точки зрения.

В DCI эти различные взгляды учитываются в ролях. Во время выполнения роль является идентификатором объекта. Во время принятия варианта использования (например, « Подать вино» ) ролевой официант однозначно идентифицирует отдельный объект в любой момент времени. Вы можете возразить, что за столом может быть несколько официантов. Однако они, вероятно, будут различаться по своим обязанностям в рамках варианта использования , например, в именах ролей HeadWaiter и Busboy. Даже если их обязанности идентичны, они все равно будут описаны как «Официант-1» и «Официант-2» или как отдельные (названные) элементы вектора «Официант», если кто-то намеревается написать для них программное обеспечение. Таким образом, такая роль, как HeadWaiter, становится идентификатором, дескриптором, с помощью которого объекты ссылаются друг на друга в варианте использования..

DCI распознает Официанта как объект, а не, скажем, как композицию из частей Сотрудника, части Официанта и части Человека. У объекта есть собственная идентичность, независимая от варианта использования ; это аспект данных DCI. Роли представляют собой псевдонимы для своих объектов, но никогда не являются отдельными объектами; это может вызвать шизофрению . В этом смысле каждый Официант - homo sapiens . Это элементарная часть системы официанта. У объекта есть много возможных идентификаторов в зависимости от варианта использования, в котором он задействован; это проявляется в идентификаторах ролей, которые являются частью аспекта взаимодействия DCI. Это (обычно более интересная) часть того, что делает система. Однако в DCI есть только один объекткоторый несет обе эти точки зрения во время выполнения. Эти перспективы могут быть сгруппированы по-разному во время кодирования. В коде преобладает структура варианта использования , которая пересекает объекты и также является частью аспекта взаимодействия DCI.

DCI позволяет объекту взять на себя одну или несколько ролей во время принятия варианта использования . Другими словами, объект повторно привязывается к идентификаторам ролей при применении каждого варианта использования . Эти роли определяют интерфейс, называемый типом роли. Каждый объект заново «переделывается» (в театральном смысле) для каждого варианта использования . Хотя роль привязана только к одному объекту, объект может играть несколько ролей. Например, официант может быть задействован в сценарии использования для подсчета всех посетителей ресторана во время пожарной инспекции и будет играть роль человека, а также роль официанта. Один объект поддерживает поведение обеих ролей, необходимое для выполнения варианта использования .

Таким образом, архитектуры DCI обычно характеризуются следующими свойствами:

  • Модель данных отражает структуру предметной области, а не разделы ее поведения;
  • Объекты динамически принимают роли во время принятия сценария использования ;
  • Каждую роль варианта использования играет объект, определенный контекстом в начале внедрения варианта использования ;
  • Сеть взаимодействий между ролями в коде (т. Е. Во время кодирования) такая же, как соответствующая сеть объектов во время выполнения;
  • Эти сети потенциально воссоздаются при каждом введении в действие сценария использования ;
  • Роли входят в область действия и выходят за ее пределы в зависимости от времени жизни варианта использования , но объекты, которые могут играть эти роли, могут сохраняться в течение нескольких жизненных циклов сценария использования и потенциально могут играть множество ролей в течение своего собственного времени жизни.

Модель исполнения [ править ]

DCI можно рассматривать как программирование событийного парадигмы, где какое - то событие (как человеческий жест в модель-представление-контроллер (MVC) архитектуры) запускает в случай использования . Вариант использования может быть краткосрочным или долгоживущим. События называются триггерами , и они обрабатываются в среде, в которую встроен DCI. Эта среда может быть контроллером традиционной архитектуры MVC или любого другого кода системного уровня.

Триггер заставляет среду создавать экземпляр объекта контекста . Типа объекта выбираются в зависимости от вида случая использования , который последует, на основе информации о триггере или состоянии системы или оба. Например, банкомат может иметь отдельные классы контекста для перевода денег, снятия денег, депозита, запроса баланса и так далее. Как только среда создает экземпляр объекта Context, она вызывает свой метод триггера, чтобы начать реализацию варианта использования.

Как описано выше, каждый контекст обеспечивает область разработки для ролей, которые участвуют в реализации варианта использования . Задача контекста - назначать объекты для исполнения этих ролей.

  1. Контекст сначала находит объекты, которые должны участвовать в реализации этого варианта использования . Эти объекты могут находиться где угодно в среде, в базе данных или создаваться «на лету»; DCI не ограничивает эти объекты. Внутри контекста есть не более одного экземпляра, играющего любую заданную роль в любой момент времени.
  2. Во-вторых, контекст назначает один объект для воспроизведения каждой из своих ролей (хотя один объект часто играет несколько ролей в одном контексте). В сильно динамических языках (Ruby, Python) Context внедряет методы Role в объект. В большинстве динамических языков любой существующий объект можно попросить сыграть любую роль в любое время (хотя некоторые комбинации объект-роль, конечно, могут не иметь смысла; бессмысленные комбинации объектов и ролей привели бы к MESSAGE NOT UNDERSTOODво время выполнения, если бы был вызван метод Role. .) В языках с более статической типизацией (Scala, C ++) должна быть какая-то предварительная договоренность, чтобы объект поддерживал методы ролей. Например, Scala создает анонимный класс , который сочетает в себе элементарную логику класса домена с прецедентов логикойтрейт, используемый для реализации роли; Роли эффективно назначаются объектам домена при их создании.
  3. В-третьих, контекст вызывает метод Role для первого объекта, чтобы принять участие в варианте использования .
  4. С этого момента роли вызывают методы друг друга для выполнения варианта использования . Метод Role может вызывать метод, selfкоторый фактически обрабатывается объектом, который в данный момент играет роль. Вот как роли вызывают элементарные операции с данными объектов, которые в данный момент их воспроизводят.

Реализация DCI [ править ]

DCI зависит от процесса проектирования, который отделяет варианты использования от модели данных. Модель данных часто основана на неформальном анализе предметной области. Роли, которые характеризуют модель функциональности системы конечного пользователя, берутся из вариантов использования .

Методы реализации различаются для разных языков программирования. Общим для многих подходов является то, что роли представлены такими конструкциями, как обобщения, шаблоны, классы или признаки . Код для базовой логики предметной области реализуется отдельно, следуя традиционной объектно-ориентированной практике и чаще всего с использованием классов. Код каждой роли вводится в объект домена, который будет воспроизводить его во время принятия варианта использования . Для реализации роли , инъекции метод обычно требуется. Черты - это один из распространенных методов языка программирования для поддержки внедрения методов . Некоторые языки, такие как Scala , имеют встроенную поддержку трейтов., в то время как другие языки (например, Ruby и Python ) допускают внедрение методов во время выполнения. В Java для поддержки DCI необходимы уловки перед компилятором, основанные на аннотациях.

Существует несколько примеров реализации: Smalltalk - Squeak , [2] C ++ , [3] C # , [4] Ruby , [5] JavaScript , [6] Python , [7] Qi4J ( Java ), [8] Scala , Perl , [ 9] и PHP . [10], и некоторые из них были добавлены на сайт fulloo.info, поддерживаемый создателями DCI.

История [ править ]

DCI был изобретен Трюгве Реенскаугом , также изобретателем MVC. Текущая формулировка DCI - это в основном работа Реенскауга и Джеймса О. Коплиена . [ необходима цитата ]

DCI возникла в основном как результат работы Трюгве Реенскауг по ролевому моделированию. [11] Трюгве давно осознал, что роли играют центральную роль в том, как программисты думают об объектах, и что развитие технологии языков программирования на основе классов лишило большей части мотивации думать об объектах в программе. Это, в свою очередь, затрудняло рассуждение о программе во время выполнения. Кроме того, тот факт, что объектно-ориентированные языки программирования предлагали только классы для выражения программной логики, оставил программиста во власти структурного макета данных для определения поведения, что неестественно по сравнению с описанием поведения на границах ролей. Это, в свою очередь, затрудняло рассуждение о поведении программы, чем, скажем, в процедурной программе на Фортране.. [ необходима цитата ]

Трюгве чувствовал важность создания программных структур, о которых можно было бы рассуждать, и начал обобществлять эти идеи еще в 2000 году. К 2006 году у него была рабочая модель дизайна, и его открытие в 2008 году работы Шерли над чертами характера дало краеугольный камень, который обеспечил выражение этих идей на языке естественного программирования. Он прототипировал идеи в среде программирования Baby, написанной на Squeak. Джим Коплиен присоединился к Trygve примерно в 2007 году, а к середине 2008 года у него был прототип, работающий на C ++ . Стин Леманн, Рикард Оберг и Никлас Хедман ускорили адаптацию этих идей к Ruby и Java в течение следующего года или около того с помощью фреймворка Qi4j. [1]Многие дополнительные языковые адаптации последовали за сессией на конференции JaOO в Дании в сентябре 2008 года. В 2010 году язык Marvin был создан Руне Лунд-Сёлтофт. Это была первая языковая сборка с нативной поддержкой DCI. Марвин был главным образом предназначен для проверки концепции, чтобы продемонстрировать идею «без впрыска DCI». Большинство предыдущих реализаций изменяли объекты ролевых игроков таким образом, чтобы они были видны вне контекста. Джеймс Коплиен создал trygve, первую языковую сборку с нуля для поддержки DCI.

Различные подходы, используемые для развития объектно-ориентированного программирования, как на уровне языка, так и на уровне шаблонов , в разной степени согласуются с DCI:

  • Миксины - это способ инкапсуляции кода для конкретной функциональности системы в закрытой форме; однако не существует единого механизма для связывания нескольких миксинов в единицу на уровне варианта использования . Их можно использовать для реализации концепции роли в DCI, хотя и не в строгом смысле этого слова. [ необходима цитата ]
  • Множественная отправка была ранней попыткой более полно отделить алгоритм от объектов, которые участвовали в его выполнении, что может быть дополнено отделением DCI общих повторяющихся алгоритмов от фрагментов кода, которые можно индивидуально локализовать для отдельных объектов. DCI концептуально ведет к более широкому повторному использованию одного алгоритма в закрытой форме для множества наборов объектов самых разнородных типов. Объект Context DCI действует как явный диспетчер интеллекта, аналогичный механизмам диспетчеризации языков с множественной диспетчеризацией. [ необходима цитата ]
  • Истинные объектно-ориентированные языки программирования, такие как Self, пытаются разрушить дихотомию между областями классового программирования и объектного выполнения, что помогает программистам сосредоточиться на объектах времени выполнения. DCI восстанавливает знания на уровне кода об отношениях между ними в контекстах и ​​в статических отношениях между методами ролей. [ необходима цитата ]
  • Внедрение зависимостей - это давний подход к изменению функциональности объекта во время выполнения, позволяя ему «передавать» часть своего выполнения внешнему объекту, который может быть повторно привязан по желанию. Большинство реализаций [ какие? ] инъекции зависимости приводят к проблеме собственной шизофрении , [ цитата необходима ], к которой реализации DCI обращаются должным образом. Такие системы, как Elmo, используют этот подход, который вносит дополнительную сложность в устранение неоднозначности методов и дублирования имен элементов данных. [12] [ требуется полная ссылка ]
  • Мультипарадигмальный дизайн [13] пытается разделить поведение и структуру, соотнося поведение с процедурным дизайном и структурный компонент с объектами, обеспечивая свободный доступ между ними, в соответствии с принципами дизайна C ++. Подход DCI может улучшить выражение взаимосвязи между процедурной и структурной частями дизайна и общей связности. [ необходима цитата ]

Проблемы объектно-ориентированного программирования также могут быть решены путем решения его проблем на уровне парадигмы.

  • Аспектно-ориентированное программирование (АОП), пожалуй, самый близкий исторический родственник DCI. В большинстве случаев использование Аспектов тесно связано с точкой зрения программиста и требует сильной инструментальной поддержки, чтобы обеспечить хорошее понимание поведения программного обеспечения на любом заданном pointcut . Основное отличие состоит в том, что в DCI структура алгоритма является первичной, с упором на ее изоляцию от внешнего кода, улучшая читаемость кода. В АОП pointcut и advice имеют одинаковую важность и, хотя физически не пересекаются, должны пониматься вместе, чтобы понять код, потому что совет инвазивен в pointcut. В то время как АОП обеспечивает административную группировку связанного набора отдельных локальных модификаций, которые вместе пересекают первичную структуру кода, DCI является семантическим выражением алгоритма с первоклассным статусом анализа, который вызывает существующие методы объекта. DCI не может рассматриваться как способ принять большой совет и позволить его частям вводить в ряд упорядоченных точечных сокращений . [ необходима цитата ]
  • Ролевое программирование объединяет идеи из аспектно-ориентированного программирования , концептуального моделирования [14] и многого другого. Ранние попытки (1991) определяли роли независимым образом [15], но более поздние подходы (2002 и последующие годы) сходятся во мнении, что роли зависят от контекста (также «команды» [16] или «институты» [17] ). В ролевом программировании роли определяются относительно некоторой внутренней (или базовой) сущности, что соответствует дихотомии данных и ролей в DCI. Концепция контекста по сути одинакова в обоих подходах. Оба подхода подчеркивают взаимодействие между группой ролей.
Можно выделить несколько отличий. Ролевое программирование сосредоточено на добавлении поддержки ролей в объектно-ориентированные языки программирования, где упор делается на повышение выразительности языка программирования и создание большего количества дизайнов. Для сравнения, DCI уделяет больше внимания методу захвата ментальных моделей, частично определяя этот метод как ограничение того, что следует рассматривать как юридический дизайн, соответствующий DCI. Например: авторы DCI склонны противодействовать некоторому использованию наследования (например, «внутри DCI вы не наследуете роли» [18]), тогда как ролевое программирование охватывает (и даже расширяет) наследование как центральную концепцию объектно-ориентированного программирования, поддерживая свободное сочетание с другими концепциями. DCI подчеркивает , что само шизофрению следует избегать, в то время как роль-ориентированного программирование утверждало , чтобы управлять расщепленными объектами таким образом , что шизофрения уже не была проблема [19] , но посредник для более гибких конструкций. В более поздней статье авторов DCI утверждается, что самошизофрения остается проблемой в ролевом программировании, используя контрпример, основанный на модифицированной реализации алгоритма Дейкстры . [20] Таким образом, DCI жертвует преимуществами наследования для полного исключения его недостатков, в то время как ролевое программирование использует подход смягчения последствий, придавая важность уравновешиванию опасностей с его популярными преимуществами.

Ссылки [ править ]

  1. ^ a b Qi4j фреймворк
  2. ^ Общий смысл объектно-ориентированного программирования Трюгве Реенскауг, http://heim.ifi.uio.no/~trygver/2009/commonsense.pdf
  3. ^ Полная документация OO DCI с примерами C ++, http://fulloo.info/Examples/C++Examples/index.html
  4. ^ Исходный код C # на GitHub, https://github.com/programmersommer/DCISample
  5. ^ Исходный код Ruby в группе Google Object-Composition, https://groups.google.com/group/object-composition/browse_thread/thread/561f638b43f1b960# 17.10.2009
  6. ^ Исходный код JavaScript в группе Google Object-Composition, https://groups.google.com/group/object-composition/browse_thread/thread/8ec4cf18e127cc3e# 17.10.2009
  7. ^ https://pypi.python.org/pypi/roles
  8. ^ Исходный код Qi4j в группе Google Object-Composition, https://groups.google.com/group/object-composition/browse_thread/thread/fe317e615b9008fe# 17.10.2009
  9. ^ Релиз на CPAN: https://metacpan.org/release/DCI Архивировано 24 января2012 г. на Wayback Machine
  10. ^ Исходный код PHP в Google, https://code.google.com/p/php-coredci
  11. ^ Трюгве Реенскауг. Работа с объектами: метод разработки программного обеспечения OOram. Прентис-Холл, 1995.
  12. ^ Джеймс Ли, Руководство пользователя Elmo, http://www.openrdf.org/doc/elmo/1.5/user-guide.html Архивировано 21июля2011 г. на Wayback Machine
  13. ^ Джеймс Коплиен, Мультипарадигмальный дизайн для C ++. Аддисон-Уэсли, 1998.
  14. ^ Фридрих Штайман, О представлении ролей в объектно-ориентированном и концептуальном моделировании, 2000, http://www.fernuni-hagen.de/ps/veroeffentlichungen/zeitschrift_46129.shtml
  15. ^ Джоэл Ричардсон и Питер Шварц, Аспекты: расширение объектов для поддержки нескольких независимых ролей, 1991, http://www.informatik.uni-trier.de/~ley/db/conf/sigmod/RichardsonS91.html Архивировано 2007-10 гг. -17 у Wayback Machine
  16. ^ Стефан Херрманн, Object Teams: Improving Modularity for Crosscutting Collaborations, http://www.objectteams.org/publications/index.html#NODe02 , 2002
  17. ^ Гвидо Балдони и др., Роли как координационная конструкция: введение в powerJava, 2005 г., http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.77.6337
  18. ^ Дж. Коплиен, опубликовано в группе Google Object-Composition, https://groups.google.com/forum/?hl=en#!topic/object-composition/haza-J2Doz8 21.10.2010
  19. ^ Stephan Herrmann, Demystifying Object Schizophrenia, 2010, http://www.objectteams.org/publications/index.html#MASPEGHI10.
  20. ^ Джеймс О. Коплиен и Трюгве Миккель Хейердал Реенскауг, парадигма данных, контекста и взаимодействия. В Гэри Т. Ливенс (ред.): Конференция по системам, программированию и приложениям: программное обеспечение для человечества, SPLASH '12, Тусон, Аризона, США, 21–25 октября 2012 г. ACM 2012, ISBN  978-1-4503- 1563-0 , стр. 227 - 228, http://dl.acm.org/citation.cfm?id=2384782&dl=ACM&coll=DL .

Внешние ссылки [ править ]

  • Архитектура DCI: новое видение объектно-ориентированного программирования Трюгве Ренскауг и Джеймс О. Коплиен
  • объектная композиция Группа Google с несколькими ранними реализациями DCI отдельными лицами
  • Контексты новые объекты по Рикард Оберг