추상 클래스의 일반 이름을 피하는 방법은 무엇입니까?

10

일반적으로 파일 핸들이나 (예) 유닉스 프로세스를 다루지 않는 한 "핸들"또는 "프로세스"와 같은 단어를 루틴 이름 및 클래스 이름의 일부로 사용하지 않는 것이 좋습니다. 그러나 추상 클래스는 종종 처리 이외의 작업으로 무엇을 할 것인지 실제로 모릅니다. 현재 상황에서는 사용자의받은 편지함에 로그인하여 메시지를 처리하는 "EmailProcessor"가 있습니다. 다음과 같은 스타일 문제가 발생했음을 알았지 만 더 정확한 이름을 지정하는 방법은 나에게 분명하지 않습니다.

파생 클래스를 클라이언트로 취급하고 구현하는 기능의 일부로 기본 클래스를 명명하는 것이 더 낫습니까? 더 의미가 있지만 is-a를 위반합니다. 예를 들어 EmailAcquirer는 파생 클래스를 획득하기 때문에 합리적인 이름이 될 수 있지만 파생 클래스는 누구에게도 획득하지 않습니다.
또는 파생 클래스가 무엇을하는지 누가 알기 때문에 막연한 이름입니다. 그러나 "프로세서"는 로그인 및 IMAP 사용과 같은 많은 관련 작업을 수행하기 때문에 여전히 너무 일반적입니다.

이 딜레마에서 벗어날 수있는 방법이 있습니까?

"이것이 무엇을 하는가?"라는 질문에 실제로 대답 할 수없는 추상적 인 방법에는 문제가 더 분명합니다. 대답은 단순히 "고객이 원하는 것"이기 때문입니다.

object-oriented coding-style naming

— 제 클린
소스

해당 "일반"주장에 대한 출처 (및 일부 문맥)가 있습니까? 또한 목록에 대한 추가 명명 규칙-존재하지 않는 완벽한 이름을 찾는 데 시간을 낭비하지 마십시오. 의심스러운 경우, 가능한 최고의 이름을 지정하고, 필요한 경우 정의 된 설명으로 더 긴 설명을 추가하십시오. 그러나 다른 사람이 당신의 선택을 좋아하지 않거나 완벽한 이름이 갑자기 나에게 나타날 경우 언제든지 나중에 리팩터링 할 수 있습니다 다른 일을 다시.

— Steve314

3

@ Steve314-예, Steve McConnell, Code Complete, 1st ed., Chapter 4 또는 5 of routines. 이 장에서 명명에 대한 광범위한 토론, 본질적으로 좋은 이름이 없다면 아마도 좋은 기능이 없을 것입니다.

— djechlin

좋은 이름을 찾지 못하면 나쁜 징조처럼 보일 수 있지만 IMO는 함수 자체에 따라 함수가 나쁜지 알아야합니다. 영어가 프로젝트를 위해 맞춤 설계되지 않았기 때문에 리팩토링하는 것은 약간 까다 롭습니다. 아니요, 일상적인 문제는 아니지만 이미 문제가 있다고 판단했습니다.

— Steve314

1

@ Steve314 프로그래밍은 전적으로 복잡성 관리에 관한 것입니다. 두뇌가 무언가에 대한 단어를 생각해 낼 수 없다면, 그것을 사용하는 것과 같은 일을해야 할 때 복잡성을 관리 할 수 없을 가능성이 큽니다. 더 큰 문장 또는 더 큰 시스템의 일부로. 실제로 좋은 이름을 찾을 수 없다는 것이 우려를 위해 멈추는 큰 원인이라고 말하는 것은 대담한 주장이 아닙니다. 그러나 이것은 McConnell에서 광범위하게 논의됩니다. 나는 전체 책이 엄밀히 읽을 가치가 있지만 적어도 두 장을 읽는 것이 좋습니다.

— djechlin

Code Complete의 주장을 반드시 신뢰할 필요는 없습니다. 나는 책의 명성을 알고 있지만 이것 또한 알고 있습니다. 게다가, 나는 시대에 따라 복잡성을 완벽하게 잘 관리 해왔다. 실수는 일어났다. 그러나 문제가 발생 했을 때 문제는 너무나 간단해서 잘못 될 수는없는 함수이다 .

— Steve314

10

문제는 이름이 아니라 한 수업에 너무 많이 넣었다는 것입니다.

예제 클래스에서 일부 부분은 매우 구체적입니다 (메일을 얻는 방법). 다른 부분은 매우 추상적입니다 (메일로 수행 할 작업).

상속보다 별도의 클래스 로이 작업을 수행하는 것이 좋습니다.

나는 제안한다 :

POPMailBoxDownloader에 의해 서브 클래스 화되는 추상 MessageIterator
POPMailBoxDownloader를 소유하고 메시지로 무언가를 수행하는 다른 클래스.

— 크리스 반 바엘
소스

이것은 정확히 맞습니다. "processEvent"또는 "MessageProcessor"클래스의 이름을 지정하는 경우 파생 대신 컴포지션을 디자인 할 가능성이 높습니다. 이 경우, 관리자는 유연성이 유용 할 수 있지만, 각 기능이 무엇을 수행하는지 (관리자보다) 정확히 궁금해함으로써 고객은 짜증을 낼 수 있습니다.

— djechlin

6

클래스의 좋은 이름을 찾을 수 없으면 클래스에 대한 인라인 코드 문서를 작성합니다. 수업의 목적을 한 가지 방식으로 설명합니다. 일반적으로이 설명에서 클래스의 좋은 이름을 도출 할 수 있습니다. 이것은 추상 클래스에도 도움이됩니다.

클래스 설명이 "사용자의받은 편지함에 로그인하여 메시지를 처리하는 경우"인 경우 "InboxProcessor"를 클래스 이름으로 제안합니다. 파생 클래스에 설명으로 "사용자의받은 편지함에 로그인하고 스팸 전자 메일을 스팸 폴더로 이동"이 있으면 "InboxSpamMover"를 이름으로 선택합니다.

"프로세서"와 같은 일반 이름을 사용할 때 추상 클래스의 일반 목적을 반영하면 문제가 발생하지 않습니다.

하나 또는 두 가지 방향으로 수업의 목적을 설명하는 데 문제가 있으면 디자인 문제가있을 수 있습니다. 수업이 너무 많은 일을하고 단일 책임 원칙을 위반하는 것일 수 있습니다. 이것은 추상 클래스에도 적용됩니다.

— 테오 렌 도프
소스

2

프랭크 자파 (Frank Zappa)의 말을 바꾸면, 그것이 바로 그 이름이고 그렇게해야합니다. 귀하의 예는 어떤 종류의 처리가 진행되고 있는지 깊이 파고 들지 않습니다. 그것에게인가 EmailToTroubleTicketProcessorAN, EmailGrammarCorrector또는은 EmailSpamDetector?

"이것이 무엇을 하는가?"라는 질문에 실제로 대답 할 수없는 추상적 인 방법에는 문제가 더 분명합니다. 대답은 단순히 "고객이 원하는 것"이기 때문입니다.

그것은 사실이 아닙니다. 초록에 대해 대답 할 수없는 질문은 " 어떻게 작동합니까?"입니다. 구현에 따라 다르기 때문입니다. 경우 EmailSender클래스가이 DeliveryStatus deliver(Email e)메소드를 구현이 전자 메일을 배달하고 갔다 방법에 대한 상태를 반환하려고합니다 것을 묵시적 계약이있다. 구현이 약속 한대로 수행하는 한 SMTP 서버에 연결하거나 귀환 비둘기에 묶도록 인쇄할지 여부는 신경 쓰지 않습니다. 초록은 그 약속을 수량화하여 구현이 "예, 그렇게합니다"라고 말할 수 있습니다.

— 블 리플
소스

end 함수가 어떤 의미에서 터미널 일 때 어떻습니까? 추상 클래스는 "그리고 여기, 당신이 원하는 것은 무엇입니까?" 예를 들어, 메소드는 state, void return type, no-throw에 액세스 할 수 없습니다.

— djechlin

여전히 같은 것입니다. 메소드가 void doWhatYouDoWith(Email e)인 경우에도 클래스를 호출 할 수 있습니다.이 클래스는 수행하는 작업 EmailDisposer을 말할 수있을만큼 구체적이지만 구현 방법에 대해 일반적으로 충분합니다. @KrisVanBael이 그것을 못 박았다고 생각하지만, 모호한 것에 의지했다면 한 지붕 아래에 너무 많은 것이있을 수 있습니다.

— Blrfl

0

그런 단어를 사용하는 것이 왜 나쁜지 생각해보십시오 . 그것들은 묘사 적인가? 수업 을 설명 하기 위해 어떤 단어가 있습니까? EmailBaseClass? EmailManager 또는 이와 유사한 것을 말하는 것보다 더 설명 할 수 있습니까? 핵심은 문제의 수업에 대한 통찰력 을 가지므로 적절한 동사 나 명사를 찾으십시오. 코드를시처럼 취급하십시오.

— zxcdw
소스

"EmailBaseClass"는 "ageInteger"라는 이름과 같을 int age것입니다. 일반 텍스트 이메일, MIME 이메일 등을 파생시킬 것으로 예상되기 때문에 더 나쁩니다. abstract처음에 단어 앞에 나오는 것을 설명 할 필요가 없습니다 (이것은 Java입니다). 이 수업의 기본 부분에 대한 특별한 통찰력이 있습니까? 그리고 더 많은 통찰력은 여전히 is-a 관계를 가로 지르는 무언가의 이름을 지정하는 문제를 해결하지 못합니다. 너무 모호하거나 너무 일반적인 것이있을 수 있습니다. 더 많은 통찰력을 얻는 것에 대한 더 많은 통찰력.

— djechlin

@ djechlin- ageInteger실제로 또는 그와 비슷한 것이 드문 경우가 있습니다. 헝가리 표기법은 상황이 많이 발생하는 약자입니다. 당신의 라인을 따라 뭔가해야 할 수도 있습니다 때 확실히 시간이있다 ageNumeric하고 ageString명확하게하는 가장 쉽고 명확한 방법 인 이름에 유형의 표시와 같은 범위를.

— Steve314

@ djechlin 개인적 으로 이해하기 위해 살짝 들여다 볼 수있는 코드로 작업하는 것이 가장 쉽다는 것을 개인적으로 알았습니다 . 즉, 이름은 내가 작업하고있는 것을 말해줍니다. systemController추상 기본 클래스인지 아니면 거대한 계층 구조의 리프 인지 알 필요가 없습니다 . 물론 이것은 대부분의 Java 개발의 경우와 같이 IDE로 해결할 수 있습니다.이 클래스는 사용자에게 클래스의 내용과 구조를 즉시 알릴 수 있으므로 실제로 통찰력있는 이름을 비슷한 맥락에서 정당화 할 수 없습니다.

— zxcdw