오래 전에 필자는 객체 이름 지정에 대한 “올바른”트랙을 다루는 기사 (블로그 항목을 믿습니다)를 읽었습니다.
예를 들어 내 응용 프로그램이 (일반적인 비즈니스 응용 프로그램) 사용자, 회사 및 주소를 처리하는 경우 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.
의도 대신 구현 통신에 대한 우려를 이해하지만 디자인 패턴은 클래스 디자인의 두 가지 측면과 결혼합니다. 적어도 원하는 인프라를 다루는 경우 세부 사항을 숨기는 동안에도 투명하게 구현 디자인 을 구현할 수 있습니다.