책임 기반 모델링과 클래스 변경 이유

Question

~ 안에 이것 내가 읽은 텍스트

영광스러운 책임 인 구성 요소에주의하십시오.구성 요소는 시스템에 목적이있는 추상화를 캡처해야합니다.의미있는 구성 요소로서 한 순간에 나타나는 것은 실제로 그 자체로 남겨진 단일 책임 일뿐입니다.그 책임은 구성 요소에 할당 될 수 있습니다.

이것은 나를 혼란스럽게 한다.클래스에 변경 이유가 하나만 있어야 한다면 책임도 하나인 것처럼 보입니다.하지만 지금은 이것을 너무 좁게 생각하고 있는 것 같습니다.책임 기반 모델링의 맥락에서 책임에 대한 설명과 변경 이유를 제공할 수 있습니까?클래스에 두 가지 이상의 책임이 있으면서도 변경해야 할 이유가 하나 있을 수 있습니까(또는 그 반대)?

Answer 1

클래스 흡입 가능성-실사 모델링 (또는 디자인)에 대해 읽으십시오.

http://www.agilemodeling.com/artifacts/crcmodel.htm

http://alistair.cockburn.us/using+crc+cards

http://users.csc.calpoly.edu/~jdalbey/swe/casestudies/atmsim/crcmodel.html

http://c2.com/doc/oopsla89/paper.html

수업에는 몇 가지 책임이있을 수 있습니다. 항상 단일 "사물"을 나타냅니다.

규칙을 변경 해야하는 한 가지 이유는 책임에 적용되지 않습니다. 기간.

"변경해야 할 이유"는 다음과 같이 사용해야합니다.

1. "1"을 의미하지 않습니다. "가능한 한 적은 적은 수준"을 의미합니다.

2. 클래스의 "인터페이스"또는 "기본 추상화"또는 "개념"에 적용됩니다. 수업은 몇 가지 개념을 캡슐화해야합니다. 핵심 개념이 바뀌면 클래스가 변경됩니다.

3. 많은 단순한 것들이 복잡한 것보다 낫습니다. 간단한 것을 재결합하고 수정하는 것이 더 쉽습니다.

4. 모든 복잡한 내부에는 자유를 얻으려고 노력하는 많은 단순한 것들이 있습니다.

5. "간단한"을 정의하기는 어렵지만 "하나의 개념"은 가깝습니다. "변경하기위한 한 가지"는 또한 "단순성"에 대한 유용한 테스트입니다.

6. 마지막으로, "변경해야 할 이유"는 문자 그대로 "1"을 의미하지 않습니다.

Answer 2

내가 이해하는 바에 따르면 "구성 요소에 대한 책임을 미화하는 것"의 위험은 시스템 구성 요소에 대한 책임을 직접 변환하지 않도록 주의해야 함을 의미합니다.

예를 들어, 이메일 시스템에서 사용자는 수신자에게 메시지를 보내기 위해 시스템에 접근할 수 있습니다.이를 가능하게 하는 것은 시스템의 책임입니다.

사용자는 이메일을 읽고 답장하기 위해 시스템에 접근할 수도 있습니다.이를 가능하게 하는 것도 시스템의 책임입니다.

하지만 이는 시스템에 "새 이메일 시작"과 "이메일에 회신"이라는 두 가지 구성 요소가 필요하다는 의미입니까?아니요.일반적인 "이메일 작성" 구성 요소는 두 가지 요구 사항을 모두 처리할 수 있습니다.

따라서 이 경우 "이메일 작성" 구성 요소는 "새 메일 시작" 및 "메일에 회신"이라는 사용자 목표를 담당합니다.그러나 핵심 개념("이메일 구성 방법")이 변경되는 경우에만 변경하면 됩니다.

Cockburn의 다음 문구를 다시 자세히 살펴보십시오."구성 요소는 시스템에서 목적을 갖는 추상화를 캡처해야 합니다."목적 시스템에서 (변경 이유)는 사용자의 목표(책임)를 만족시키려는 목적과 동일하지 않습니다.

긴 이야기를 짧게 만들려면:내가 이해한 바에 따르면 구성 요소에는 이상적으로 하나의 핵심 개념이 있습니다.여러 가지 책임이 있을 수 있습니다.그러나 제가 보기에 하나의 책임이 하나 이상의 구성 요소에 할당될 수는 없습니다.