클래스 이름을 지정하는 가장 좋은 방법은 무엇입니까?

훌륭하고 정확한 클래스 이름을 찾는 것은 매우 어렵습니다. 올바르게 수행하면 코드가 더 자체 문서화되고 더 높은 수준의 추상화에서 코드에 대한 추론을위한 어휘를 제공합니다.

특정 디자인 패턴을 구현하는 클래스에는 잘 알려진 패턴 이름 (예 : FooFactory, FooFacade)을 기반으로 이름이 지정 될 수 있으며 도메인 개념을 직접 모델링하는 클래스는 문제 도메인에서 이름을 가져올 수 있지만 다른 클래스는 어떻습니까? 영감이 부족하고 일반 클래스 이름 (예 : FooHandler, FooProcessor, FooUtils 및 FooManager)을 사용하지 않으려는 프로그래머의 시소러스와 같은 것이 있습니까?

Kent Beck의 Implementation Patterns 에서 몇 가지 구절을 인용하겠습니다 .

단순 수퍼 클래스 이름

"[...] 이름은 짧고 펀치감이 있어야합니다. 그러나 이름을 정확하게 만들기 위해 여러 단어가 필요할 때가 있습니다.이 딜레마에서 벗어나는 방법은 계산에 대한 강력한 은유를 선택하는 것입니다. 은유를 염두에두고 하나의 단어는 그들에게 풍부한 연관성, 연결성 및 의미를 가져옵니다. 예를 들어, HotDraw 드로잉 프레임 워크에서 드로잉의 개체에 대한 제 이름은 DrawingObject 였습니다 . Ward Cunningham은 타이포그래피 은유와 함께 왔습니다. 드로잉은 다음과 같습니다. 인쇄 된 레이아웃 페이지입니다. 페이지의 그래픽 항목은 도형이므로 클래스는 Figure 가되었습니다 . 은유의 맥락에서 Figure 는 동시에 DrawingObject 보다 짧고 풍부하며 정확 합니다. "

정규화 된 하위 클래스 이름

"하위 클래스의 이름에는 두 가지 작업이 있습니다. 그들은 그들이 어떤 클래스와 어떻게 다른지 전달해야합니다. [...] 계층의 루트에있는 이름과 달리, 하위 클래스 이름은 대화에서 거의 자주 사용되지 않습니다. 그래서 그들은 간결한 대가로 표현할 수 있습니다. [...]

계층의 루트 역할을하는 하위 클래스에 고유 한 간단한 이름을 지정합니다. 예를 들어, HotDraw 에는 Figure가 선택 될 때 Figure 편집 작업을 제공 하는 Handle 클래스 가 있습니다. Figure 를 확장 함에도 불구하고 간단히 Handle 이라고 합니다. 전체 핸들 패밀리가 있으며 가장 적절한 이름은 StretchyHandle 및 TransparencyHandle 입니다. Handle 은 자체 계층 구조의 루트 이기 때문에 정규화 된 하위 클래스 이름보다 단순한 슈퍼 클래스 이름이 필요합니다.

하위 클래스 이름 지정의 또 다른 주름은 다중 수준 계층 구조입니다. [...] 즉시 수퍼 클래스에 수정자를 맹목적으로 추가하는 대신 독자의 관점에서 이름을 생각해보십시오. 이 수업이 어떤 수업인지 알기 위해 필요한 수업은 무엇입니까? 해당 수퍼 클래스를 서브 클래스 이름의 기초로 사용하십시오. "

상호 작용

인터페이스에 대해 어떻게 생각하는지에 따라 두 가지 스타일의 명명 인터페이스가 달라집니다. 구현이없는 클래스 인 인터페이스는 마치 클래스 인 것처럼 이름을 지정해야합니다 ( Simple Superclass Name , Qualified Subclass Name ). 이 스타일의 이름 지정에 대한 한 가지 문제점은 이름 지정 클래스에 도달하기 전에 좋은 이름이 사용된다는 것입니다. File 이라는 인터페이스에는 ActualFile , ConcreteFile 또는 (yuck!) FileImpl 과 같은 구현 클래스가 필요합니다 .(접미사와 약어 모두). 일반적으로, 추상 객체가 인터페이스로 구현 되든 수퍼 클래스로 구현 되든 관계없이 구체적 또는 추상 객체를 다루는 지 여부를 전달하는 것은 중요하지 않습니다. 인터페이스와 슈퍼 클래스 사이의 구분을 연기하는 것은 이러한 스타일의 이름 지정에 의해 잘 지원되므로 나중에 필요할 경우 마음을 바꿀 수 있습니다.

때로는 구체적인 클래스의 이름을 지정하는 것이 인터페이스 사용을 숨기는 것보다 커뮤니케이션에 더 중요합니다. 이 경우 인터페이스 이름 앞에 "I"를 붙입니다. 인터페이스가 IFile 이면 클래스는 간단히 File 이라고 할 수 있습니다 .

더 자세한 논의를 원하시면 책을 구입하세요! 그것은 가치! :)

항상 MyClassA, MyClassB로 가십시오-좋은 알파 정렬을 허용합니다 ..

농담이야!

이것은 좋은 질문이며 얼마 전에 경험 한 것입니다. 나는 직장에서 코드베이스를 재구성하고 어디에 무엇을 넣을지, 무엇을 부를지에 문제가 있었다 ..

진짜 문제?

수업을 너무 많이 했어요. 단일 책임 원칙 을 고수 하면 모든 것이 훨씬 더 멋지게 결합됩니다. 하나의 모 놀리 식 PrintHandler 클래스 대신 PageHandler , PageFormatter (등)로 분류 한 다음 마스터 프린터 클래스 를 가질 수 있습니다. 모두 함께 가져옵니다.

내 re-org에서 시간이 걸렸지 만 결국 많은 중복 코드를 비닝하고 코드베이스를 훨씬 더 논리적으로 만들고 클래스에 추가 메서드를 던지기 전에 생각할 때 많은 것을 배웠습니다.

나는 할 수 없습니다 그러나 클래스 이름으로 패턴 이름 등을 넣어 좋습니다. 클래스 인터페이스는 (싱글 톤에 대한 생성자를 숨기는 것과 같이) 명확하게 만들어야합니다. 클래스가 일반 용도로 사용되는 경우 일반 이름에 문제가 없습니다.

행운을 빕니다!

좋은 API 디자인 에 대한 Josh Bloch의 훌륭한 이야기 에는 몇 가지 좋은 조언이 있습니다.

• 수업은 한 가지를해야하고 잘해야합니다.
• 클래스의 이름을 지정하거나 설명하기 어려운 경우 이전 글 머리 기호의 조언을 따르지 않을 수 있습니다.
• 클래스 이름은 클래스가 무엇인지 즉시 전달해야합니다.
• 좋은 이름은 좋은 디자인을 만듭니다.

문제가 노출 된 내부 클래스의 이름을 지정하는 것이라면이를 더 큰 클래스로 통합해야합니다.

문제가 많은 다른 작업을 수행하는 클래스의 이름을 지정하는 것이라면 여러 클래스로 나누는 것을 고려해야합니다.

이것이 공용 API에 대한 좋은 조언이라면 다른 클래스에 해를 끼칠 수 없습니다.

당신이 이름으로 붙어 있다면, 때로는 그것을주고 어떤 나중에 개정에 대한 의지와 반 재치있는 이름 것은 좋은 전략이다.

명명 마비를 얻지 마십시오. 예, 이름은 매우 중요하지만 엄청난 시간을 낭비 할만큼 중요하지 않습니다. 10 분 안에 좋은 이름을 생각할 수 없다면 계속 진행하세요.

좋은 이름이 떠오르지 않으면 더 깊은 문제가 있는지 질문 할 것입니다. 수업이 좋은 목적을 가지고 있는가? 그렇다면 이름 지정은 매우 간단해야합니다.

"FooProcessor"가 실제로 foo를 처리하는 경우 BarProcessor, BazProcessor 등이 이미 있다고해서 이름을 지정하는 것을 주저하지 마십시오. 확실하지 않은 경우 분명한 것이 가장 좋습니다. 당신의 코드를 읽어야하는 다른 개발자들은 당신과 같은 동의어 사전을 사용하지 않을 수 있습니다.

즉,이 특정 예에서는 더 많은 특이성이 손상되지 않습니다. "프로세스"는 매우 광범위한 단어입니다. 예를 들어, 실제로 "FooUpdateProcessor"( "FooUpdater"가 될 수 있음)입니까? 명명에 대해 너무 "창조적"일 필요는 없지만 코드를 작성했다면 코드가 수행하는 작업과 수행하지 않는 작업에 대해 상당히 잘 알고있을 것입니다.

마지막으로, 베어 클래스 이름이 여러분과 여러분의 코드 독자가 계속 진행해야하는 전부는 아니라는 점을 기억하십시오. 일반적으로 네임 스페이스도 사용됩니다. 그것들은 종종 독자들에게 당신의 클래스가 정말로 무엇을위한 것인지 명확하게 볼 수있는 충분한 컨텍스트를 제공 할 수 있습니다.