클래스 이름 지정 - 모든 것을 호출하는 것을 피하는 방법 "<WhatEver> 매니저"? [닫은]
청렴결백한 만능 재주꾼2023. 4. 9. 15:43
반응형
질문자 :Community Wiki
오래 전에 나는 객체 이름 지정에 대한 "올바른" 길을 알려주는 기사(블로그 항목을 믿습니다)를 읽었습니다.
예를 들어 내 응용 프로그램이 (일반적인 비즈니스 앱으로) 사용자, 회사 및 주소를 처리하는 경우 User , Company 및 Address 도메인 클래스가 있고 아마도 어딘가에 UserManager , CompanyManager 및 AddressManager 이 처리하는 팝업이 나타납니다. 그것들.
UserManager , CompanyManager 및 AddressManager 가 무엇을 하는지 알 수 있습니까? 아니요. Manager는 도메인 개체로 수행할 수 있는 모든 작업에 적합한 매우 일반적인 용어이기 때문입니다.
내가 읽은 기사는 매우 구체적인 이름을 사용하는 것이 좋습니다. C++ 응용 프로그램이고 UserManager 의 작업이 사용자를 힙에서 할당하고 해제하는 것이라면 사용자를 관리하지 않고 사용자의 탄생과 죽음을 보호합니다. UserShepherd 라고 부를 수 있을 것입니다.
또는 UserManager 의 작업은 각 사용자 개체의 데이터를 검사하고 데이터를 암호화 방식으로 서명하는 것입니다. 그런 다음 UserRecordsClerk 있습니다.
이제 이 아이디어가 저에게 붙어서 적용하려고 합니다. 그리고 이 간단한 아이디어를 놀라울 정도로 어렵게 찾으십시오.
나는 클래스가 하는 일을 설명할 수 있고 (빠르고 더러운 코딩에 빠지지 않는 한) 내가 작성한 클래스는 정확히 한 가지 일을 합니다. 내가 그 설명에서 이름으로 가는 것이 그리운 것은 이름의 일종의 카탈로그, 개념을 이름에 매핑하는 어휘입니다.
궁극적으로 내가 내 마음에 패턴 카탈로그와 같은 뭔가를하고 싶습니다 (자주 패턴이 쉽게 개체 이름을 제공 설계, 예를 들면 공장)
Factory - 다른 객체 생성(디자인 패턴에서 가져온 이름 지정)
셰퍼드 - 셰퍼드는 객체의 수명, 생성 및 종료를 처리합니다.
동기화 장치 - 둘 이상의 개체(또는 개체 계층) 간에 데이터를 복사합니다.
Nanny - 생성 후 객체가 "사용 가능한" 상태에 도달하도록 돕습니다(예: 다른 객체에 연결하여).
등
그렇다면 그 문제를 어떻게 처리합니까? 고정된 어휘가 있습니까? 즉석에서 새로운 이름을 만들어 내고 있습니까? 아니면 그다지 중요하지 않거나 잘못된 이름을 지정하는 것을 고려합니까?
추신: 나는 또한 이 문제를 논의하는 기사와 블로그에 대한 링크에 관심이 있습니다. 시작으로, 여기에 내가 그것에 대해 생각하게 만든 원본 기사가 있습니다: 'Manager' 없이 Java 클래스 이름 지정
나는 모두 좋은 이름을 선호하며, 종종 사물의 이름을 선택할 때 세심한 주의를 기울이는 것의 중요성에 대해 글을 씁니다. 바로 이와 같은 이유로, 나는 물건의 이름을 지정할 때 은유를 조심합니다. 원래 질문에서 "factory"와 "synchronizer"는 그들이 의미하는 것처럼 보이는 좋은 이름처럼 보입니다. 그러나 "shepherd"와 "nanny"는 은유를 기반으로 하기 때문에 그렇지 않습니다. 코드의 클래스는 말 그대로 유모가 될 수 없습니다. 실제 유모가 아기나 아이들을 돌보는 것처럼 다른 것들을 돌보기 때문에 유모라고 부릅니다. 그것은 비공식적 인 연설에서는 괜찮지 만 누가 언제 누가 아는지 누가 알고 있는지 유지해야 할 코드의 클래스 이름을 지정하는 데는 괜찮지 않습니다(내 생각에는).
왜요? 은유는 문화에 따라 달라지고 종종 개인에게도 종속되기 때문입니다. 당신에게는 클래스 이름을 "nanny"로 지정하는 것이 매우 명확할 수 있지만 다른 사람에게는 그렇게 명확하지 않을 수 있습니다. 개인적인 용도로만 코드를 작성하는 경우가 아니라면 이에 의존해서는 안 됩니다.
어쨌든 관습은 은유를 만들 수도 깨뜨릴 수도 있습니다. "factory" 자체의 사용은 은유에 기반을 두고 있지만 꽤 오랫동안 사용되어 왔고 현재 프로그래밍 세계에서 꽤 잘 알려진 은유이므로 사용하는 것이 안전하다고 말할 수 있습니다. 그러나 "nanny"와 "shepherd"는 허용되지 않습니다.
Community Wiki
실제 세계를 올바르게 모델링했다면 xxxFactory , xxxManager 또는 xxxRepository 클래스 없이도 할 수 있습니다.
dailywtf.com, "ManagerOfPeopleWhoHaveMortgages" 등에 게시될 내용에 대한 미끄러운 경사처럼 들립니다.
하나의 모놀리식 Manager 클래스가 좋은 디자인은 아니지만 'Manager'를 사용하는 것은 나쁘지 않다고 생각합니다. UserManager 대신 UserAccountManager, UserProfileManager, UserSecurityManager 등으로 나눌 수 있습니다.
'매니저'는 클래스가 실제 '사물'을 나타내지 않는다는 것을 분명히 보여주기 때문에 좋은 단어입니다. 'AccountsClerk' - 사용자 데이터를 관리하는 클래스인지, 아니면 업무를 담당하는 Accounts Clerk를 나타내는 클래스인지 어떻게 알 수 있습니까?
Mr. Boy
Manager 또는 Helper 를 사용하는 것에 대해 생각하고 있는 자신을 발견할 때 , 나는 아직 올바른 추상화를 찾지 못했거나 단일 책임 원칙을 위반하고 있음을 의미하는 코드 냄새라고 생각하므로 리팩토링하고 더 많은 노력을 기울이고 있습니다. 디자인에 추가하면 이름 지정이 훨씬 쉬워집니다.
그러나 잘 디자인된 클래스라도 (항상) 이름을 지정하지는 않으며 선택은 부분적으로 비즈니스 모델 클래스를 생성하는지 아니면 기술 인프라 클래스를 생성하는지에 따라 달라집니다.
비즈니스 모델 클래스는 도메인마다 다르기 때문에 어려울 수 있습니다. 도메인 내의 전략 클래스에 대한 Policy (예: LateRentalPolicy )과 같이 내가 많이 사용하는 용어가 있지만 일반적으로 비즈니스 사용자와 공유할 수 있는 "유비쿼터스 언어 "를 만들고 클래스를 설계하고 명명하려는 시도에서 LateRentalPolicy 실제 세계의 아이디어, 대상, 행동 및 이벤트를 모델링합니다.
기술 인프라 클래스는 우리가 정말 잘 알고 있는 도메인을 설명하기 때문에 조금 더 쉽습니다. InsertUserCommand,CustomerRepository, 또는 SapAdapter. 와 같은 클래스 이름에 통합하는 것을 선호합니다. 내가 대신 의도의 구현을 통신에 대한 우려를 이해하지만 디자인 패턴은 클래스 디자인의 두 가지 측면을 결혼 - 적어도 때 세부 사항을 숨기고있는 동안 당신이 구현 디자인은 투명도되고 싶어 인프라와 당신이있는 거 거래.
Community Wiki
(가령) GOF 책에 정의된 대로 패턴을 사용하고 이러한 이후에 개체에 이름을 지정하면 클래스 이름 지정, 구성 및 의도 전달에 많은 도움이 됩니다. 대부분의 사람들은 이 명명법(또는 적어도 대부분)을 이해할 것입니다.
Brian Agnew
내 클래스에 대해 XyzManager보다 더 구체적인 이름을 생각해낼 수 없다면 이것이 실제로 클래스에 함께 속하는 기능, 즉 아키텍처 '코드 냄새'인지 여부를 재고해야 하는 시점이 될 것입니다.
Community Wiki
명심해야 할 가장 중요한 점은 다음과 같습니다. 이름이 충분히 설명적인가? 이름을 보고 클래스가 무엇을 해야 하는지 알 수 있습니까? 클래스 이름에 "Manager", "Service" 또는 "Handler"와 같은 단어를 사용하는 것은 너무 일반적인 것으로 간주될 수 있지만 많은 프로그래머가 사용하기 때문에 클래스가 무엇을 위한 것인지 이해하는 데 도움이 됩니다.
나는 나 자신이 파사드 패턴을 많이 사용해 왔다(적어도 그것이 호출되는 것이라고 생각한다). 한 명의 사용자만 설명 User 클래스와 내 "사용자 컬렉션"을 추적 Users 클래스가 있을 수 있습니다. 나는 실생활에서 관리자를 좋아하지 않고 그들을 상기시키고 싶지 않기 때문에 클래스를 UserManager 라고 부르지 않는다 :) 복수형을 사용하는 것만으로도 클래스가 하는 일을 이해하는 데 도움이 된다.
더 구체적인 단어를 찾는 한, 나는 종종 동의어 사전을 사용하고 좋은 단어를 찾기 위해 관련 단어를 뛰어 넘습니다. 하지만 개발을 진행하면서 더 나은 이름을 SuchAndSuchManager , 때때로 SuchAndSuchManager가 실제로 여러 클래스로 분할되어야 한다는 것을 깨닫고 사용되지 않는 클래스의 이름이 문제.
AaronLS
여기서 중요한 것은 코드 가시성 범위 내에서 일관성을 유지하는 것입니다. 즉, 코드를 보고 작업해야 하는 모든 사람이 명명 규칙을 이해하는 한, 호출하기로 결정하더라도 괜찮습니다. 'CompanyThingamabob' 및 'UserDoohickey'. 회사에서 일하는 경우 첫 번째 중지는 회사 이름 지정 규칙이 있는지 확인하는 것입니다. 회사에서 일하지 않거나 일하지 않는 경우 자신에게 맞는 용어를 사용하여 자신만의 용어를 만들고 최소한 캐주얼하게 코딩하는 신뢰할 수 있는 동료/친구에게 전달하고 의미 있는 피드백을 통합하십시오.
다른 사람의 관례를 적용하는 것은 그것이 널리 받아들여지고 있더라도 그것이 당신에게 페이지를 뛰어넘지 않는다면 내 책에서 약간의 실수입니다. 무엇보다 먼저 다른 문서를 참조하지 않고 내 코드를 이해해야 하지만 동시에 같은 업계의 같은 분야에 있는 다른 사람이 이해할 수 없을 정도로 일반적이어야 합니다.
Lazarus
나는 당신이 당신의 시스템에 사용하는 패턴을 고려할 것입니다. 명명 규칙 / 분류 / 클래스 그룹화는 사용되는 패턴에 의해 정의되는 경향이 있습니다. 개인적으로, 나는 다른 사람이 내 코드를 선택하고 실행할 수 있는 가장 가능성 있는 방법이기 때문에 이러한 명명 규칙을 고수합니다.
예를 들어, UserRecordsClerk는 UserRecordsClerk와 CompanyRecordsClerk가 모두 구현하고 전문화하는 일반 RecordsClerk 인터페이스를 확장하는 것으로 더 잘 설명될 수 있습니다.
정보는 Design Patterns 와 같은 책을 참조하십시오. 이 책은 훌륭한 책이며 아직 코드를 사용하고 있지 않은 경우 목표로 하는 코드를 정리하는 데 도움이 될 것입니다! ;영형)
패턴이 잘 선택되고 적절한 만큼 사용되는 한 꽤 독창적이지 않은 간단한 클래스 이름으로 충분하다고 생각합니다!