클래스에 정적 필드와 메서드 만있는 것이 나쁜 습관입니까?

클래스에 정적 필드와 메서드 만있는 것이 나쁜 습관입니까?

---

정적 멤버 변수와 정적 메서드 로만 구성된 클래스가 있습니다 . 기본적으로 범용 유틸리티 클래스로 사용됩니다.

클래스에 정적 멤버 변수와 정적 메서드 만 포함하는 것은 나쁜 습관입니까?

---

아니요, 전혀 그렇게 생각하지 않습니다. 특정 인스턴스에 실제로 의존하지 않는 인스턴스 메서드로 가득 찬 클래스를 갖는 것은 더 나쁜 습관입니다. 정적으로 만들면 사용자에게 정확히 어떻게 사용되는지 알 수 있습니다. 또한 이러한 방식으로 불필요한 인스턴스화를 방지합니다.

편집 : 나중에 생각해 보면 일반적으로 "그냥"언어 기능을 사용하지 않는 것이 좋다고 생각합니다. 또는 그것이 "Java 방식"이라고 생각하기 때문입니다. 나는 정적 유틸리티 메소드로 가득 찬 클래스를 가지고 있던 첫 직장을 떠 올렸고, 수석 프로그래머 중 한 명이 내 모든 메소드를 "글로벌"로 만들어서 Java의 OO 기능을 완전히 활용하지 못했다고 말했습니다. 그녀는 6 개월 후에 팀에 없었습니다.

---

클래스에 내부 상태가없고 본질적으로 리프 클래스 (유틸리티 클래스가이 범주에 속함)라고하는 한, 즉 다른 클래스와 독립적입니다. 그것은 괜찮습니다.

그 Math클래스는 좋은 예입니다.

---

합리적으로 들립니다.

참고 :이 작업을 수행하는 클래스에는 프로그래머가 정적 클래스의 인스턴스를 만들려고하면 컴파일러에서 오류가 발생하도록 인수가없는 전용 생성자가있는 경우가 많습니다.

---

정적 메서드는 나를 크게 걱정하지 않습니다 (테스트 제외).

일반적으로 정적 멤버가 문제입니다. 예를 들어 앱이 클러스터 된 경우 어떻게됩니까? 시작 시간은 어떻습니까? 어떤 종류의 초기화가 일어나고 있습니까? 이러한 문제 등을 고려하려면 Gilad Bracha 의이 기사 를 확인하십시오 .

---

완벽하게 합리적입니다. 실제로 C #에서는 이러한 목적을 위해 특별히 static 키워드를 사용하여 클래스를 정의 할 수 있습니다.

---

그것에 푹 빠지지 마십시오. java.lang.Math 클래스는 수학 함수에 관한 것입니다. 예를 들어 표준 API에없는 일반적인 문자열 처리 함수를 포함하는 StringUtilities 클래스가있을 수도 있습니다. 그러나 예를 들어 클래스 이름이 Utilities 인 경우 분할 할 수있는 힌트입니다.

---

Java는 특별히 정적 가져 오기를 도입했습니다. ( http://en.wikipedia.org/wiki/Static_import )

정적 가져 오기는 필드가 정의 된 클래스를 지정하지 않고 Java 코드에서 사용하기 위해 클래스에서 멤버 (필드 및 메소드)가 공용 정적로 정의 된 Java 프로그래밍 언어에 도입 된 기능입니다. 이 기능은 버전 5.0의 언어에 도입되었습니다.

이 기능은 원래 필드를 정의한 클래스를 참조하지 않고도 코드에 상수를 포함 할 수있는 형식 안전 메커니즘을 제공합니다. 또한 상수 인터페이스를 생성하는 관행을 폐기하는 데 도움이됩니다. 상수 만 정의한 다음 해당 인터페이스를 구현하는 클래스를 작성하는 인터페이스는 부적절한 인터페이스 사용으로 간주됩니다 [1].

이 메커니즘은 클래스의 개별 멤버를 참조하는 데 사용할 수 있습니다.

 import static java.lang.Math.PI;
 import static java.lang.Math.pow;

또는 클래스의 모든 정적 멤버 :

 import static java.lang.Math.*;

---

(다른 사람들이 이미 언급했듯이) 합리적인 해결책처럼 들린다는 생각에는 동의하지만, 고려할 수있는 한 가지는 디자인 관점에서 "유용성"을위한 클래스가있는 이유입니다. 이러한 기능은 전체 시스템에서 진정으로 일반적인 것입니까, 아니면 아키텍처 내의 특정 객체 클래스와 실제로 관련이 있습니까?

당신이 그것에 대해 생각하는 한, 나는 당신의 해결책에 문제가 없다고 생각합니다.

---

Java SDK 의 Collections 클래스에는 정적 멤버 만 있습니다.

그래서, 당신이 적절한 정당성을 가지고 있다면, 그것은 나쁜 디자인이 아닙니다.

---

유틸리티 메서드는 종종 정적 메서드 (예 :) 만있는 클래스에 배치됩니다 StringUtils. 전역 상수도 자체 클래스에 배치되므로 나머지 코드 ( public final static특성) 에서 가져올 수 있습니다 .

두 용도 모두 매우 일반적이며 인스턴스화되지 않도록 개인 기본 생성자가 있습니다. final 클래스를 선언하면 정적 메서드를 재정의하려는 실수를 방지 할 수 있습니다.

에 의한 경우 static member variables전역 상수를 의미하지 않았다, 당신은 자신의 클래스에 해당 변수에 액세스하는 방법을 배치 할 수 있습니다. 이 경우 해당 변수가 코드에서 수행하는 작업에 대해 설명 할 수 있습니까?

---

이것은 일반적으로 유틸리티 클래스가 설계되는 방식이며 잘못된 것은 없습니다. 등 유명한 예 o.a.c.l.StringUtils, o.a.c.d.DbUtils, o.s.w.b.ServletRequestUtils, 등

---

객체 지향 디자인에 대한 엄격한 해석에 따르면 유틸리티 클래스는 피해야합니다.

문제는 엄격한 해석을 따르면 많은 일을 수행하기 위해 클래스를 일종의 객체로 강제해야한다는 것입니다.

Java 디자이너조차도 유틸리티 클래스를 만듭니다 (java.lang.Math가 떠 오릅니다)

옵션은 다음과 같습니다.

double distance = Math.sqrt(x*x + y*y);  //using static utility class

대 :

RootCalculator mySquareRooter = new SquareRootCalculator();
mySquareRooter.setValueToRoot(x*x + y*y);
double distance;
try{
   distance = mySquareRooter.getRoot();
}
catch InvalidParameterException ......yadda yadda yadda.      

자세한 방법을 사용하지 않더라도 다음과 같이 끝날 수 있습니다.

Mathemetician myMathD00d = new Mathemetician()
double distance = myMathD00d.sqrt(...);

in this instance, .sqrt() is still static, so what would the point be in creating the object in the first place?

The answer is, create utility classes when your other option would be to create some sort of artificial "Worker" class that has no or little use for instance variables.

---

This link http://java.dzone.com/articles/why-static-bad-and-how-avoid seems to go against most of the answers here. Even if it contains no member variables (i.e. no state), a static class can still be a bad idea because it cannot be mocked or extended (subclassed), so it is defeating some of the principles of OO

---

I wouldn't be concerned over a utility class containing static methods.

However, static members are essentially global data and should be avoided. They may be acceptable if they are used for caching results of the static methods and such, but if they are used as "real" data that may lead to all kinds of problems, such as hidden dependencies and difficulties to set up tests.

참고URL : https://stackoverflow.com/questions/1942903/is-it-bad-practice-for-a-class-to-have-only-static-fields-and-methods