HIGHT(객체 지향 설계)

GRASP (object-oriented design)

General Responsibility Assignment Software Patterns(또는 원칙)는 약칭 ALGEL크레이그 라만이 1997년[citation needed] 펴낸 저서 UML과 Patternes 적용에서 처음 발표한 "객체 설계와 책임 배정의 9가지 기본 원리"[1]: 6 세트다.

HIGHT에서 사용되는 다른 패턴과 원칙은 제어기, 생성자, 양방향, 정보 전문가, 낮은 결합, 높은 응집력, 다형성, 보호되는 변형, 순수한 제작이다.[2]이 모든 패턴은 많은 소프트웨어 개발 프로젝트에서 공통적으로 발생하는 소프트웨어 문제를 해결한다.이러한 기법들은 새로운 작업 방식을 창조하기 위해 발명된 것이 아니라, 객체 지향 설계에서 오래되고 시도되고 시험된 프로그래밍 원리를 더 잘 문서화하고 표준화하기 위해 발명되었다.

Larman은 "소프트웨어 개발을 위한 중요한 설계 도구는 설계 원리에 대해 잘 교육된 마음이다"라고 말한다.UML도 아니고 다른 기술도 아니다고 말했다.[3]: 272 그러므로, HIGHT 원칙은 정말로 정신적인 도구 집합이며, 객체 지향 소프트웨어의 설계에 도움을 주는 학습 보조 수단이다.

패턴

객체 지향 설계에서 패턴은 새로운 맥락에서 적용될 수 있는 문제와 해결책에 대한 명명된 설명이다. 이상적으로는 패턴이 다양한 상황에서 해결책을 적용하는 방법에 대해 조언하고 힘과 절충을 고려한다.특정 범주의 문제에서 주어진 많은 패턴은 사물에 대한 책임의 할당을 안내한다.

정보 전문가

문제:사물에 책임을 할당하는 기본 원칙은 무엇인가?
해결책:그것을 이행하는 데 필요한 정보를 가지고 있는 클래스에 책임을 부여한다.

정보 전문가(전문가 또는 전문가 원칙)는 방법, 계산 분야 등의 책임을 위임할 장소를 결정하는 데 사용하는 원칙이다.

정보 전문가의 원칙을 이용하여, 책임을 할당하는 일반적인 접근방식은 주어진 책임을 검토하고, 그 책임을 이행하는 데 필요한 정보를 결정한 다음, 그 정보가 저장되는 장소를 결정하는 것이다.

이것은 그것을 이행하는 데 필요한 가장 많은 정보를 가지고 학급에 책임을 지도록 이끌 것이다.[3]: 17:11

관련 패턴 또는 원리: 낮은 결합, 높은 응집력

크리에이터

객체 생성은 객체 지향 시스템에서 가장 일반적인 활동 중 하나이다.어떤 계급이 객체를 창조하는 것을 담당하는가는 특정한 계급의 객체들 사이의 관계의 근본적인 속성이다.

문제:객체를 만드는 사람A?
해결책:일반적으로 클래스 할당B사물을 창조할 책임A다음 중 하나 또는 그 이상이 적용되는 경우:

  • 의 인스턴스B의 예를 포함하거나 복합적으로 집계하다.A
  • 의 인스턴스B의 예를 기록하다.A
  • 의 인스턴스B의 예를 면밀히 이용하다.A
  • 의 인스턴스B의 예에 대한 초기화 정보를 가지고 있다.A창조물에 [3]: 16:16.7 물려주겠지

관련 패턴 또는 원리: 낮은 커플링, 공장 패턴

제어기

컨트롤러 패턴은 전체 시스템 또는 사용 사례 시나리오를 나타내는 비 UI 클래스에 시스템 이벤트 처리 책임을 할당한다.컨트롤러 개체는 시스템 이벤트를 수신하거나 처리할 책임이 있는 비사용자 인터페이스 개체다.

문제:누가 입력 시스템 이벤트를 처리해야 하는가?
해결책:유스케이스 컨트롤러는 유스케이스의 모든 시스템 이벤트를 처리하기 위해 사용되어야 하며, 둘 이상의 유스케이스에 사용할 수 있다.예를 들어 사용 사례 Create User and Delete User의 경우 두 개의 개별 사용 사례 컨트롤러 대신 UserController라는 단일 클래스를 가질 수 있다.

컨트롤러는 시스템 작동을 수신하고 조정("제어")하는 UI 계층을 벗어나는 첫 번째 개체로 정의된다.컨트롤러는 수행되어야 하는 작업을 다른 객체에 위임해야 하며, 그것은 활동을 조정하거나 통제한다.그것은 그 자체로 많은 일을 해서는 안 된다.HIGHT 컨트롤러는 정보시스템 논리 아키텍처에서 공통 계층이 있는 객체 지향 시스템에서 애플리케이션/서비스 계층[4](애플리케이션/서비스 계층과 도메인 계층을 명시적으로 구별했다고 가정)의 일부라고 생각할 수 있다.

관련 패턴 또는 원리: 명령, , 도면층, 순수 제작

양방향

양방향 패턴은 낮은 결합을 지원하고 두 요소 사이의 조정 책임을 중간 객체에 할당하여 두 요소 사이의 잠재력을 재사용한다.모델-뷰-컨트롤러 패턴에서 데이터(모델)와 데이터(뷰) 간 조정을 위한 컨트롤러 구성요소의 도입이 그 예다.이것은 그들 사이의 결합이 낮은 상태를 유지하도록 한다.

문제:두 가지(또는 그 이상) 사물의 직접적인 결합을 방지하기 위해 책임을 어디에 할당해야 하는가?낮은 커플링이 지원되고 재사용 가능성이 더 높게 유지되도록 객체를 분리하는 방법?

해결책:다른 구성요소나 서비스가 직접 결합되지 않도록 중간 객체에 조정 책임을 할당한다.
중개자는 다른 요소들 사이에 양방향성을 만든다.

로우 커플링

결합은 한 요소가 다른 요소에 얼마나 강하게 연결되어 있는지, 다른 요소에 대한 지식을 가지고 있는지 또는 의존하는지 측정하는 척도다.낮은 결합은 다음과 같은 편익에 대한 책임을 할당하는 방법을 지시하는 평가 패턴이다.

  • 계급간의 의존도를 낮추고,
  • 한 클래스의 변화가 다른 클래스에 미치는 영향 감소
  • 높은 재사용 가능성.

높은 응집력

높은 응집력은 사물의 적절한 집중, 관리 용이성 및 이해가능성을 유지하려는 평가 패턴이다.높은 응집력은 일반적으로 낮은 결합을 지지하는데 사용된다.높은 응집력은 주어진 요소 집합의 책임이 강하게 연관되어 있고 다소 특정한 주제에 고도로 집중되어 있다는 것을 의미한다.프로그램을 클래스 및 서브시스템으로 세분화(올바른 경우)하는 것은 명명된 클래스와 서브시스템의 응집성을 높이는 활동의 예다.대안으로 낮은 응집력은 예를 들어 하위시스템의 요소 집합이 관련 없는 책임을 너무 많이 갖는 상황이다.구성 요소 간의 응집력이 낮은 서브시스템은 전체적으로 이해, 재사용, 유지 및 변경이 어려운 경우가 많다.[3]: 314–315

다형성

다형성 원리에 따르면, 유형에 따른 행동의 변화를 정의하는 책임은 이러한 변화가 발생하는 유형에 할당된다.이것은 다형 연산을 사용하여 달성된다.형식의 사용자는 형식에 기초한 명시적 분기가 아닌 다형 연산을 사용해야 한다.

문제:유형에 따라 대안을 처리하는 방법?플러그형 소프트웨어 구성 요소를 생성하는 방법
해결책:관련된 대안이나 행동이 유형(계급)에 따라 다를 경우, 그 행동에 대한 책임(다형연산을 사용한)을 그 행동이 변화하는 유형에 할당한다.(폴리모프리즘은 몇 가지 관련 의미를 갖는다.이 맥락에서, 그것은 "다른 객체의 서비스에 동일한 이름을 부여한다"는 것을 의미한다.

보호변동

보호되는 변형 패턴은 인터페이스로 불안정성의 초점을 감싸고 이 인터페이스의 다양한 구현을 만들기 위해 다형성을 사용함으로써 다른 요소(객체, 시스템, 서브시스템)에 대한 변화로부터 요소들을 보호한다.

문제:이러한 요소의 변동이나 불안정성이 다른 요소에 바람직하지 않은 영향을 미치지 않도록 객체, 서브시스템 및 시스템을 설계하는 방법?
해결책:예측된 변동 또는 불안정성의 지점을 식별하고, 그 주변에 안정적인 인터페이스를 만들기 위한 책임을 할당한다.

순수 제작

순수 날조란 문제 영역에서 개념을 나타내지 않는 등급으로, 특히 낮은 결합, 높은 응집력 및 파생된 재사용 가능성을 달성하기 위해 특별히 구성된다(정보 전문가 패턴으로 제시된 솔루션이 그렇지 않은 경우).이런 종류의 클래스를 도메인 중심의 설계에서는 "서비스"라고 부른다.

관련 패턴원칙 • 낮은 커플링• 높은 응집력.

참고 항목

참조

  1. ^ Craig Larman (2001). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (PDF) (2nd ed.). Prentice Hall. ISBN 0-13-092569-1.
  2. ^ Muhammad Umair (2018-02-26). "SOLID, GRASP, and Other Basic Principles of Object-Oriented Design". DZone.
  3. ^ a b c d Craig Larman (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd ed.). Pearson. ISBN 978-0131489066.
  4. ^ "Application Layer like business facade?". Yahoo! Groups (domaindrivendesign). Archived from the original on 2020-08-07. Retrieved 2010-07-15.