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

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

---

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

특정 디자인 패턴을 구현하는 클래스에는 잘 알려진 패턴 이름 (예 : 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 분 안에 좋은 이름을 생각할 수 없다면 계속 진행하세요.

---

If a good name doesn't spring to mind, I would probably question whether there is a deeper problem - is the class serving a good purpose? If it is, naming it should be pretty straightforward.

---

If your "FooProcessor" really does process foos, then don't be reluctant to give it that name just because you already have a BarProcessor, BazProcessor, etc. When in doubt, obvious is best. The other developers who have to read your code may not be using the same thesaurus you are.

That said, more specificity wouldn't hurt for this particular example. "Process" is a pretty broad word. Is it really a "FooUpdateProcessor" (which might become "FooUpdater"), for example? You don't have to get too "creative" about the naming, but if you wrote the code you probably have a fairly good idea of what it does and doesn't do.

Finally, remember that the bare class name isn't all that you and the readers of your code have to go on - there are usually namespaces in play as well. Those can often give readers enough context to see clearly what your class if really for, even if its bare name is fairly generic.

참고URL : https://stackoverflow.com/questions/38019/whats-the-best-approach-to-naming-classes