design-patterns - 이름 지정 클래스-모든 것을 "<WhatEver>Manager"라고 부르는 것을 피하는 방법?




oop naming-conventions naming (12)

오래 전에 나는 네이밍 객체의 "올바른"트랙에 나를 올려 놓은 기사 (나는 블로그 엔트리를 믿는다)를 읽었습니다 : 당신의 프로그램에서 이름 짓기에 관해서는 매우 신중해야합니다.

예를 들어 내 응용 프로그램이 (일반 비즈니스 응용 프로그램처럼) 사용자, 회사 및 주소를 처리하는 경우 User , CompanyAddress 도메인 클래스가 있고 아마도 UserManager , CompanyManagerAddressManager 어딘가에 해당 핸들이 팝업됩니다 그것들.

UserManager , CompanyManagerAddressManager UserManager 일을 알려줄 수 있습니까? 아니요, Manager는 도메인 객체로 수행 할 수있는 모든 작업에 매우 일반적인 용어이기 때문에 아닙니다.

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

또는 UserManager 의 작업은 각 User 객체의 데이터를 검사하고 데이터에 암호로 서명하는 것입니다. 그러면 UserRecordsClerkUserRecordsClerk .

이제이 아이디어가 나와 함께 붙어서 그것을 적용하려고합니다. 그리고이 간단한 아이디어를 놀랍도록 열심히 찾으십시오.

나는 클래스가하는 일을 기술 할 수있다. (필자가 빠르고 코딩에 빠지지 않는 한) 내가 쓰는 클래스는 정확히 가지를한다. 그 설명에서 이름에 이르기까지 놓친 것은 일종의 이름 목록인데, 그 개념을 이름에 매핑하는 어휘입니다.

궁극적으로 나는 내 마음 속에 패턴 카탈로그와 같은 것을 갖고 싶다. (종종 디자인 패턴은 객체 이름을 쉽게 제공한다. 예를 들어 공장 )

  • Factory - 다른 객체를 만듭니다 (디자인 패턴에서 가져온 이름).
  • 양치기 (Shepherd) - 양치기는 개체의 수명, 생성 및 종료를 처리합니다.
  • Synchronizer - 둘 이상의 개체 (또는 개체 계층 구조)간에 데이터를 복사합니다.
  • Nanny - 객체가 생성 후 "사용 가능"상태에 도달하도록 돕습니다. 예를 들어 다른 객체에 연결

  • 등등.

그래서, 어떻게 그 문제를 처리합니까? 고정 된 어휘를 사용하고 있습니까? 즉석에서 새로운 이름을 발명 했습니까? 또는 중요하지 않거나 잘못되었지만 이름을 지정하는 것을 고려합니까?

추신 : 나는 또한 문제를 논의하는 기사와 블로그에 대한 링크에 관심이있다. 우선, 저에게 생각 해낸 원래 기사가 있습니다 : '관리자'가없는 Java 클래스의 이름 지정하기

업데이트 : 요약 답변

그 동안 내가이 질문에서 배운 것을 요약 해 보았습니다.

  • 새로운 은유를 만들지 않도록 노력하십시오 (Nanny)
  • 다른 프레임 워크가하는 일을 살펴보십시오.

이 주제에 관한 더 많은 기사 / 책 :

그리고 응답에서 수집 한 이름 접두사 / 접미사의 현재 목록 (주관적으로!) :

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

그리고 도로를위한 좋은 팁 :

명명 마비를하지 마십시오. 예, 이름은 매우 중요하지만 엄청난 시간을 낭비 할 정도로 중요하지 않습니다. 10 분 안에 좋은 이름을 생각할 수 없다면 계속 나아가 라.


Answers

Manager 이름이나 Helper 를 클래스 이름에 사용하는 것에 대해 생각할 때 필자는 코드 냄새라고 생각합니다. 즉, 아직 올바른 추상화를 찾지 못했다거나 단일 책임 원칙을 위반하고 있으므로 리팩토링하여 더 많은 노력을 기울이고 있습니다. 설계에 따라 이름 지정이 훨씬 쉬워집니다.

그러나 잘 설계된 클래스조차도 (항상) 자신의 이름을 지칭하지 않으며, 비즈니스 모델 클래스 또는 기술 인프라 클래스를 작성하는지 여부에 따라 부분적으로 결정됩니다.

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

기술 인프라 클래스는 우리가 잘 알고있는 도메인을 기술하기 때문에 조금 더 쉽습니다. 필자는 디자인 패턴 이름을 InsertUserCommand, CustomerRepository, 또는 SapAdapter. 와 같은 클래스 이름에 포함시키는 것을 선호합니다 SapAdapter. 의도보다는 의사 소통에 대한 우려를 이해하지만 디자인 패턴은 이러한 두 가지 측면의 디자인과 결합됩니다. 최소한 인프라를 다루는 경우에는 세부 사항을 숨기더라도 구현 디자인 을 투명하게 유지해야합니다.


C # 관련하여 명명 규칙 논리에 대한 많은 정보를 얻기 위해 "프레임 워크 디자인 지침 : 재사용 가능한 .NET 라이브러리의 규칙, 관용구 및 패턴" 을 발견했습니다.

더 구체적인 단어를 찾는 한, 나는 종종 시소러스를 사용하고 관련 단어를 뛰어 넘어서 좋은 단어를 찾으려고 노력합니다. 내가 개발을 진행하면서 더 좋은 이름을 SuchAndSuchManager 가 실제로 여러 클래스로 나누어 져야한다는 사실을 SuchAndSuchManager 그런 다음 사용되지 않는 클래스의 이름이 비 - 발행물.


source-code-wordle.de 에서 살펴볼 수 있습니다. .NET Framework 및 다른 라이브러리의 클래스 이름에서 가장 자주 사용되는 접미사를 분석했습니다.

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

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


thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages"등에 게시 될 수있는 것의 미끄러운 경사면처럼 들립니다.

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

'관리자'는 수업이 실제 세계의 '물건'을 대표하지 않는다는 것을 분명히 보여주기 때문에 좋은 단어입니다. 'AccountsClerk'- 사용자 데이터를 관리하는 클래스인지 또는 자신의 직업에 대한 Accounts Closure 중 누군가를 나타내는 지 어떻게 알 수 있습니까?


비슷한 질문 을했지만 가능하면 .NET 프레임 워크에있는 이름을 복사하려고합니다. Java 및 Android 프레임 워크에서 아이디어를 찾습니다.

Helper , ManagerUtil 은 상태를 포함하지 않고 일반적으로 절차 적 및 정적 인 클래스를 조정하기 위해 첨부하는 피할 수없는 명사입니다. 대안은 Coordinator 입니다.

당신은 이름이있는 자주색 프로 섹 션을 얻을 수 있었고 Minder , Overseer , Supervisor , AdministratorMaster 와 같은 것들을 사용할 수있었습니다.하지만 제가 말했듯이 당신이 익숙한 프레임 워크 이름처럼 유지하는 것이 더 낫습니다.

.NET Framework에서 찾을 수있는 다른 일반적인 접미사 (올바른 용어 인 경우)는 다음과 같습니다.

  • Builder
  • Writer
  • Reader
  • Handler
  • Container

GOF 서적에 정의 된대로 패턴을 사용하여 객체를 명명하고 객체 이름을 지정하면 클래스 이름 지정, 구성 및 의사 전달에 많은 도움이됩니다. 대부분의 사람들은이 명칭 (또는 적어도 그것의 중요한 부분)을 이해할 것입니다.


여기서 중요한 것은 코드의 가시성 범위 내에서 일관성을 유지하는 것입니다. 즉, 코드를보고 / 조작해야하는 모든 사람들이 자신의 명명 규칙을 이해하면 괜찮을 것이라고 생각합니다. 'CompanyThingamabob'및 'UserDoohickey'. 첫 번째 중지는 회사에서 일하는 경우 이름 지정을위한 회사 협약이 있는지 확인하는 것입니다. 회사에 근무하지 않거나 회사에서 일하지 않는 경우 자신에게 맞는 용어를 사용하여 자신 만의 회사를 만들고, 적어도 코드를 자연스럽게 코딩하는 신뢰할 수있는 동료 / 친구 몇 명에게 전달하고 의미가있는 의견을 통합하십시오.

다른 사람의 대회를 널리 받아 들였을 때조차도 페이지에서 뛰어 내리지 않으면 내 책에서 약간의 실수가됩니다. 무엇보다도 먼저 다른 문서를 참조하지 않고 코드를 이해해야하지만 동시에 동일한 업계의 동일한 분야에있는 다른 사람에게는 이해할 수 없을 정도로 충분히 포괄적 일 필요가 있습니다.


실제 세계를 정확하게 모델링했다면 xxxFactory , xxxManager 또는 xxxRepository 클래스 없이도 할 수 있습니다.

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

;-)


나는 당신이 사용하는 시스템의 패턴을 고려할 것이다. 명명 규칙 / 클래스의 분류 / 분류는 사용 된 패턴에 의해 정의되는 경향이있다. 개인적으로, 나는 다른 사람이 내 코드를 집어 들고 실행할 수있는 가장 가능성있는 방법이기 때문에 이러한 명명 규칙을 고수합니다.

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

정보를 얻으 려면 디자인 패턴 과 같은 책을 읽으십시오. 훌륭한 책이며, 코드를 사용하고있는 곳을 명확히하는 데 도움이 될 것입니다 - 아직 사용하지 않으 셨다면! ;영형)

나는 당신의 패턴이 잘 선택되고 적절하게 사용되는 한 그렇게 생각하지 않는다. 그렇다면 꽤 단순하고 간단한 클래스 이름으로 충분할 것이다!


나는 모두 좋은 이름을 원하며 종종 사물의 이름을 선택할 때 세심한주의를 기울이는 것이 중요하다는 점을 씁니다. 이와 똑같은 이유 때문에, 물건을 명명 할 때 나는 은유를 경계합니다. 원래의 질문에서, "공장"과 "싱크로 나이저"는 그들이 의미하는 것처럼 좋은 이름처럼 보입니다. 그러나 "목자"와 "유모"는 은유에 기초하고 있기 때문에 그렇지 않습니다. 코드의 클래스는 말 그대로 유모가 될 수 없습니다. 실생활 보모가 아기 나 아이들을 돌보는 것과 매우 흡사하기 때문에 보모라고 부릅니다. 그것은 비공식적 인 연설에서는 괜찮지 만 언제 누가 알 수 있는지 누가 알 수 있는지에 의해 유지되어야하는 코드에 클래스 이름을 부여하는 것은 좋지 않습니다 (제 의견으로는).

왜? 왜냐하면 은유는 문화에 의존하고 종종 개인에 의존하기도하기 때문입니다. 너에게 "유모"라는 이름을 지어주는 것은 분명 할 수 있지만, 아마도 다른 사람에게 그렇게 명확하지 않을 수도 있습니다. 개인적 용도로만 사용하는 코드를 작성하지 않는 한, 그 것에 의존해서는 안됩니다.

어떤 경우이든 대회가 은유를 만들거나 깨뜨릴 수 있습니다. "팩토리"자체의 사용은 은유를 기반으로하지만, 프로그래밍 세계에서 꽤 잘 알려져 있고 현재 꽤 많이 사용되어 왔기 때문에 사용하는 것이 안전하다고 말합니다. 그러나 "유모"와 "목자"는 받아 들일 수 없습니다.






design-patterns oop naming-conventions naming