유틸리티 클래스는 사악합니까? [닫은]

나는이 실을 보았다

"유틸리티"클래스가 악한 경우 일반 코드를 어디에 두어야합니까?

그리고 유틸리티 클래스가 왜 나쁜지 생각 했습니까?

수십 개의 클래스 깊이가있는 도메인 모델이 있다고 가정 해 보겠습니다. 인스턴스를 xml-ify 할 수 있어야합니다. 부모에게 toXml 메서드를 만드나요? MyDomainXmlUtility.toXml 도우미 클래스를 만들어야합니까? 이것은 비즈니스 요구가 전체 도메인 모델에 걸쳐있는 경우입니다. 실제로 인스턴스 메서드로 속합니까? 애플리케이션의 xml 기능에 대한 많은 보조 메서드가 있다면 어떨까요?

유틸리티 클래스는 정확히 악한 것은 아니지만 좋은 객체 지향 디자인을 구성하는 원칙을 위반할 수 있습니다. 좋은 객체 지향 디자인에서 대부분의 클래스는 단일 항목과 모든 속성 및 작업을 나타내야합니다. 사물에 대해 작업하는 경우 해당 메서드는 해당 사물의 구성원이어야합니다.

그러나 유틸리티 클래스를 사용하여 여러 메서드를 함께 그룹화 할 수있는 경우가 있습니다. java.util.Collections 모든 Java 컬렉션에서 사용할 수있는 여러 유틸리티를 제공하는 클래스가 있습니다. 이들은 특정 유형의 Collection에만 국한된 것이 아니라 모든 Collection에서 사용할 수있는 알고리즘을 구현합니다.

실제로해야 할 일은 디자인에 대해 생각하고 방법을 배치하는 것이 가장 적합한 위치를 결정하는 것입니다. 일반적으로 클래스 내부의 작업입니다. 그러나 때로는 실제로 유틸리티 클래스입니다. 그러나 유틸리티 클래스를 사용할 때는 임의의 메서드를 그 안에 넣지 말고 목적과 기능에 따라 메서드를 구성하십시오.

일반적인 합의는 유틸리티 클래스가 그 자체로 악하지 않다는 것 입니다. 다음과 같이 신중하게 사용해야합니다.

• 정적 유틸리티 메소드를 일반적이고 재사용 가능하도록 설계하십시오. 상태 비 저장인지 확인하십시오. 즉, 정적 변수가 없습니다.

• 유틸리티 메서드가 많으면 개발자가 쉽게 찾을 수 있도록 클래스로 분할합니다.

• 도메인 클래스의 정적 또는 인스턴스 메서드가 더 나은 솔루션이 될 수있는 유틸리티 클래스를 사용하지 마십시오. 예를 들어, 추상 기본 클래스 또는 인스턴스화 가능한 도우미 클래스의 메서드가 더 나은 솔루션인지 고려하십시오.

• Java 8 이상에서는 인터페이스의 "기본 메소드"가 유틸리티 클래스보다 더 나은 옵션 일 수 있습니다. ( 예를 들어 Java 8의 기본 메소드와 추상 클래스가있는 인터페이스를 참조하십시오 .)

이 질문을 보는 또 다른 방법은 인용 된 질문에서 "유틸리티 클래스가"악한 "경우" 라는 말이 밀려 오는 주장 이라는 것을 관찰하는 것입니다 . 나 같은 질문 :

"돼지가 날 수 있다면 우산을 가져 가야하나요?"

위의 질문에서 나는 실제로 돼지가 날 수 있다고 말하는 것이 아닙니다 ... 또는 그들이 날 수 있다는 제안에 동의합니다 .

전형적인 "xyz is evil" 진술은 극단적 인 관점을 제시함으로써 생각하게 만드는 수사적 장치입니다. 그것들은 거의 (만약 있다면) 문자 그대로 사실의 진술로 의도 된 것이 아닙니다.

유틸리티 클래스는이를 지원하는 데이터로 책임을 그룹화하지 못하기 때문에 문제가 있습니다.

그러나 그것들은 매우 유용하며 나는 더 철저한 리팩터링을하는 동안 영구적 인 구조 또는 디딤돌로 항상 구축합니다.

A로부터 클린 코드의 관점 유틸리티 클래스는 단일 책임과 오픈 폐쇄 원칙을 위반. 변경해야 할 이유가 많으며 설계 상 확장 할 수 없습니다. 리팩토링하는 동안에는 중간 부분으로 만 존재해야합니다.

나는 그것이 악해지기 시작한다고 생각합니다.

1) 너무 커집니다 (이 경우 의미있는 범주로 그룹화).
2) 정적 메서드가 아니어야하는 메서드가 있습니다.

그러나 이러한 조건이 충족되지 않는 한 매우 유용하다고 생각합니다.

경험의 법칙

이 문제는 두 가지 관점에서 볼 수 있습니다.

• 사무용 겉옷 *Util 방법은 종종 잘못된 코드 디자인 또는 지연 명명 규칙의 제안입니다.
• 재사용 가능한 교차 도메인 상태 비 저장 기능을위한 합법적 인 설계 솔루션입니다. 거의 모든 일반적인 문제에 대해 기존 솔루션이 있습니다.

예 1. 올바른 사용법 util 클래스 / 모듈 . 외부 라이브러리 예

대출과 신용 카드를 관리하는 애플리케이션을 작성하고 있다고 가정 해 보겠습니다. 이러한 모듈의 데이터는 웹 서비스를 통해 json형식으로 노출 됩니다. 이론적으로는 객체를에있는 문자열로 수동으로 변환 할 수 json있지만, 이는 바퀴를 재발 명 할 것입니다. 올바른 솔루션은 Java 객체를 원하는 형식으로 변환하는 데 사용되는 외부 라이브러리를 두 모듈에 모두 포함하는 것입니다. (예제 이미지에서는 gson 을 표시 했습니다 )

예 2. util클래스 / 모듈 의 올바른 사용법 . 나만의 글쓰기util다른 팀원들에게 변명없이

유스 케이스로 우리는 두 개의 애플리케이션 모듈에서 몇 가지 계산을 수행해야한다고 가정하지만 둘 다 폴란드에 공휴일이 언제 있는지 알아야합니다. 이론상 모듈 내에서 이러한 계산을 수행 할 수 있지만이 기능을 추출하여 모듈을 분리하는 것이 좋습니다.

여기에 작지만 중요한 세부 사항이 있습니다. 작성한 클래스 / 모듈은라고 부르지 HolidayUtil않고 PolishHolidayCalculator. 기능적으로는 util클래스이지만 일반적인 단어는 피할 수있었습니다.

유틸리티 클래스는 더 나은 이름을 생각하기에는 너무 게으르다는 것을 의미하기 때문에 나쁩니다. :)

즉, 나는 게으르다. 때때로 당신은 일을 끝내야하고 당신의 마음은 공란 .. "유틸리티"클래스가 들어 오기 시작하는 때입니다.

지금이 질문을 되돌아 보면 C # 확장 메서드가 유틸리티 클래스의 필요성을 완전히 파괴한다고 말하고 싶습니다. 그러나 모든 언어가 이러한 천재적 구조를 가지고있는 것은 아닙니다.

기존 객체에 바로 새 함수를 추가 할 수있는 JavaScript도 있습니다.

하지만 C ++과 같은 오래된 언어에서이 문제를 해결하는 우아한 방법이 있는지 잘 모르겠습니다.

좋은 OO 코드는 작성하기가 다소 어렵고, 좋은 OO를 작성하려면 적절한 기능 코드를 작성하는 것보다 더 많은 시간 / 지식이 필요하기 때문에 찾기가 어렵습니다.

그리고 예산이 부족할 때 상사는 하루 종일 여러 수업을 작성하는 데 항상 기뻐하지 않습니다 ...

나는 유틸리티 클래스가 악하다는 데 전적으로 동의하지 않습니다.

유틸리티 클래스는 어떤면에서 OO 원칙을 위반할 수 있지만 항상 나쁜 것은 아닙니다.

예를 들어 value와 일치하는 모든 하위 문자열의 문자열을 정리하는 함수를 원한다고 가정 해보십시오 x.

stl c ++ (현재)는 이것을 직접 지원하지 않습니다.

다음과 같은 다형성 확장을 만들 수 있습니다. std::string .

그러나 문제는 프로젝트에서 사용하는 모든 문자열이 확장 된 문자열 클래스가되기를 정말로 원합니까?

OO가 말이 안되는 때가 있는데, 이것이 바로 그 중 하나입니다. 우리는 프로그램이 다른 프로그램과 호환되기를 원하므로 계속 std::string해서 클래스 StringUtil_(또는 무언가)를 만들 것입니다.

클래스 당 하나의 유틸리티를 고수하는 것이 가장 좋습니다. 모든 클래스에 대해 하나의 유틸리티를 사용하거나 하나의 클래스에 대해 여러 유틸리티를 사용하는 것은 어리석은 일입니다.

디자이너가 코드를 넣을 적절한 장소를 생각할 수 없기 때문에 유틸리티를 브랜드화하는 것은 매우 쉽습니다. 진정한 "유틸리티"는 거의 없습니다.

경험상 일반적으로 처음 사용되는 패키지에 코드를 보관 한 다음 나중에 다른 곳에서 실제로 필요하다고 판단되는 경우에만 더 일반적인 위치로 리팩토링합니다. 유일한 예외는 유사 / 관련 기능을 수행하는 패키지가 이미 있고 코드가 여기에 가장 적합한 경우입니다.

상태 비 저장 정적 메서드를 포함하는 유틸리티 클래스가 유용 할 수 있습니다. 이들은 종종 단위 테스트가 매우 쉽습니다.

Java 8을 사용하면 인터페이스에서 정적 메서드를 사용할 수 있습니다. 문제가 해결되었습니다.

대부분의 Util 클래스는 다음과 같은 이유로 좋지 않습니다.

1. 그들은 방법의 범위를 넓 힙니다. 그들은 그렇지 않으면 비공개가 될 코드를 공개합니다. util 메서드가 별도의 클래스에서 여러 호출자에 의해 필요하고 안정적이라면 (즉, 업데이트가 필요하지 않음) 개인 도우미 메서드를 호출 클래스에 복사하여 붙여 넣는 것이 좋습니다. 일단 API로 노출하면 jar 구성 요소에 대한 공개 진입 점이 무엇인지 이해하기가 더 어려워집니다 (메서드 당 하나의 부모가있는 계층 구조라는 트리 구조를 유지합니다. 이것은 다음과 같은 경우 더 어려운 구성 요소로 정신적으로 분리하는 것이 더 쉽습니다. 여러 부모 메서드에서 호출 된 메서드가 있습니다.)
2. 그들은 죽은 코드를 초래합니다. 시간이 지남에 따라 Util 메서드는 앱이 발전함에 따라 사용되지 않으며 결국 사용되지 않는 코드로 인해 코드 기반이 오염됩니다. 그것이 비공개로 남아 있었다면 컴파일러는 메서드가 사용되지 않았으며 제거 할 수 있다고 알려줄 것입니다 (가장 좋은 코드는 코드가 전혀 없다는 것입니다). 이러한 방법을 개인용이 아닌 것으로 만들면 사용하지 않는 코드를 제거하는 데 도움이되는 컴퓨터가 무력해질 것입니다. 모든 컴퓨터가 알고있는 다른 jar 파일에서 호출 될 수 있습니다.

정적 라이브러리와 동적 라이브러리에는 몇 가지 비유가 있습니다.

클래스에 메서드를 추가 할 수없는 경우 (예 Account: Jr. 개발자의 변경에 대해 잠겨 있음) 다음과 같이 몇 가지 정적 메서드를 Utilities 클래스에 추가합니다.

public static int method01_Account(Object o, String... args) {
    Account acc = (Account)o;
    ...
    return acc.getInt();
}  

유틸리티 클래스가 항상 악한 것은 아닙니다. 그러나 광범위한 기능에 공통적 인 메서드 만 포함해야합니다. 제한된 수의 클래스 중에서 만 사용할 수있는 메서드가있는 경우 추상 클래스를 공통 부모로 만들고 그 안에 메서드를 넣는 것이 좋습니다.