[java] Java의 유틸리티 클래스에 대한 명명 규칙

Java로 유틸리티 클래스를 작성할 때 따라야 할 좋은 지침은 무엇입니까?

패키지는 “util”또는 “utils”여야합니까? ClassUtil 또는 ClassUtils입니까? 클래스는 언제 “Helper”또는 “Utility”입니까? 유틸리티 또는 유틸리티? 아니면 이들의 혼합물을 사용합니까?

표준 Java 라이브러리는 Utils와 Utilities를 모두 사용합니다.

  • javax.swing.Utilities
  • javax.print.attribute.AttributeSetUtilities
  • javax.swing.plaf.basic.BasicGraphicsUtils

Apache는 다양한 Util 및 Utils를 사용하지만 대부분은 Utils입니다.

  • org.apache.commons.modeler.util.DomUtil
  • org.apache.commons.modeler.util.IntrospectionUtils
  • org.apache.commons.io.FileSystemUtils
  • org.apache.lucene.wordnet.AnalyzerUtil
  • org.apache.lucene.util.ArrayUtil
  • org.apache.lucene.xmlparser.DOMUtils

Spring은 많은 Helper 및 Utils 클래스를 사용합니다.

  • org.springframework.web.util.UrlPathHelper
  • org.springframework.core.ReflectiveVisitorHelper
  • org.springframework.core.NestedExceptionUtils
  • org.springframework.util.NumberUtils

그렇다면 유틸리티 클래스의 이름은 어떻게 지정합니까?



답변

그러한 많은 관습과 마찬가지로 중요한 것은 사용하는 관습이 아니라 일관되게 사용하는 것입니다. 예를 들어, 세 개의 유틸리티 클래스가 있고이를 CustomerUtil, ProductUtils 및 StoreUtility라고 부르는 경우 클래스를 사용하려는 다른 사람들은 계속해서 혼란스러워하고 실수로 CustomerUtils를 입력하고 조회해야하며 몇 번 저주합니다. (한 번은 연사가 “1”, “2nd”, “C”라는 세 가지 요점으로 연설의 개요를 보여주는 슬라이드를 올리는 일관성에 대한 강의를 들었습니다.)

CustomerUtil 및 CustomerUtility를 갖는 것과 같이 철자의 미묘한 차이 만 다른 두 개의 이름을 절대로 만들지 마십시오. 두 개의 클래스를 만들어야하는 타당한 이유가 있다면, 그들에 대해 뭔가 다른 것이있을 것입니다. 그리고 그 이름은 적어도 그 차이가 무엇인지 우리에게 단서를 제공해야합니다. 하나는 이름 및 주소와 관련된 유틸리티 기능을 포함하고 다른 하나는 주문과 관련된 유틸리티 기능을 포함하는 경우 CustomerNameAndAddressUtil 및 CustomerOrderUtil 또는 이와 같은 일부를 호출하십시오. 이름에서 의미없는 미묘한 차이를 볼 때 나는 정기적으로 미쳐 버립니다. 어제처럼 저는 “freight”, “freightcost”및 “frght”라는 세 개의화물 비용 필드가있는 프로그램을 작업하고있었습니다. 나는 그들 사이의 차이점을 알아 내기 위해 코드를 연구해야했다.


답변

이에 대한 Java 세계에는 표준 규칙 / 규칙이 없습니다. 그러나 @colinD가 언급했듯이 클래스 이름 끝에 “s”를 추가하는 것을 선호합니다.

그것은 마스터 자바 API 디자이너 Josh Bloch가하는 일에 꽤 표준 인 것 같습니다 (자바 컬렉션과 구글 컬렉션)

Helper와 Util이 진행되는 한, 패키지의 특정 기능을 달성하는 데 도움이되는 API가있을 때 Helper라고 부를 것입니다 (패키지를 모듈 구현으로 고려). Util은 모든 컨텍스트에서 호출 될 수 있음을 의미합니다.

예를 들어 은행 계좌와 관련된 응용 프로그램에서 모든 숫자 특정 유틸리티 정적 API는 org.mycompany.util.Numbers

API를 지원하는 모든 “계정”특정 비즈니스 규칙은

org.mycompany.account.AccountHelper

결국 더 나은 문서화와 더 깨끗한 코드를 제공하는 문제입니다.


답변

유형이 인터페이스이거나 제어하지 않는 클래스 일 때 유형 이름에 “s”를 추가하는 규칙을 좋아합니다. JDK의 예는 다음 Collections과 같습니다.Executors . Google 컬렉션에서 사용되는 규칙이기도합니다.

제어 할 수있는 클래스 를 다룰 때 유틸리티 메서드는 일반적으로 클래스 자체에 속한다고 생각합니다.


답변

나는 ‘utils’가 패키지 이름이어야한다고 생각합니다. 클래스 이름은 내부 논리의 목적을 지정해야합니다. 접미사 -util (s) 추가는 중복됩니다.


답변

나는 “도우미”와 “유틸리티”라는 단어가 같은 의미로 사용된다고 확신합니다. 어쨌든 당신이 제공 한 예제로 판단하면, 당신의 클래스 이름이 약어 (또는 “DomUtil”과 같은 약어가있는 경우)라고 말하고 패키지를 “whatever.WhateverUtil”(또는 패키지에 유틸리티가 둘 이상있는 경우 Utils) ). 그렇지 않으면 약어 대신 전체 이름이 있으면 “whatever.WhateverUtilities”라고 부릅니다.

그것은 정말로 당신에게 달려 있지만, 코더가 당신이 말하는 것을 아는 한, 당신은 갈 수 있습니다. 그래도 누군가를위한 직업으로이 일을 전문적으로하고 있다면 제 조언을 받기 전에 코딩 표준이 무엇인지 물어보세요. 직업을 유지하는 데 도움이되는 것과 상관없이 항상 상점 표준을 따르십시오. 🙂


답변