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

115

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

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

java naming-conventions

— JR.
소스

82

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

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

— 어치
소스

9

그리고 4 번 :-)에 대한 IV - 그러나 이었다 차이 화물 , freightcost 및 frght은 ?

— KajMagnus

4

@KayMagnus 그 게시물은 1 년이 넘었지만 제가 회상 하듯이 그중 하나는 주문 내용을 변경하기 전에 잠재적으로 운임 비용이 기록 된 현재 운임 비용이었습니다. 다른 하나는 표에서 가져온 표준 운임 비용입니다. 세 번째는 해외 배송과 같은 특수한 경우에 사용되는 계산 된 비용입니다. 최소한 "currFreight", "stdFreight", "calcFreight"라고 말하지 않은 이유처럼 말입니다. 그것은 적어도 clude를 제공했을 것입니다.

— 제이

좋아, 설명 :-) 흥미로운 이상한 코드 예를 들어, 덕분에 생각

— KajMagnus

31

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

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

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

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

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

org.mycompany.account.AccountHelper

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

— 반지 전달자
소스

5

그 도우미는 Utils보다 더 구체적 일 것입니다.

— KajMagnus

1

예, 저는이 접근 방식을 좋아합니다. 더 논리적입니다.

— 코난

3

링크가 끊어졌습니다. 다른 하나를 찾았습니다 .

— Chavjoh

22

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

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

— ColinD
소스

2

구글 구아바는이 패턴을 사용

— Jherico

11

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

— 아이토
소스

2

그것은 '기능별 패키지' 접근 방식 에서 옳은 일이 아닙니다 .

— jpangamarca

1

@jpangamarca 링크 한 기사에는 '기능별 패키지'예제에서 "util"패키지가 있습니다. 나는 실제로 어떤 종류의 유틸리티 기능 / 계층을 종종 피할 수 없다고 생각합니다.

— kapex

1

@kapex 내가 생각하는 저자의 감독. tld.organization.app.util패키지 (가 할 수 있지만 안) 존재해서는 안, 임의의 수의 tld.organization.app.feature.util패키지는 완벽하게 정상입니다.

— jpangamarca

3

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

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

— KSwift87
소스