명명 클래스-모든 것을“<WhatEver> Manager”라고 부르는 것을 피하는 방법? [닫은]

오래 전에 필자는 객체 이름 지정에 대한 "올바른"트랙을 다루는 기사 (블로그 항목을 믿습니다)를 읽었습니다.

예를 들어 내 응용 프로그램이 (일반적인 비즈니스 응용 프로그램) 사용자, 회사 및 주소를 처리하는 경우 User, a Company및 Address도메인 클래스가 있고 아마도 어딘가에 a UserManager, a CompanyManager및 a AddressManager가 표시됩니다.

그래서 당신은 어떤 사람들을 말할 수있는 UserManager, CompanyManager그리고 AddressManager합니까? 아니요. Manager는 도메인 개체로 수행 할 수있는 모든 작업에 적합한 매우 일반적인 용어이기 때문입니다.

내가 읽은 기사는 매우 구체적인 이름을 사용하는 것이 좋습니다. C ++ 응용 프로그램이고 UserManager의 작업이 힙에서 사용자를 할당하고 해제하는 경우 사용자를 관리하지 않고 출생과 사망을 보호합니다. 흠, 아마도 우리는 이것을이라고 부를 수 UserShepherd있습니다.

또는 UserManager의 임무는 각 User 객체의 데이터를 검사하고 암호화하여 데이터에 서명하는 것입니다. 그리고 우리는이있을 것이다 UserRecordsClerk.

이제이 아이디어가 나와 붙어서 적용하려고합니다. 그리고이 간단한 아이디어를 놀라 울 정도로 어렵게 찾으십시오.

클래스가하는 일을 설명 할 수 있고 (빠르고 더러운 코딩에 빠지지 않는 한) 내가 작성한 클래스는 정확히 한 가지 작업을 수행합니다 . 그 설명에서 이름으로 가기 위해 놓친 것은 일종의 이름 카탈로그, 개념을 이름에 매핑하는 어휘입니다.

궁극적으로 패턴 카탈로그와 같은 것을 마음에두고 싶습니다 (종종 디자인 패턴은 팩토리 와 같은 객체 이름을 쉽게 제공합니다 )

• 팩토리-다른 오브젝트를 작성합니다 (디자인 패턴에서 가져온 이름 지정).
• 목자-목자는 객체의 수명, 생성 및 종료를 처리합니다.
• 동기화 기-둘 이상의 객체 (또는 객체 계층)간에 데이터를 복사합니다.

• Nanny-생성 후 개체가 "사용 가능한"상태에 도달하도록 지원합니다 (예 : 다른 개체에 배선하여)

• 등

그렇다면 그 문제를 어떻게 처리합니까? 당신은 고정 어휘를 가지고 있습니까, 당신은 즉시 새로운 이름을 발명합니까 또는 중요하지 않은 또는 잘못된 이름을 고려합니까?

추신 : 또한이 문제를 다루는 기사와 블로그 링크에 관심이 있습니다. 시작으로 여기에 내가 생각한 원래 기사가 있습니다. 'Manager'없이 Java 클래스 이름 지정

업데이트 : 답변 요약

그동안 내가이 질문에서 배운 내용에 대한 약간의 요약이 있습니다.

• 새로운 은유를 만들지 마십시오 (내니)
• 다른 프레임 워크의 기능을 살펴보십시오

이 주제에 대한 추가 기사 / 책 :

• 정기적으로 수업에 앞서거나 추가하는 이름은 무엇입니까?
• 클래스 이름을 지정하는 가장 좋은 방법은 무엇입니까?
• 책 : 디자인 패턴 : 재사용 가능한 객체 지향 소프트웨어의 요소 (양장본)
• 책 : 엔터프라이즈 애플리케이션 아키텍처의 패턴 (양장본)
• 책 : 구현 패턴 (페이퍼 백)

그리고 답변에서 수집 한 이름 접두사 / 접미사 (주제!)의 현재 목록 :

• 조정자
• 건축업자
• 작가
• 리더
• 매니저
• 컨테이너
• 실험 계획안
• 표적
• 변환기
• 제어 장치
• 전망
• 공장
• 실재
• 버킷

그리고 길을위한 좋은 팁 :

명명 마비를 얻지 마십시오. 예, 이름은 매우 중요하지만 많은 시간을 낭비 할만큼 중요하지는 않습니다. 10 분 안에 좋은 이름을 찾지 못하면 계속 진행하십시오.

내가 물어 비슷한 질문을 하지만, 가능하다면 나는 이미 이름을 복사하려고 닷넷 프레임 워크, 그리고 내가 아이디어를 찾아 자바 와 안드로이드 프레임 워크.

보인다 Helper, Manager그리고 Util더 상태를 포함하지 일반적 절차 및 정적 클래스를 조정하기위한 부착 피할 수없는 명사이다. 대안은 Coordinator입니다.

당신은 이름 특히 보라색 prosey를 얻을 수와 같은 것들에 갈 수있다 Minder, Overseer, Supervisor, Administrator,와 Master,하지만 난 당신이 사용하고있는 프레임 워크 이름처럼 유지를 선호했다한다.

.NET 프레임 워크 에서 찾을 수있는 다른 일반적인 접미사 (올 바르면)

• Builder
• Writer
• Reader
• Handler
• Container

source-code-wordle.de를 살펴볼 수 있습니다 . .NET 프레임 워크 및 기타 라이브러리의 클래스 이름 접두사가 가장 많이 사용되는 것을 분석했습니다.

상위 20 개는 다음과 같습니다.

• 속성
• 유형
• 돕는 사람
• 수집
• 변환기
• 매니저
• 정보
• 공급자
• 예외
• 서비스
• 요소
• 매니저
• 마디
• 선택권
• 공장
• 문맥
• 안건
• 디자이너
• 베이스
• 편집자

나는 좋은 이름을 가진 사람이며, 종종 이름을 선택할 때주의를 기울여야하는 중요성에 대해 글을 씁니다. 이 같은 이유로, 나는 이름을 지을 때 은유에주의한다. 원래 질문에서 "공장"과 "동기화 기"는 의미하는 것의 좋은 이름처럼 보입니다. 그러나 "셰퍼드"와 "유모"는 은유에 기초하기 때문에 아닙니다 . 코드의 클래스는 말 그대로 보모가 될 수 없습니다 . 당신은 그것을 보모라고 부릅니다. 왜냐하면 아기 나 아이들을 돌보는 실제 보모와 매우 흡사합니다. 비공식적으로 말하면 괜찮지 만, 누가 알지 누가 누가 알 수 있는지에 따라 코드에서 클래스를 명명하는 것은 괜찮습니다.

왜? 은유는 문화에 의존하고 종종 개인에 의존하기 때문입니다. 당신에게 클래스 "nanny"의 이름을 지정하는 것은 매우 분명 할 수 있지만 다른 사람에게는 그다지 명확하지 않을 수 있습니다. 개인적인 용도로만 사용되는 코드를 작성하지 않는 한 그에 의존해서는 안됩니다.

어쨌든 관습은 은유를 만들거나 깨뜨릴 수 있습니다. "공장"자체의 사용은 은유를 기반으로하지만 꽤 오랫동안 사용되어 왔으며 현재 프로그래밍 세계에서 상당히 잘 알려진 것이므로 사용하는 것이 안전하다고 말할 것입니다. 그러나 "유모"와 "목자"는 용납 할 수 없습니다.

우리는 어떤없이 할 수있는 xxxFactory, xxxManager또는 xxxRepository우리가 제대로 현실 세계를 모델링하는 경우 클래스 :

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)

dailywtf.com, "ManagerOfPeopleWhoHaveMortgages"등에 게시 될 내용에 미끄러운 경사처럼 들립니다.

하나의 모 놀리 식 Manager 클래스는 디자인이 좋지 않지만 'Manager'를 사용하는 것은 나쁘지 않습니다. UserManager 대신 UserAccountManager, UserProfileManager, UserSecurityManager 등으로 분류 할 수 있습니다.

'관리자'는 클래스가 실제 '사물'을 나타내지 않음을 분명히 나타 내기 때문에 좋은 단어입니다. 'AccountsClerk'-그것이 사용자 데이터를 관리하는 클래스인지, 또는 업무 담당 회계 담당자 인 사람인지 어떻게 알 수 있습니까?

이 분야의 기사에 관심이 있으므로 Steve Yegge의 의견 기사 "명사에서 실행"에 관심이있을 수 있습니다.

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

클래스 이름을 사용 Manager하거나 Helper클래스 이름으로 생각할 때 코드 악취로 간주됩니다. 이는 올바른 추상화를 아직 찾지 못했거나 단일 책임 원칙을 위반하여 리팩토링하고 디자인에 더 많은 노력을 기울이고 있음을 의미합니다. 종종 이름 지정이 훨씬 쉬워집니다.

그러나 잘 설계된 클래스조차도 항상 이름을 밝히지 않으며 비즈니스 모델 클래스를 생성하는지 기술 인프라 클래스를 작성하는지에 따라 선택이 부분적으로 달라집니다.

비즈니스 모델 클래스는 도메인마다 다르기 때문에 어려울 수 있습니다. Policy도메인 내 전략 클래스 (예 :) 와 같이 많이 사용하는 용어가 LateRentalPolicy있지만, 일반적 으로 비즈니스 사용자와 공유하고 클래스를 설계하고 이름을 지정할 수 있는 " 유비쿼터스 언어 " 를 만들려고 할 때 실제로 사용됩니다. -세계의 아이디어, 사물, 행동 및 사건.

기술 인프라 클래스는 우리가 정말 잘 알고있는 영역을 설명하기 때문에 조금 더 쉽습니다. 디자인 패턴 이름을 클래스 이름에 통합하는 것을 선호 InsertUserCommand, CustomerRepository,하거나 SapAdapter.의도 대신 구현 통신에 대한 우려를 이해하지만 디자인 패턴은 클래스 디자인의 두 가지 측면과 결혼합니다. 적어도 원하는 인프라를 다루는 경우 세부 사항을 숨기는 동안에도 투명하게 구현 디자인 을 구현할 수 있습니다.

GOF book에 의해 정의 된 패턴으로 실패 하고, 그 이후에 객체의 이름을 지정하면 클래스의 이름을 지정하고 구성하고 의사 소통을하는 데 많은 도움이됩니다. 대부분의 사람들은이 명명법 (또는 적어도 그 일부)을 이해할 것입니다.

XyzManager보다 클래스에 대해 더 구체적인 이름을 얻을 수 없다면 이것이 클래스에 속하는 기능, 즉 건축 적 '코드 냄새'인지 여부를 재고해야 할 시점입니다.

명심해야 할 가장 중요한 것은 이름이 충분히 설명 적이라고 생각합니다. 클래스가 무엇을해야하는지 이름을 보면 알 수 있습니까? 클래스 이름에 "Manager", "Service"또는 "Handler"와 같은 단어를 사용하는 것은 너무 일반적인 것으로 간주 될 수 있지만 많은 프로그래머가이를 사용하므로 클래스의 목적을 이해하는 데 도움이됩니다.

나는 나 자신이 정면 패턴을 많이 사용하고있다. User한 명의 사용자를 설명 하는 클래스와Users 클래스 "사용자 모음"을 추적 . 나는 UserManager실생활에서 관리자를 좋아하지 않기 때문에 클래스를 호출 하지 않으며 나는 상기시키기를 원치 않습니다. :) 복수형을 사용하는 것만으로도 클래스가하는 일을 이해하는 데 도움이됩니다.

C #에만 해당하는 것을 발견했습니다. "프레임 워크 디자인 지침 : 재사용 가능한 .NET 라이브러리의 규칙, 숙어 및 패턴" 에서 명명 논리에 대한 많은 정보를 얻을 수있었습니다.

보다 구체적인 단어를 찾는 한, 나는 종종 동의어 사전을 사용하고 관련 단어를 뛰어 넘어 좋은 단어를 찾으려고 노력합니다. 개발을 진행하면서 더 나은 이름을 얻거나 때로는 SuchAndSuchManager여러 클래스로 나뉘어 야한다는 사실을 깨닫고 더 이상 사용하지 않는 클래스의 이름이 문제가되지 않습니다. .

나는 여기서 중요한 것은 코드의 가시성 영역 내에서 일관성이 있어야한다고 생각합니다. 즉, 코드를 보거나 작업 해야하는 모든 사람들이 네이밍 규칙을 이해하는 한 전화를 걸더라도 괜찮습니다. '회사 Thingamabob'및 'UserDoohickey'. 회사를 위해 일하는 경우 첫 번째 중지는 회사 이름 지정 규칙이 있는지 확인하는 것입니다. 회사에 근무하지 않거나 근무하지 않는 경우 자신에게 적합한 용어를 사용하여 자신을 만들고 최소한 부담없이 코딩하고 신뢰할만한 피드백을 통합하는 신뢰할 수있는 동료 / 친구 몇 명에게 전달하십시오.

다른 사람의 컨벤션을 널리 받아 들여도 페이지가 튀어 나오지 않으면 내 책에서 약간의 실수가 있습니다. 우선 다른 문서를 참조하지 않고 코드를 이해해야하지만 동시에 동일한 산업 분야의 같은 분야에있는 다른 사람이 이해할 수 없을 정도로 포괄적이어야합니다.

시스템에 사용하는 패턴, 클래스의 명명 규칙 / 카탈로그 / 그룹화는 사용 된 패턴으로 정의되는 경향이 있습니다. 개인적으로, 나는 다른 사람들이 내 코드를 가져 와서 실행할 수있는 가장 가능성이 높은 이름 지정 규칙을 고수합니다.

예를 들어 UserRecordsClerk는 UserRecordsClerk와 CompanyRecordsClerk가 구현 한 다음 전문화하는 일반 RecordsClerk 인터페이스를 확장하는 것으로 더 잘 설명 될 수 있습니다. 즉, 인터페이스의 메소드를보고 해당 서브 클래스의 기능이 무엇인지 일반적으로 알 수 있습니다.

디자인 패턴 과 같은 책을보십시오 정보 훌륭한 책이며 아직 코드를 사용하지 않는 경우 코드를 사용하려는 위치를 정리하는 데 도움이 될 수 있습니다! ;영형)

나는 당신의 패턴이 잘 선택되고 적절하게 사용되는 한, 매우 독창적 인 수업 이름으로 충분하다고 생각합니다!