데이터, 컨텍스트 및 상호작용

Data, context and interaction

데이터, 컨텍스트, 인터랙션(DCI)은 컴퓨터 소프트웨어에서 통신 객체의 시스템을 프로그래밍하기 위해 사용되는 패러다임입니다.목표는 다음과 같습니다.

  • 시스템 동작에 최고 수준의 상태를 부여하여 객체 지향 코드의 가독성을 향상시킨다.
  • 하나의 클래스 인터페이스로 결합하는 것이 아니라 빠르게 변화하는 시스템 동작(시스템 동작)과 느리게 변화하는 도메인 지식(시스템이란 무엇인가)을 명확하게 구분한다.
  • 소프트웨어 개발자가 객체 상태 및 동작뿐만 아니라 시스템 수준의 상태 및 동작에 대해 추론할 수 있도록 지원합니다.
  • 오브젝트 지향 프로그래밍 언어의 역사 초기에 오브젝트 사고를 무색하게 했던 클래스 사고 스타일이 아니라 프로그래머의 멘탈 모델에 가까운 오브젝트 사고 스타일을 지지한다.

패러다임은 도메인 모델(데이터)을 사용 사례(콘텍스트) 및 개체가 수행하는 역할(상호작용)과 분리합니다.DCI는 Model-View-Controller(MVC; 모델 뷰 컨트롤러)를 보완합니다.패턴 언어로서의 MVC는 여전히 데이터와 그 처리를 프레젠테이션에서 분리하기 위해 사용됩니다.

묘사

데이터.

데이터는 "시스템" 그대로입니다.DCI 아키텍처의 데이터 부분은 관계와의 (상대적인) 정적 데이터 모델입니다.데이터 설계는 보통 시스템의 기본 도메인 구조를 나타내는 일반적인 클래스로 코드화됩니다.이러한 클래스는 거의 스마트한 데이터가 아니며 특정 사용 사례를 지원하는 데 고유한 기능이 없습니다.이러한 클래스는 일반적으로 데이터의 물리적 스토리지를 캡슐화합니다.이러한 데이터는 최종 사용자, 도메인 전문가, 프로그래머 및 시스템 내 다른 사람들의 정신 모델에서 파생된 정보 구조를 구현합니다.이들은 MVC의 모델 객체와 거의 일치할 수 있다.

데이터 객체의 예로는 은행 계좌를 들 수 있습니다.그 인터페이스에는 잔액의 증감 및 현재의 잔액에 대한 문의에 관한 기본적인 조작이 있습니다.이 인터페이스에서는 트랜잭션이나 다른 오브젝트나 사용자와의 상호작용을 수반하는 조작은 제공되지 않을 가능성이 있습니다.그래서 예를 들어, 은행 계좌는 잔액을 늘리기 위한 기본을 제공할 수 있지만, 그것은 라고 불리는 방법을 가지고 있지 않을 것이다.deposit이러한 연산은 DCI의 상호작용 부분에 속합니다.

데이터 개체는 도메인 기반 설계에서 가져올 수 있는 클래스의 인스턴스이며, 이러한 클래스는 하위 유형 관계를 사용하여 도메인 데이터를 구성할 수 있습니다.DCI는 결국 계층으로 전락하지만 계층적 사고보다는 객체적 사고가 지배하는 계산 모델을 반영한다.따라서 DCI에서 "데이터"를 생각할 때 인스턴스화된 클래스보다 런타임에 인스턴스를 더 많이 고려해야 합니다.

맥락

컨텍스트는 특정 알고리즘, 시나리오 또는 사용 사례에 대한 역할과 실행 시 이러한 역할을 개체에 매핑하고 사용 사례를 실행하는 코드가 포함된 클래스(또는 해당 인스턴스)입니다.각 역할은 특정 사용 사례 제정 중에 정확히 하나의 객체에 구속됩니다.단, 하나의 객체가 여러 역할을 동시에 수행할 수 있습니다.컨텍스트는 알고리즘, 시나리오 또는 유스케이스의 제정을 시작할 때 인스턴스화됩니다.요약하면 컨텍스트는 특정 역할을 통해 데이터 개체를 사용하는 사용 사례와 알고리즘으로 구성됩니다.

각 컨텍스트는 하나 이상의 사용 사례를 나타냅니다.컨텍스트 오브젝트는 자신이 담당하는 유스케이스를 제정할 때마다 인스턴스화된다.주요 업무는 사용 사례에 참여할 개체를 식별하고 책임을 통해 사용 사례를 수행하는 역할을 할당하는 것입니다.역할은 메서드로 구성될 수 있으며, 각 메서드는 사용 사례를 구현하는 알고리즘의 로직 중 일부입니다.역할 메서드는 현재 사용 사례 제정에서 해당 역할을 수행하기 위해 컨텍스트에 의해 선택된 개체의 컨텍스트에서 실행됩니다.컨텍스트에서 발생하는 역할-객체 바인딩은 로컬 객체 지향 프로그래밍의 다형성과 대조될 수 있습니다.전체적인 비즈니스 기능은 여러 컨텍스트에서 분산된 방법과 그 역할의 복잡하고 동적인 네트워크의 합계입니다.

각 컨텍스트는 역할에 대응하는 식별자를 포함하는 범위입니다.해당 컨텍스트 내에서 실행되는 모든 역할은 이러한 식별자를 통해 해당 컨텍스트의 다른 역할을 참조할 수 있습니다.이러한 식별자를 메서드리스 롤이라고 부릅니다.유스케이스의 제정시에, 이러한 식별자 각각은, 이 컨텍스트에 대응하는 역할을 담당하는 오브젝트에 바인드 됩니다.

컨텍스트의 예로는 SourceAccount와 DestinationAccount라는 이름의 역할을 통해 데이터 모델(은행 계정)을 사용하는 두 계정 간의 유선 전송을 들 수 있습니다.

상호 작용

상호작용은 "시스템이 하는 일"입니다.상호 작용은 런타임에 객체가 수행하는 역할로 구현됩니다.이러한 개체는 데이터(도메인) 개체의 상태 및 메서드를 하나 이상의 역할에서 메서드(역할이 상태 비저장)와 결합합니다.적절한 DCI 스타일에서는 역할은 다른 오브젝트를 그 (메서드리스) 역할의 관점에서만 취급합니다.라는 특별한 역할이 있습니다.self현재 역할을 수행하는 개체에 바인딩됩니다.Role 메서드 내의 코드는 다음에서 메서드를 호출할 수 있습니다.self따라서 현재 객체의 데이터 부분의 메서드를 호출합니다.DCI의 한 가지 흥미로운 점은 이러한 바인딩이 실행 시에만 확실하게 유지된다는 것입니다(다양한 접근법과 규칙을 사용하여 바인딩이 성공하도록 C++ 템플릿을 사용할 수 있습니다).즉, 역할 메서드인 상호작용이 일반적이라는 것을 의미합니다.실제로 일부 DCI 구현에서는 역할에 범용 또는 템플릿을 사용합니다.

역할은 시스템 내 일부 엔티티에 대한 최종 사용자의 멘탈 모델에 해당하는 상태 비저장 프로그래밍 구성입니다.역할은 책임의 집합을 나타냅니다.로컬 오브젝트 지향 프로그래밍은 오브젝트나 클래스를 다양한 책임으로 언급하는 반면 DCI는 이를 역할로 귀속시킵니다.사용 사례에 참여하는 개체는 특정 역할을 수행한 결과로 수행하는 개체와 같은 책임이 있습니다.대부분의 최신 프로그래밍 언어에는 역할을 표현하는 방법 및 객체에 대한 역할 메서드의 주입을 표현하는 방법이 있으며 구현 기술은 언어에 따라 다릅니다.주입은 Ruby나 Python과 같은 언어에서는 런타임에 완전히 역동적일 수 있습니다.Smalltalk-Squeak, Scala, C++와 같은 언어에서는 더 정적입니다.Qi4j 프로그래밍 환경은 Java [1]객체에 Role 메서드 주입을 표현하는 방법을 제공합니다.인터페이스의 Java 8 디폴트 방식을 사용하면 롤을 쉽게 구현할 수 있습니다.

예를 들어, 위의 송금 사용 사례에서는 Source Account 및 Destination Account의 Role 메서드에 의해 실제 송금이 이루어집니다.

DCI의 특징

DCI는 통신 객체의 모든 허용 가능한 네트워크를 공통 토폴로지를 공유하는 네트워크로 제한합니다(사용 사례별로 하나씩).이러한 네트워크는 DCI 역할 간의 상호작용에서는 명시적이지만, 고전적인 객체 방향에서는 출현합니다.역할은 이러한 토폴로지의 노드입니다.이 노드를 점유할 수 있는 모든 객체의 동작을 부분적으로 분류한 것입니다.토폴로지는 시스템의 런타임 구조에 대한 설명입니다.

객체 지향 프로그램은 실제 객체 간의 관계가 복잡하고 역동적이라는 점에서 객체의 복잡하고 동적인 네트워크입니다.레스토랑 웨이터를 생각해 보세요.웨이터는 여러 가지 측면에서 볼 수 있는 복잡한 객체입니다. 예를 들어, 나의 웨이터(예를 들어, 오늘 밤 메뉴를 설명하고 주문을 받는 사람), 레스토랑의 종업원(일정 급여와 근무 시간), 레스토랑의 사람(점유 제한 150명)입니다.Waiter 클래스가 Waiters의 실제 본질(오브젝트 지향의 본질)을 포착하기 위해 작성되었다면 이러한 모든 관점을 지원하려면 매우 복잡해야 합니다.

DCI에서는 이러한 다양한 뷰가 역할에 반영됩니다.실행 시 역할은 개체의 ID입니다.사용 사례(와인 서빙 등)를 제정하는 동안 역할 웨이터는 항상 단일 객체를 명확하게 식별합니다.테이블에 웨이터가 여러 명 있을 수 있다고 주장할 수 있습니다.그러나 역할 이름 HeadWaiter와 Busboy에서 볼 수 있는 것과 같이 사용 사례 내에서는 책임에 차이가 있을 수 있습니다.책임이 동일하더라도, Waiter-1과 Waiter-2 또는 Waiter-1을 위해 소프트웨어를 작성하려는 경우 Waiter 벡터의 개별(이름 있는) 요소로 기술됩니다.따라서 HeadWaiter와 같은 역할은 식별자, 즉 핸들이 되며, 이 식별자에 의해 유스케이스에서는 오브젝트가 서로 참조합니다.

DCI는 종업원 파트, 웨이터 파트 및 개인 파트의 구성이 아닌 객체로 웨이터를 인식합니다.개체는 사용 사례와 독립적으로 고유한 ID를 가집니다. 이것이 DCI의 데이터 측면입니다.역할들은 그들의 사물에 대한 별칭 이름들이지만 결코 개별적인 사물이 아니다; 그것은 자기 정신분열증을 야기할 것이다.그런 의미에서 모든 웨이터는 호모 사피엔스다.이것은 웨이터의 기본적인 시스템입니다.오브젝트는 관련된 사용 사례에 따라 여러 가지 가능한 ID를 가집니다.이 ID의 표면은 DCI의 인터랙션 패싯의 일부를 구성합니다.이것들은 (보통 더 흥미로운) 시스템의 기능 부분입니다.단, DCI에서는 런타임에 이러한 관점을 모두 전달하는 객체는 1개뿐입니다.이러한 관점은 코딩 시 다르게 그룹화될 수 있습니다.코드는 오브젝트를 횡단하는 유스케이스 구조에 의해 지배되며 DCI의 인터랙션 패싯의 일부이기도 합니다.

DCI 를 사용하면, 유스케이스의 제정중에 오브젝트가 1개 이상의 역할을 맡을 수 있습니다.즉, 각 사용 사례 제정 시 개체는 역할 식별자에 다시 바인딩됩니다.이러한 역할은 역할 유형이라고 하는 인터페이스를 추론합니다.각 오브젝트는 사용 사례마다 (극적 의미에서) 새롭게 "재캐스트"됩니다.하나의 역할이 하나의 객체에만 바인딩되어 있지만 하나의 객체가 여러 역할을 수행할 수 있습니다.예를 들어, HeadWaiter는 화재 검사 중에 레스토랑의 모든 거주자를 세는 사용 사례에 관여할 수 있으며, HeadWaiter 역할과 함께 개인 역할도 수행합니다.단일 개체는 사용 사례를 수행하는 데 필요한 두 역할의 동작을 지원합니다.

요약하면 DCI 아키텍처는 다음과 같은 속성을 특징으로 하는 경향이 있습니다.

  • 데이터 모델은 동작의 파티션이 아닌 도메인 구조를 반영합니다.
  • 유스케이스 도입 시에 오브젝트가 동적으로 역할을 담당한다.
  • 사용 사례의 모든 역할은 사용 사례 제정 시작 시 컨텍스트에 의해 결정된 객체에 의해 수행된다.
  • 코드 내 역할 간 상호작용 네트워크(즉, 코딩 시)는 런타임에 대응하는 객체 네트워크와 동일하다.
  • 이러한 네트워크는 사용 사례 제정 시마다 재작성될 수 있습니다.
  • 역할은 사용 사례 수명에 따라 범위를 넘나들지만, 이러한 역할을 수행할 수 있는 개체는 여러 사용 사례 수명에 걸쳐 지속될 수 있으며, 잠재적으로 자신의 수명 동안 여러 역할을 수행할 수 있습니다.

실행 모델

DCI는 이벤트 중심 프로그래밍 패러다임으로 생각할 수 있습니다.이 패러다임에서는 (모델 뷰 컨트롤러(MVC) 아키텍처에서 사람의 제스처로서) 어떤 이벤트가 유스케이스를 트리거합니다.사용 사례는 단수명 또는 장기수명이 될 수 있습니다.이벤트는 트리거라고 불리며 DCI가 내장된 환경에서 처리됩니다.이 환경은 기존의 MVC 아키텍처 또는 기타 시스템레벨 코드의 컨트롤러가 될 수 있습니다.

트리거에 의해 환경은 컨텍스트개체를 인스턴스화합니다.오브젝트 유형은 트리거 또는 시스템 상태 또는 둘 다에 대한 정보에 따라 발생하는 사용 사례에 따라 선택됩니다.예를 들어 현금 인출기에는 송금, 인출, 입금, 잔액 조회 등을 위한 별도의 컨텍스트 클래스가 있을 수 있습니다.환경이 Context 개체를 인스턴스화하면 트리거 메서드를 호출하여 사용 사례 제정을 시작합니다.

위에서 설명한 바와 같이, 각 컨텍스트는 사용 사례 제정에 참여하는 역할의 설계 범위를 제공합니다.이러한 역할을 수행할 개체를 할당하는 것은 컨텍스트의 작업입니다.

  1. 콘텍스트는 먼저 이 사용 사례 제정에서 참여해야 할 개체를 찾습니다.이러한 오브젝트는 환경 내, 데이터베이스 내, 즉석에서 작성할 수 있습니다.DCI는 이러한 오브젝트를 제한하지 않습니다.컨텍스트 내에는 항상 특정 역할을 수행하는 인스턴스가 최대 1개 있습니다.
  2. 둘째, 콘텍스트는 각각의 역할을 수행하기 위해 단일 개체를 할당합니다(단, 단일 개체가 단일 컨텍스트에서 여러 역할을 수행하는 경우가 많습니다).강력한 동적 언어(Ruby, Python)에서는 컨텍스트가 Role 메서드를 개체에 주입합니다.대부분의 동적 언어에서 현존하는 오브젝트는 언제든지 임의의 역할을 수행하도록 요구받을 수 있습니다(물론 일부 오브젝트-역할 조합은 의미가 없을 수 있습니다).오브젝트와 역할의 무의미한 조합은 다음과 같습니다.MESSAGE NOT UNDERSTOOD실행 시 Role 메서드가 호출된 경우).보다 정적으로 입력된 언어(Scala, C++)에서는 오브젝트가 Role 메서드를 지원하도록 사전에 준비가 되어 있어야 합니다.예를 들어 Scala는 도메인 클래스의 기본 논리와 역할 구현에 사용되는 특성의 사용 사례 논리를 결합한 익명 클래스를 만듭니다. 역할이 인스턴스화되면 도메인 개체에 효과적으로 할당됩니다.
  3. 셋째, 컨텍스트는 첫 번째 개체에서 역할 메서드를 호출하여 사용 사례에 참여합니다.
  4. 이후 역할들은 서로의 방법을 호출하여 사용 사례를 수행합니다.Role 메서드는 다음에서 메서드를 호출할 수 있습니다.self현재 역할을 수행하는 객체에 의해 처리됩니다.이것은 Roles가 현재 재생 중인 객체의 기본적인 데이터 조작을 호출하는 방법입니다.

DCI의 실장

DCI는 데이터 모델에서 사용 사례를 분리하는 설계 프로세스에 의존합니다.데이터 모델은 대부분의 경우 비공식 도메인 분석을 기반으로 합니다.최종 사용자의 시스템 기능 모델을 특징짓는 역할은 사용 사례에서 비롯됩니다.

구현 기술은 프로그래밍 언어에 따라 다릅니다.역할은 일반, 템플릿, 클래스 또는 특성과 같은 구조로 표현된다는 것이 많은 접근법의 공통점입니다.기본 도메인 로직을 위한 코드는 기존의 객체 지향 관행과 가장 일반적으로 사용되는 클래스를 따라 별도로 구현됩니다.각 역할의 코드는 사용 사례 제정 중에 재생되는 도메인 개체에 삽입됩니다.역할을 구현하려면 보통 메서드 주입이 필요합니다.특성은 메서드 주입을 지원하는 일반적인 프로그래밍 언어 기술 중 하나입니다.Scala와 같은 일부 언어는 특성을 기본적으로 지원하며, 다른 언어(예: Ruby 및 Python)는 메서드의 런타임 주입을 허용합니다.Java에서는 DCI를 지원하려면 주석을 기반으로 한 사전 컴파일러 트릭이 필요합니다.

구현 예로는 Smalltalk-Squeak,[2][3] C++,[4] C#,[5] Ruby,[6] JavaScript,[7] Python, Qi4J([8]Java), Scala,[9] Perl,[10] PHP가 있으며, DCI의 작성자가 관리하는 fulloo.info 사이트에 추가되어 있습니다.

역사

DCI는 MVC의 발명가이기도 한 Trygve Reenskaug에 의해 발명되었다.DCI의 현재 공식은 대부분 Reenskaug와 James O의 작품이다. 코플린[citation needed]

DCI는 주로 역할 기반 모델링에 대한 Trygve [11]Reenskaug의 연구에서 비롯되었습니다.Trygve는 오래 전부터 Roles가 프로그래머가 오브젝트에 대해 생각하는 방법에 있어서 중심적인 역할을 하고 있으며, 프로그래밍 언어 테크놀로지의 클래스 베이스의 진보가 프로그램 내의 오브젝트에 대해 생각할 동기를 상당 부분 빼앗아 갔다는 것을 인식하고 있었습니다.그 결과 실행 시 프로그램에 대해 추론하는 것이 어려워졌습니다.또한 객체 지향 프로그래밍 언어가 프로그램 로직을 표현하기 위한 클래스만을 제공한다는 사실은 프로그래머가 동작을 기술하기 위한 데이터의 구조적 레이아웃에 좌우되도록 했습니다.이것은 역할 경계에서의 동작을 기술하는 것에 비하면 부자연스럽습니다.결과적으로 Fortran의 [citation needed]절차 프로그램보다 프로그램 동작을 추론하는 것이 더 어려워졌습니다.

Trygve는 추론할 수 있는 프로그램 구조를 만드는 것이 중요하다고 느꼈고, 2000년부터 이러한 아이디어를 사회화하기 시작했습니다.2006년까지 그는 디자인 모델을 운용할 수 있게 되었고, 2008년 특성에 관한 Schérli의 작품을 발견함으로써 이러한 아이디어의 자연스러운 프로그래밍 언어 표현을 가능하게 하는 열쇠가 되었습니다.그는 스퀵으로 작성된 아기 프로그래밍 환경에서 아이디어를 프로토타입으로 만들었습니다.Jim Coplien은 약 2007년에 Trygve에 입사하여 2008년 중반에는 C++로 시제품을 가동했습니다.Steen Lehmann, Rickard Oberg 및 Niclas Hedhman은 Qi4j [1]프레임워크를 통해 향후 1년 정도 이러한 아이디어를 Ruby 및 Java에 적용하는데 박차를 가했습니다.2008년 9월 덴마크에서 열린 JaOO 컨퍼런스에 이어 많은 언어 적응이 이루어졌습니다.2010년에 Rune Lund-Söltoft가 Marvin 언어를 만들었습니다.DCI를 네이티브로 지원하는 최초의 언어 빌드입니다.Marvin은 주로 "DCI를 뺀 주입"이라는 개념을 케이스에 보여주기 위한 개념 증명으로 사용되었습니다.이전 구현의 대부분은 컨텍스트 밖에서 볼 수 있는 방식으로 역할 수행자 개체를 변경했습니다.James Coplien은 DCI를 지원하는 최초의 언어 빌드인 trygve를 만들었습니다.

오브젝트 지향 프로그래밍의 진화를 위해 언어 및 패턴 수준에서 취해진 다양한 접근법은 DCI와 다양한 수준으로 일치합니다.

  • mixins는 특정 What-the-system 기능의 코드를 클로즈드 형식으로 캡슐화하는 방법입니다.단, 복수의 mixin을 하나의 유닛에 링크하는 일관된 메커니즘은 없습니다.엄밀한 [citation needed]의미에서는 아니지만 DCI의 역할 개념을 구현하기 위해 사용할 수 있습니다.
  • 멀티 디스패치는 알고리즘을 실행에 관여하는 오브젝트로부터 보다 완전하게 분리하기 위한 초기 시도입니다.이것은 DCI가 공통의 반복 알고리즘을 개별 오브젝트에 개별적으로 현지화할 수 있는 코드 fragment로부터 분리함으로써 보완할 수 있습니다.DCI는 개념적으로 매우 이질적인 유형의 많은 객체 집합에 걸쳐 닫힌 형태의 단일 알고리즘을 더 폭넓게 재사용할 수 있도록 합니다.DCI의 Context 객체는 여러 [citation needed]디스패치를 사용하는 언어의 디스패치 메커니즘과 유사한 명시적인 인텔리전스 디스패처와 같은 역할을 합니다.
  • Self와 같은 진정한 객체 지향 프로그래밍 언어는 클래스 풀 프로그래밍과 객체 실행이라는 이분법을 분해하여 프로그래머가 런타임 객체에 집중할 수 있도록 합니다.DCI는 콘텍스트 및 역할 [citation needed]메서드 간의 정적 관계에 대한 코드 수준의 지식을 복원합니다.
  • 의존성 주입은 실행 시 오브젝트의 일부 실행을 자유롭게 재바인드할 수 있는 외부 오브젝트에 "아웃소싱"할 수 있도록 함으로써 오브젝트의 기능을 변경하는 오랜 접근법입니다.의존성 주입의 대부분의[which?] 구현은 DCI의 구현이 적절하게 다루어지는 자기 정신 분열증 [citation needed]문제를 야기한다.Elmo 등의 시스템에서는 이 접근방식을 사용합니다.이 접근방식은 메서드의 모호성과 중복된 데이터 멤버 [12][full citation needed]이름을 해결하기 위해 복잡성이 증가합니다.
  • 멀티패러다임[13] 설계는 C++의 설계원리에 따라 절차설계에 대한 동작과 오브젝트에 대한 구조요소에 따라 동작과 구조를 분리하여 이들 사이에 자유로운 접근을 허용한다.DCI 접근방식은 설계와 일반 [citation needed]응집성의 절차적 부분과 구조적 부분 간의 관계를 표현하는 데 있어 개선될 수 있다.

객체 지향 프로그래밍의 과제는 패러다임 수준에서 문제를 해결함으로써 해결할 수 있습니다.

  • 애스펙트 지향 프로그래밍(AOP)은 아마도 DCI와 관련된 가장 가까운 역사일 것입니다.Aspects의 대부분의 사용은 프로그래머의 관점과 밀접하게 관련되어 있으며, 주어진 포인트 컷에 대한 소프트웨어의 동작을 잘 이해하기 위해서는 강력한 도구 지원이 필요합니다.주된 차이점은 DCI에서는 알고리즘의 구조가 프라이머리이며 외부 코드와의 분리에 중점을 두고 있어 코드 가독성을 향상시킨다는 것입니다.AOP에서는 포인트 컷과 조언이 동일한 중요성을 가지며, 물리적으로는 분리되어 있지만, 그 조언은 포인트 컷에서 침습적이기 때문에 코드를 이해하기 위해 함께 이해해야 한다.AOP는 코드의 1차 구조를 크로스 컷하는 개별 로컬 수정의 관련 컬렉션의 관리 그룹을 제공하는 반면 DCI는 기존 객체 메서드를 호출하는 퍼스트 클래스 분석 스탠딩을 가진 알고리즘의 의미 표현입니다.DCI는 많은 조언을 받아 그 일부를 다수의 정규화된 포인트 [citation needed]컷에 주입하는 방법으로 생각할 수 있습니다.
  • 역할 지향 프로그래밍은 애스펙트 지향 프로그래밍, 개념 모델링 등의 아이디어를 통합합니다.초기 시도(1991)는 독립적인 [15]방식으로 역할을 정의했지만, 보다 최근의 접근법(2002년 이후)은 역할이 상황에 따라 달라진다는 것을 강조하는 데 수렴한다(또한 "팀" 또는 "기관").역할 지향 프로그래밍에서 역할은 DCI의 데이터 역할 이분법에 해당하는 일부 본질적(또는 기본) 엔티티에 대해 정의됩니다.문맥의 개념은 두 접근법 모두에서 본질적으로 동일합니다.두 방법 모두 역할 그룹 간의 상호 작용을 강조합니다.
몇 가지 차이점을 식별할 수 있습니다.역할 지향 프로그래밍은 객체 지향 프로그래밍 언어에 역할 지원을 추가하는 데 중점을 두고 프로그래밍 언어의 표현력을 높이고 더 많은 설계를 가능하게 하는 데 중점을 두고 있습니다.이에 비해 DCI는 정신 모델을 포착하는 방법에 초점을 맞추고 있으며, 이 방법을 부분적으로 DCI에 대응하는 법적 설계에 대한 제한으로 정의한다.예를 들어 다음과 같습니다.DCI의 작성자는 상속의 사용을 권장하지 않는 경향이 있습니다(예를 들어 "DCI 내에서는 역할을 상속하지 않습니다."). 반면 역할 지향 프로그래밍은 다른 개념과의 자유로운 조합을 지원하는 객체 지향 프로그래밍의 중심 개념으로 상속을 수용합니다(또한 강화합니다).DCI는 자기정신분열증은 피해야 한다고 강조하는 반면, 역할 지향 프로그래밍은 정신분열증이 더 이상 문제가 아니라 좀 더 유연한 설계의 촉진제였던 방식으로 분할된 객체를 관리해야 한다고 주장했다.DCI 저자들에 의한 최근의 논문은 자기 분열증이 Dijkstra 알고리즘의 [20]수정된 구현에 기초한 반례를 사용하는 역할 지향 프로그래밍에서 여전히 문제라고 주장한다.이와 같이 DCI는 단점을 완전히 회피하기 위해 상속의 이점을 희생하는 반면 역할 지향 프로그래밍은 위험과 일반적인 장점 간의 균형을 중시하는 완화 접근법을 취합니다.

레퍼런스

  1. ^ a b Qi4j 프레임워크
  2. ^ Trygve Reenskaug의 객체 지향 프로그래밍의 상식, http://heim.ifi.uio.no/~trygver/2009/triensense.pdf
  3. ^ 완전한 OO DCI 문서 C++ 예, http://fulloo.info/Examples/C++Examples/index.html
  4. ^ GitHub의 C# 소스 코드, https://github.com/programmersommer/DCISample
  5. ^ Object-Composition Google 그룹의 루비 소스 코드, https://groups.google.com/group/object-composition/browse_thread/thread/561f638b43f1b960 #17.10.2009
  6. ^ Object-Composition Google 그룹의 JavaScript 소스 코드, https://groups.google.com/group/object-composition/browse_thread/thread/8ec4cf18e127cc3e # 17.10.2009
  7. ^ "Roles: Role based software development".
  8. ^ Qi4j 소스코드(Object-Composition Google group, https://groups.google.com/group/object-composition/browse_thread/thread/fe317e615b9008fe #17.10.2009)
  9. ^ CPAN 출시: https://metacpan.org/release/DCI Wayback Machine에서 2012-01-24 아카이브 완료
  10. ^ Google의 PHP 소스 코드(https://code.google.com/p/php-coredci)
  11. ^ 트리지브 렝스카우그오브젝트 조작:OORAM 소프트웨어 엔지니어링 방법.프렌티스 홀, 1995년
  12. ^ James Leigh, Elmo 사용자 가이드, http://www.openrdf.org/doc/elmo/1.5/user-guide.html, Wayback Machine에서 2011-07-21 아카이브 완료
  13. ^ 제임스 코플린, C++용 멀티패러다임 디자인애디슨 웨슬리, 1998년
  14. ^ Friedrich Steimann, 객체 지향 및 개념 모델링에서의 역할 표현, 2000, http://www.fernuni-hagen.de/ps/veroeffentlichungen/zeitschrift_46129.shtml 2016-10-07 Wayback Machine에서 아카이브됨
  15. ^ Joel Richardson 및 Peter Schwarz, Aspects: 오브젝트를 확장하여 여러 독립된 역할을 지원, 1991년, http://www.informatik.uni-trier.de/~ley/db/conf/sigmod/RichardsonS91.html Wayback Machine에서 2007-10-17 아카이브 완료
  16. ^ Stephan Herrmann, 오브젝트 팀: 크로스컷 콜라보레이션을 위한 모듈화 개선, http://www.objectteams.org/publications/index.html#NODe02, 2002
  17. ^ Guido Baldoni 등, 조정 구조로서의 역할: powerJava 소개, 2005, http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.77.6337
  18. ^ J. Coplien, Object-Composition Google 그룹에 게시됨, https://groups.google.com/forum/?hl=en#!topic/object-composition/haza-J2Doz8 21.10.2010
  19. ^ Stephan Herrmann, Demystifying Object 조현병, 2010, http://www.objectteams.org/publications/index.html#MASPEGHI10
  20. ^ 제임스 O.Coplien, and Trygve Mikkjel Heyerdahl Reenskaug, 데이터, 컨텍스트 및 상호작용 패러다임.게리 T에서.Leavens (Ed.) : 시스템, 프로그래밍 및 응용 프로그램 컨퍼런스:Software for Humanity, Splash '12, Tucson, 미국 AZ, 2012년 10월 21일부터 25일까지ACM 2012, ISBN 978-1-4503-1563-0, 페이지 227-228, http://dl.acm.org/citation.cfm?id=2384782&dl=ACM&coll=DL.

외부 링크