OOP에서 클래스 디자인에 어떻게 접근합니까?

OO 솔루션을 디자인하려고 할 때 나는 일반적으로 클래스 이름 (명사), 그들이하는 것 (동사) 및 다른 클래스와의 협력 방식을 나열 하는 CRC 모델링을 사용합니다 .

이 블로그 에는이 명사-동사 접근법에 대해 다음과 같이 말할 수 있습니다.

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

제 질문은 OO 접근법을 사용하기 위해 더 나은 모델링 기술이 있습니까?

공정하게, 그는 그 주장에 "재미있다"고 덧붙였다.

오늘날까지 나는 "명사와 동사"접근 방식을 사용하여 시스템을 모델링하는 것으로 시작하는 경향이 있지만, TDD가이 접근 방식이 잘못된 것에 초점을 맞추고 있음을 몇 년 동안 가르쳐 왔습니다. 이런 점에서 블로거는 요점을 가지고 있습니다. 그러나 나는 그것이 우리의 마음이 작동하는 방식이 아니라 잘못에 대한 접근법인지 확실하지 않습니다.

여기서 약간의 도전을 원한다면 읽기를 중단하고 영어를 사용하여 독점 게임을 모델링 한 다음 다시 여기로 오십시오.

보드, 공간, 카드, 주사위, 조각과 같이 우리가 많은 것들과 상호 작용하는 대상을 즉시 보려는 유혹이있을 것입니다. 그러나 그것은 대부분의 논리가가는 곳이 아닙니다. 이러한 개체의 대부분은 완전히 바보입니다. 원한다면 데이터.

그러나 테스트를 시작하자마자 어떤 게임에서 어떤 객체가 가장 중요한지 알 수 있습니다. 규칙.

처음 게임을했을 때 한 번 읽었고 분쟁이있을 때까지 다시는 상호 작용하지 않는 작은 종이 조각을 기억하십니까? 전산화 된 버전은 그런 식으로 작동하지 않습니다. 플레이어가 시도하는 모든 일, 컴퓨터는 규칙을 참고하여 규칙이 허용되는지 여부를 확인합니다.

당신이 그것에 대해 생각할 때, 당신은 같은 일을하지만 종이 기반 규칙을 읽는 데 시간이 걸리고 뇌에 합리적인 캐싱 시스템이 있기 때문에 머리의 규칙을 참조하십시오. 컴퓨터는 규칙을 다시 쉽게 읽을 수있을 것입니다. 데이터베이스에 저장되어 있지 않으면 캐시 할 수도 있습니다.

이것이 바로 TDD가 실제로 드라이빙 디자인에 인기가있는 이유입니다. 사고 과정을 올바른 장소로 빠르게 진행시키는 경향이 있기 때문에 :

독점 게임에 대한 몇 가지 테스트를 작성한다고 생각할 때. 세트를보고 객체를 찾으려고 할 수 있습니다. 우리는이 조각들을 가지고 있습니다. 그에 대한 몇 가지 테스트를 작성하겠습니다.

아마도 기본 클래스 MonopolyPiece를 가질 것이고 각 유형의 조각은 그로부터 파생 될 것입니다. DogPiece부터 시작하겠습니다. 첫 번째 테스트 ... 아. 실제로 여기에는 논리가 없습니다. 예, 각 조각이 다르게 그려 지므로 DogDrawer가 필요할 수 있지만 게임을 살피는 동안 화면에 "D"를 쓰고 싶습니다. 마지막에 UI를 꾸미겠습니다.

테스트 할 실제 로직을 찾아 보자. 이 집들과 호텔은 많이 있지만 테스트는 필요하지 않습니다. 돈 아니 재산 카드. 등등. 보드조차 상태 머신 일 뿐이며 로직을 포함하지 않습니다.

당신은 당신의 손에 세 가지가 남아 있음을 빨리 알게 될 것입니다. 기회와 커뮤니티 상자 카드, 한 쌍의 주사위와 일련의 규칙. 이것들은 디자인과 테스트에 중요한 부분이 될 것입니다.

명사와 동사를 쓸 때 나오는 것이 보입니까?

실제로 Robert Martin의 Agile Principles Patterns and Practices 에는 TDD를 사용하여 Bowling Score Card 앱을 살려내고 클래스가 귀찮은 가치가 없다고 생각한 모든 종류의 물건을 찾으려고 시도 하는 훌륭한 예가 있습니다.

그런 방법이 도움이되지 않았습니다. 사실 나는 그것들을 사용하는 것이 나를 혼란스럽게한다는 것을 알았습니다. Robert C. Martin의 커피 메이커를 확인하십시오 . 그는 이런 종류의 접근 방식을 사용하지 않는다고 생각합니다.

나를 귀찮게하는 한 가지는 당신이 링크하는 CRC 기사에서 그 사람이 오는 해결책입니다. 고객 / 주문 협업은 내가 쓸만한 가치가있는 것이 아닙니다. 이 모델에는 클래스 등급이 필요한 고객에 대한 흥미로운 점이 없습니다. "고객"이라는 흥미로운 점은 해당 Person 과 연관된 하나 이상의 주문이 있다는 것 입니다.

대학 모델도 있습니다. 학생과 교수가 공유 할 수있는 많은 것들이있을 것입니다. 또한 대학 캠퍼스에서 무료로 자주 허용되는 교수가 수업에 참여하면 어떻게됩니까?

디자인 툴킷의 하나의 요소가 가치있는 연습 일 수 있다고 생각합니다. 나는 그것이 적어도 디자인에 접근하는 유일한 방법이어야한다고 생각하지 않습니다. 솔직히, 공통성 / 변이 분석 접근법이 더 유용하다는 것을 알았습니다. 일상 생활에서 추상화를 분류 할 때 우리가하는 일을 매우 밀접하게 모델링하는 것 같습니다.

편집 : 두 번째 블로그의 절반을 읽으면 꽤 많이 동의한다고 말해야합니다. 나머지 부분을 읽고 학습 측면에서 무엇을 제공하는지 확인해야합니다.

내 의견은 우려를 분리하고 종속성을 줄이기 위해 클래스를 추가하거나 제거해야한다는 의견입니다. 디자인 패턴에 유창한 것은 리팩토링 및 단순화 가능성을보기에 좋은 방법 일 것입니다.

내 경험에 따르면 일반적으로 수업은 명사 / 동사 범주에 속하지 않지만 오히려 다른 패턴 수업 (공장, 싱글 톤, 전략 패턴 등) 및 기타 관리자 수업과 함께 명사 / 동사 수업이 혼합됩니다. 응용 프로그램의 측면을 다룹니다.

중요한 것은 클래스를보고 클래스를 변경하여 클래스를 변경하여 클래스를 변경하고 수정할 수 있어야한다는 것입니다. 응용 프로그램의 측면에 대한 더 많은 코드가 클래스에 더 많이 퍼질수록 응용 프로그램을 따르고 관리하고 확장하기가 더 어려워집니다.