책임 중심 설계

Responsibility-driven design

책임 중심 설계는 객체 지향 프로그래밍의 설계 기술로, 클라이언트-서버 모델을 사용하여 캡슐화를 개선합니다.이는 객체가 담당하는 작업 및 객체가 공유하는 정보를 고려하여 계약에 초점을 맞춥니다.그것은 레베카 위프스-브록과 브라이언 윌커슨이 제안했다.

책임 중심 설계는 클래스가 보유한 데이터와 함께 클래스의 동작을 정의하도록 촉진하는 데이터 중심 설계와 정면으로 대조됩니다.데이터 중심 설계는 클래스 설계가 아닌 제어 흐름을 결정하기 위해 데이터를 사용하는 데이터 중심 프로그래밍과 다릅니다.

클라이언트/서버 모델에서는 클라이언트와 서버는 모두 클래스의 클래스 또는 인스턴스입니다.클라이언트 또는 서버는 항상 오브젝트를 나타냅니다.당사자 쌍방은 계약을 체결하고 이를 준수함으로써 정보를 교환한다.클라이언트는 계약에 지정된 요청만 수행할 수 있으며 서버는 이러한 [1]요청에 응답해야 합니다.따라서 책임 중심 설계는 특정 요청의 의도만 지정함으로써 요청 수행 방법 등의 세부 사항을 다루는 것을 피하려고 합니다.요구가 실행되는 정확한 방법의 지정은 서버에 비공개로 되어 있기 때문에 캡슐화가 증가한다는 이점이 있습니다.

서버의 캡슐화를 촉진하기 위해 Wirfs-Brock 및 Wilkerson은 클래스의 동작에 대한 외부 영향을 제한하는 언어 기능을 호출합니다.그들은 에펠 프로그래밍 언어처럼 구성원과 함수의 가시성을 정교하게 할 것을 요구한다.Newspeak 프로그래밍 언어에서는 짝수 클래스의 가시성을 더욱 세밀하게 제어할 수 있습니다.

개요

책임 중심 설계는 책임에 따라 특징지어지는 행동 추상화로서 대상에 초점을 맞춥니다.CRC 카드 모델링 기술은 이러한 행동 추상화를 생성하기 위해 사용됩니다.데이터 속성을 포함한 나머지 개체 구조는 나중에 [2]필요에 따라 할당됩니다.이를 통해 설계는 캡슐화를 개선하고 추상 클래스를 쉽게 식별할 수 있는 상속 유형 계층을 따를 수 있습니다.또한 고유 기능으로 간주되는 클라이언트를 기반으로 클래스를 그룹화할 수도 있습니다.

적절한 객체 지향 설계에는 규정된 요건을 충족하는 기능을 실현하기 위한 동작에 조기에 초점을 맞추고 구현 세부사항을 요건에 늦게 결합하는 것이 포함됩니다.이 접근방식은 특히 제어의 분산과 시스템 동작의 분산에 도움이 됩니다.이것에 의해, 고기능의 대규모 또는 분산형 시스템의 복잡함을 관리할 수 있습니다.마찬가지로 인지 모델, 지능형 에이전트 및 기타 지식 기반 시스템에 [3]대한 설명 기능을 설계하고 유지하는 데 도움이 될 수 있습니다.

구성 요소

그들의 책에서는 오브젝트 디자인: 저자들은 역할, 책임 및 협업,[4] 책임 중심 설계를 구성하는 다음과 같은 구성 요소를 설명합니다.

  • 응용 프로그램:소프트웨어 어플리케이션은 상호작용하는 [5]오브젝트 세트라고 불립니다.
  • 후보: 후보 또는 후보 오브젝트는 CRC 카드에 기술된 오브젝트 형태의 주요 개념입니다.그것들은 객체 [6]설계 과정에서 초기 발명의 역할을 한다.
  • 콜라보레이션:공동작업은 객체 또는 역할(또는 둘 다)[5]의 상호작용으로 정의됩니다.
  • CRC 카드: CRC는 후보, 책임, 공동작업자를 나타냅니다.후보 [7]기록을 위한 초기 설계에 사용된 색인 카드입니다.이 카드는 선이 없는 면과 선이 있는 면으로 나누어져 있습니다.
    • 안감면 내용:이 쪽에는 후보자의 이름, 책임 및 협력자가 기록됩니다.[7]
    • 줄 없는 측면의 내용:이쪽에는 후보자의 이름, 용도, 고정관념의 역할, 그리고 자신이 참여하는 패턴의 역할 이름 등 가치 있는 것이 [7]기록되어 있다.
  • 핫스팟: 핫스팟은 응용 프로그램에서 다양한 현상이 발생하는 지점입니다.핫스팟 [8]카드를 사용하여 기록된다.
  • 핫스팟 카드: 핫스팟 카드는 중요한 차이를 구별할 수 있도록 충분한 상세도로 다양한 내용을 기록하는 데 사용됩니다.CRC 카드와 마찬가지로 인덱스 [8]카드에서도 작성됩니다.이러한 카드의 구성 요소는 다음과 같습니다.
    • 핫스팟명
    • 변동에 대한 일반적인 설명
    • 변동이 발생하는 두 개 이상의 특정 예제

물건들

오브젝트는 기계와 같은 동작을 가진 것으로 설명되며 서로 연결해서 함께 동작할 수 있습니다.이러한 개체는 제대로 정의된 역할을 수행하고 스크립트로 작성된 응답 및 [5]정보를 캡슐화합니다.

  • 오브젝트 네이버:서브시스템의 [9]다른 용어입니다.이것은 [9]공동작업자의 논리적인 그룹화입니다.
  • 책임:책임이란 업무를 수행하거나 [5]정보를 알아야 하는 의무입니다.이것들은, 사용 시나리오에 따라서 한층 더 분류됩니다.
    • 공공의 책임:공공의 책임은 객체가 타인에게 서비스로서 제공하는 책임과 [10]타인에게 제공하는 정보입니다.
    • 개인 책임:사적 책임은 공공의 [10]책임을 지원하기 위해 개체가 취하는 행동입니다.
    • 하위 책임:때때로, 크고 복잡한 책임은 [11]하위 책임이라고 불리는 작은 책임으로 나누어집니다.그들은 그들이 하는 일에 따라 더욱 분류된다.
      • 하위 책임:여기에는 각 하위 [11]책임의 주요 단계가 포함됩니다.
      • 시퀀스의 책임:이는 하위 [11]책임의 실행 순서를 나타냅니다.

역할

오브젝트 역할이란 오브젝트에 의해 제공되는 일반적인 서비스의 외부 뷰를 말합니다.이것은 관련된 [5]책임의 집합입니다.클래스 또는 인터페이스로서 실장할 수 있습니다.그러나 인터페이스는 최종적으로 [12]작업을 수행하는 구체적인 클래스를 숨김으로써 유연성을 증가시키기 때문에 선호되는 구현입니다.

역할 고정관념: 역할 고정관념은 미리 정의된 [13]책임을 수반하는 단순화된 역할입니다.몇 가지 카테고리가 있습니다.

  • 컨트롤러: 이 역할을 구현하는 오브젝트는 다른 [13]오브젝트의 액션을 결정 및 세밀하게 지시합니다.
  • 코디네이터:이 역할은 다른 [13]사용자에게 작업을 위임하여 이벤트에 대응합니다.
  • 정보 보유자:정보 보유자는 정보를 [13]알고 제공한다.
    • 정보 프로바이더: 정보 프로바이더는 정보 프로바이더로서 정보의 관리와 유지보수에 있어서 보다 적극적인 역할을 담당합니다.이 구분은 디자이너가 좀 더 [14]구체적일 필요가 있을 때 사용할 수 있습니다.
  • 인터페이스:이 역할은 [13]응용 프로그램의 개별 부분 간에 정보 및 요청을 변환합니다.그것은 더욱 구체적인 역할로 나뉜다.
    • 외부 인터페이스: 외부 인터페이스 장치는 [14]자체 애플리케이션이 아닌 다른 애플리케이션과 통신합니다.주로 비개체 지향 API를 캡슐화하는 데 사용되며 [15]많은 협업이 이루어지지 않습니다.
    • 내부 인터페이스:시스템 [14]간 인터페이스라고도 합니다.오브젝트 네이버 [15]간의 가교 역할을 합니다.
    • 사용자 인터페이스:사용자 인터페이스 사용자는 UI에서 생성된 이벤트에 응답한 후 보다 적절한 [14][15][16]개체에 전달함으로써 사용자와 통신합니다.
  • 서비스 프로바이더:업무를 수행하고 컴퓨팅 [14]서비스를 제공하는 역할입니다.
  • 구조자:이 역할은 개체와 이러한 [14]관계에 대한 정보 간의 관계를 유지합니다.

제어 스타일

책임 중심 설계 프로세스에서 중요한 부분은 통제 스타일을 개발하게 되는 통제 책임의 분배입니다.제어 스타일은 서브시스템 간의 제어 흐름에 관한 것입니다.

  • 컨트롤의 개념 : 클래스 [17]간의 책임과 협업.
  • Control Centers: 제어 스타일을 개발하는 데 있어 중요한 측면은 소위 제어 센터의 발명입니다.제어와 조정을 담당하는 물체가 있는 [18]장소입니다.
  • [ Control Style Variations ]: 컨트롤 스타일은 3가지 다른 변형이 있습니다.그러나 제어 스타일은 다른 스타일보다 더 중앙 집중화되거나 위임된다고 할 수 있기 때문에 이러한 정의는 정확한 정의는 아닙니다.

집중 관리 스타일

이 제어 스타일은 어플리케이션 구조에 절차 패러다임을 부여하고 소수의 오브젝트 또는 단일 오브젝트에만 중대한 의사결정의 책임을 부여합니다.

종류들
  • Call-Return model : 어플리케이션 내의 오브젝트를 계층적으로 제어합니다.컨트롤은 루트에서 시작하여 아래로 이동합니다.순차적 모델에서 사용됩니다.
  • Manager 모델 : 어플리케이션 내의 오브젝트 제어는 1개의 오브젝트만으로 이루어집니다.일반적으로 동시 모델로 구현됩니다.케이스 스테이트먼트를 사용하여 시퀀셜모델로 실장할 수도 있습니다.
이점
  • 애플리케이션 로직은 한 곳에 있습니다.
단점들
  • 제어 로직이 지나치게 복잡해질 수 있음
  • 컨트롤러는 정보 보유자의 콘텐츠에 의존할 수 있다
  • 컨트롤러의 동작을 통해 오브젝트를 간접적으로 결합할 수 있습니다.
  • 유일하게 흥미로운 작업은 컨트롤러에서 수행됩니다.
사용 시기

의사결정이 적고 단순하며 단일 태스크와 관련된 경우.

위임된 제어 스타일

위임된 제어 스타일은 중앙 집중식 제어 스타일과 분산된 제어 스타일 사이에 있습니다.의사 결정의 일부와 액션의 대부분을 컨트롤 센터 주변의 객체에 전달합니다.각 인접 오브젝트에는 중요한 역할이 있습니다.이벤트 기반 모델이라고도 하며, 이벤트 처리를 요청하는 개체에 제어가 위임됩니다.

종류[참조]
  • 브로드캐스트모델 : 응용 프로그램 내의 모든 오브젝트에 이벤트가 브로드캐스트됩니다.이벤트를 처리할 수 있는 개체는 컨트롤을 획득할 수 있습니다.
  • Interrupt-drived model : 인터럽트를 처리하는 인터럽트 핸들러가 있어 인터럽트를 처리하는 오브젝트가 있습니다.
이점
  • 그것은 이해하기 쉽다.
  • 외부 코디네이터가 있어도 오브젝트를 스마트하게 만들어 무엇을 해야 하는지 알 수 있고 다른 어플리케이션에서 재사용할 수 있습니다.
  • 위임 코디네이터는 지배적인 컨트롤러보다 더 적은 수의 개체에 대해 알고 있는 경향이 있습니다.
  • 대화상자는 상위 레벨입니다.
  • 일반적으로 변경 사항이 더 적은 수의 개체에 영향을 미치기 때문에 변경하기가 쉽습니다.
  • 디자인 작업을 팀원들 간에 나누는 것이 더 쉽습니다.
단점들
  • 과도한 책임 분산은 약한 대상과 약한 협업으로 이어질 수 있습니다.
사용 시기

보다 전문화된 오브젝트에 작업을 위임하고 싶은 경우.

클러스터 제어 스타일

이 제어 스타일은 작업이 [19]조정된 객체 그룹 간에 제어가 고려되는 중앙 집중식 제어 스타일의 변형입니다.군집화된 제어 스타일과 위임된 제어 스타일의 주요 차이점은 의사결정 객체가 대부분 외부에 [20]있는 반면 군집화된 제어 스타일에서는 의사결정 객체가 제어 센터 내에 위치한다는 것입니다.

분산 제어 스타일

분산된 제어 스타일에는 제어 센터가 없습니다.로직은 오브젝트 전체로 분산되어 각 오브젝트를 작게 유지하고 그 사이에 가능한 [21]한 적은 의존관계를 구축합니다.

이점
  • 없음.
단점들
  • 동작 방법을 확인하려면 여러 개체에 걸친 서비스 요청 시퀀스를 추적해야 합니다.
  • 단일 객체가 크게 기여하지 않기 때문에 재사용이 용이하지 않음
사용 시기

절대.

선호하는 제어 스타일

광범위한 실험 결과를 수행한 후, 선임 경영진만이 위임된 제어 스타일과 중앙 집중식 제어 스타일을 사용하는 데 필요한 기술을 보유하게 됩니다.중간급 직원들에 [17]대한 언급은 없다.

레퍼런스

  1. ^ Wirfs-Brock, Rebecca; Wilkerson, Brian (1989). "Object-Oriented Design: A Responsibility-Driven Approach". ACM SIGPLAN Notices. 24 (10): 74. doi:10.1145/74878.74885.
  2. ^ Anthony J. H. Simons; Monique Snoeck; Kitty Hung (1998). "Design Patterns as Litmus Paper to Test the Strength of Object-Oriented Methods". Oois'98. pp. 129–147. CiteSeerX 10.1.1.130.8713. doi:10.1007/978-1-4471-0895-5_10. ISBN 978-1-85233-046-0.
  3. ^ Steven R. Haynes; Isaac G. Councill; Frank E. Ritter (2004). "Responsibility-Driven Explanation Engineering for Cognitive Models".
  4. ^ Wirfs-Brock, Rebecca; McKean, Alan (2003). Object Design: Roles, Responsibilities, and Collaborations. Indianapolis, IN: Addison-Wesley. ISBN 978-0201379433.
  5. ^ a b c d e Wirfs-Brock & McKean 2002, 페이지 3
  6. ^ Wirfs-Brock & McKean 2002, 페이지 58
  7. ^ a b c Wirfs-Brock & McKean 2002, 페이지 61
  8. ^ a b Wirfs-Brock & McKean 2002, 페이지 72
  9. ^ a b Wirfs-Brock & McKean 2002, 페이지 17
  10. ^ a b Wirfs-Brock & McKean 2002, 페이지 126
  11. ^ a b c Wirfs-Brock & McKean 2002, 페이지 168
  12. ^ Wirfs-Brock & McKean 2002, 페이지 340
  13. ^ a b c d e Wirfs-Brock & McKean 2002, 페이지 4
  14. ^ a b c d e f Wirfs-Brock & McKean 2002, 93페이지
  15. ^ a b c Wirfs-Brock & McKean 2002, 페이지 165
  16. ^ Wirfs-Brock & McKean 2002, 페이지 164
  17. ^ a b Eric, Arisholm; Dag I.K., Sjoberg (2004). "Evaluating the effect of a delegated versus centralized control style on the maintainability of object-oriented software". IEEE Transactions on Software Engineering. 30 (8): 521–534. doi:10.1109/TSE.2004.43. S2CID 6396127.
  18. ^ Wirfs-Brock & McKean 2002, 페이지 196
  19. ^ Wirfs-Brock & McKean 2002, 197페이지
  20. ^ Wirfs-Brock & McKean 2002, 페이지 213
  21. ^ Wirfs-Brock & McKean 2002, 페이지 30

참고 문헌

  • 객체 지향 설계: 책임 중심 접근법.오브젝트 지향 프로그래밍 시스템, 언어 및 애플리케이션에 관한 컨퍼런스 프로시저(미국 루이지애나주 뉴올리언스, 1989년 10월 2일~06일)OPSLA '89.ACM 프레스, 뉴욕, 71-75
  • Wirfs-Brock, Rebecca; McKean, Alan (November 2002). Object Design: Roles, Responsibilities, and Collaborations. Addison Wesley. ISBN 978-0-201-37943-3.