체크포인트: 설계 클래스
주제
- 클래스 이름은 클래스가 수행하는 역할을 정확히 반영합니다.
- 클래스 설명은 클래스의
목적을 명확히 나타냅니다.
- 클래스는 잘 정의된 단일 추상을 나타냅니다.
- 클래스 속성 및 조작은 모두
클래스의 책임을 수행하는 데 필요합니다.
- 각 클래스는 소규모의
일관적고 고유한 책임 세트를 나타냅니다.
- 클래스의 책임은 잘 정의되고 명확하게
내용을 설명하며 클래스의 목적과 밀접한 관련이 있습니다.
- 각 클래스는 상대적으로 자체 구성을 갖추고
있으며 다른 클래스와 약한 결합 상태를 유지합니다.
- 클래스 책임의 추상 레벨은
일관적입니다. (상위 레벨(어플리케이션 레벨)과 하위
레벨(구현 레벨) 책임은 혼합되지 않습니다.)
- 동일한 상속 계층 구조의 클래스는
고유한 클래스 속성, 조작 및 관계를 소유합니다. (모든 공통 속성, 조작 및 관계를 상속합니다.)
- 클래스 인스턴스의 전체 라이프라이클에
대해 설명합니다. 각 객체는 하나 이상의 유스
케이스 구현에 의해 작성, 사용 및 제거됩니다.
- 클래스는 유스 케이스 구현으로
설정된 작동 요구사항을 충족시킵니다.
- 요구사항 스펙에 포함된
클래스에 대한 모든 요구사항을 처리합니다.
- 클래스에 대한 수요(클래스
설명에 반영되며 순서 다이어그램의 객체에
의함)는 클래스의 상태 시스템과 일치합니다.
- 클래스의 모든 책임은 서로 관련이 있어
해당 책임의 일부를 사용하고 나머지 책임을 사용하지
않는 시스템에 클래스가 존재할 수 없습니다.
- 두 개의 클래스가 반드시 동일한 목적을 가질 필요는 없습니다.
- 일반화 계층 구조는 균형을 맞추어 계층
구조가 비정상적으로 수평 또는 깊은 구조인 클래스가 없습니다.
- 명확한 공통성이
상속 계층 구조에 반영되었습니다.
- 서브클래스 속성의 병합으로
보이는 수퍼클래스는 없습니다.
- 상속 트리의 양측에 중복 서브클래스를
포함하는 예, 직각 특성이 있는 상속
계층 구조에 중간 추상 클래스가 없습니다.
- 상속은 예를 들어 코드 또는 클래스
구조의 비트를 재활용하기 위한 구현 고려사항이
아닌 공통 설계 추상을 캡처하는 데 사용됩니다.
- 클래스 이름은 목적을 표시합니다.
- 클래스 이름은 프로젝트 설계
가이드라인에 지정된 이름 지정 규칙을 따릅니다.
- 각 조작의 이름은 설명적이며 쉽게 이해할 수 있습니다.
- 상태 시스템과 조작은 일치합니다.
- 상태 시스템과 조작은
클래스 작동에 대해 완벽하게 설명합니다.
- 각 조작의 매개변수는 번호,
이름 및 유형 모든 관점에 있어 정확합니다.
- 각 조작에 대한 구현
스펙은 올바릅니다(정의된 경우).
- 조작 서명은 대상
프로그래밍 언어의 표준을 준수합니다.
- 각 조작은 최소 하나의 유스 케이스 구현에서 사용합니다.
- 모든 클래스 관계는 클래스의
특정 조작을 지원하는 데 필요합니다.
- 각 속성은 단일 개념 사항을 나타냅니다.
- 각 속성의 이름은 설명적이며
속성에 저장된 정보를 정확하게 전달합니다.
- 집계 및 연관의 역할 이름은 연관 클래스
및 연관된 클래스 간의 관계에 대해 설명합니다.
- 관계의 다양성은 올바릅니다.
- 상태 시스템은 필수 작동을
나타내면서도 최대한 단순합니다.
- 상태 시스템에는 불필요한
상태 또는 전이가 포함되지 않습니다.
- 상태 시스템에는 명확한 컨텍스트가 있습니다.
- 모든 참조 객체는 포함 객체에서 볼 수 있습니다.
- 상태 시스템은 호율적이므로 시스템이
디스패치하는 조치가 정의하는 대로 시간 및
자원의 균형을 최적화하여 해당 작동을 수행합니다.
- 상태 시스템은 쉽게 이해할 수 있습니다.
- 상태 및 전이 이름은 시스템
도메인의 컨텍스트로 쉽게 이해할 수 있습니다.
- 상태 이름은 이미 발생한 내용이 아닌
현재 발생하고 있는 내용 또는 대기 중인 내용을 표시합니다.
- 상태 및 전이 이름은 상태 시스템에서
고유합니다. (엄격한 요구사항은 아니지만 고유한
이름을 강제 실행하기 위한 디버깅에 유용합니다.)
- 상태의 논리적
분류는 합성 상태에 포함됩니다.
- 합성 상태를 효과적으로
사용하여 복잡도를 줄였습니다.
- 전이 레이블은
전이의 기본 원인을 반영합니다.
- 세부사항 코드가 25행이 넘는 상태
전이에 대한 코드 단편은 없습니다. 대신 함수를
사용하여 전이 코드 복잡도를 효과적으로 줄였습니다.
- 중첩 깊이를 파악할 수 있도록 상태
시스템 중첩을 점검했습니다. 대부분의 복잡한 작동에도
일반적으로 하나 또는 두 가지 서브상태 레벨이면 충분합니다.
- 동시 서브상태 대신 활성 클래스를
사용했습니다. 활성 클래스는 대부분의 경우 동시
서브상태보다 쉽게 이해할 수 있는 바람직한 대안입니다.
- 오류 또는 유지보수 상태에 대해 설명했습니다.
- 확장 상태 변수 대신 서브상태를 사용했습니다.
몇 가지 변수를 테스트하여 전이가 발생해야 하는
상태를 판별하는 전이 감시 조건에 대한 증거가 없습니다.
- 상태 시스템은 플로우 도표와 다릅니다.
- 상태 시스템은 서브상태가 하나 뿐인 중첩
상태 시스템으로 구성되어 구조가 지나치게 복잡하지 않습니다.
중첩된 서브상태가 향후 설계 작업 또는
서브클래스 작성을 위한 플레이스홀더이고 올바른
선택을 한 경우, 일시적으로 승인할 수 있습니다.
| |
|