Spring 응용 프로그램의 유틸리티 클래스 - 정적 방법을 사용해야 합니까?

Spring 응용 프로그램의 유틸리티 클래스 - 정적 방법을 사용해야 합니까?

유틸리티 클래스 DateUtil(아래 참조)이 있다고 가정합니다.이 방법을 사용하기 위해 호출자 메서드는 DateUtils.getDateAsString(aDate)을 사용합니다.정적 수식어를 제거하고 DateUtils를 springbean으로 만든 후(DateUtilsBean 참조) 호출 수업에 주입하는 것이 좋을까요, 아니면 그냥 그대로 두는 것이 좋을까요?

정적을 사용할 때 볼 수 있는 한 가지 단점은 조롱과 관련된 문제입니다. 정적 방법으로 조롱하는 방법을 참조하십시오.

public class DateUtils {

    public static String getDateAsString(Date date) {       
        String retValue =  "" // do something here using date parameter
        return retValue;
    }
}

춘두 버전

@Component
public class DateUtilsBean {

    public String getDateAsString(Date date) {      
        String retValue =  "" // do something here using date parameter
        return retValue;
    }
}

난 그렇게 생각 안 해.DateUtils 클래스는 부작용이 없고 입력 매개 변수만 처리하는 순수 유틸리티 클래스처럼 들립니다.이러한 기능은 정적 방법으로 유지되는 것이 좋습니다.데이트 도우미 방법을 흉내내고 싶어할 가능성은 별로 없을 것 같습니다.

저는 션 패트릭 플로이드의 의견에 동의합니다.

이것이 제 기준입니다. 클래스의 메소드가 외부 종속성(데이터베이스, 파일 시스템, 사용자 구성, 다른 개체/빈 등) 없이 수신되는 매개 변수를 통해서만 작업을 수행하는 경우, 일반적으로 개인 생성자가 있는 최종 클래스에서 정적 메소드로 작업을 수행합니다.

그렇지 않으면, 저는 그것을 스프링 빈을 사용해서 구현할 것입니다.

그래서 당신이 제기하는 경우에는 이 기준에 따라 정적인 방법으로 수업을 작성하겠습니다.

안부 전해요.

Springbean으로 선언하는 것이 좋을 것입니다. 왜냐하면 Spring의 라이프 사이클은 Spring에 의해 관리되고, 결국 종속성을 주입하고, 객체를 풀링하고, 적절한 방법으로 테스트할 수 있기 때문입니다. 일반 객체로 사용하고 매개 변수로 전달할 수 있다고 말하지 말고, 하위 클래스에서 메서드를 재정의할 수 있습니다.기타.

간단히 말해서, 예, 대부분의 경우 더 나은 설계가 될 것입니다.그럼에도 불구하고 노출된 것처럼 단순한 경우에는 큰 차이가 없습니다.

이 댓글에 좋은 대답 봄 싱글톤 콩에 정적인 것을 아예 사용해야 하나요.

정적 변수에는 하나의 JVM에 하나의 인스턴스가 있습니다.스프링 컨텍스트마다 싱글톤이 존재합니다.응용 프로그램에 컨텍스트가 하나만 있는 경우 응용 프로그램은 동일한 작업을 수행합니다.

하지만 그것들을 함께 섞지 마세요.일부 오래된 프로젝트에서는 ApplicationContext를 통해 springbean을 사용하는 순수하지 않은 유틸리티 클래스를 볼 수 있습니다.그것을 위한 테스트 케이스를 작성하는 것은 매우 어렵습니다.

이곳의 대부분의 사람들은 정적인 방법으로 Util 수업을 하는 것을 지지하지만, 저는 Springbean 대신에 반대합니다.

1. 이유가 있는 종속성 주입입니다.이 도구는 상황에 따라 다른 구현으로 Spring Bean을 대체하는 도구입니다.가장 일반적인 것은 개발 및 테스트 컨텍스트 차이입니다.그러나 미래에는 새로운 환경(운영, 다른 데이터 전송 프로토콜, 다른 데이터베이스 구현 등)을 구축할 수도 있습니다.이 경우 Spring이 주입한 인터페이스 구현 빈은 삶을 훨씬 더 편하게 해줄 것입니다.

반대로 정적 방법으로 유틸리티 클래스를 사용하는 것은 Tight Coupling이라고 하는 잘 알려진 설계 문제이며 코드 취약성으로 이어집니다.

2. 정적 메서드가 있는 유틸리티 클래스가 있는 경우를 생각해 보십시오.새 기능이 요청되면 삽입된 종속성을 추가해야 합니다.갑자기 지금은 Util이 아니라 Util Bean입니다.따라서 원래 Util에 메소드를 추가하는 대신 메소드의 이름을 바꾸고 호출하는 모든 코드를 리팩터링해야 합니다.리팩터링은 저렴하죠?다른 응용프로그램에서 사용되는 라이브러리를 빌드할 때 해당 라이브러리를 제어할 수 없는 경우에는 그렇게 빠르지 않습니다.그리고 무슨 일이 있었게?오늘 당신의 코드가 내일 컴파일된 라이브러리 종속성이 아니라는 것을 어떻게 압니까?

좋아요, 우리는 열심히 일했고, util을 bean으로 개명했고, 모든 것이 좋습니다.하지만 우리는 새로운 기능 요청을 받았고, 다음으로 콩에서 방법을 제거해야 합니다.이제 이것은 의존성이 없으며 빈의 이름을 back util로 변경해야 합니다.

3. 개발자가 Spring을 사용하는 경우 MVC 아키텍처 설계를 따르는 경우가 많습니다.이 경우 Util 클래스는 어디에 있습니까?서비스처럼 들리지만 다른 것으로 보이며 별도의 패키지가 있을 가능성이 높습니다.별로 좋지 않습니다.

결론 => 스프링과 함께 콩을 사용하고 정적인 방법으로 유틸리티 클래스를 어지럽히지 않습니다.저는 의존성 주입이 사용되는 모든 응용 프로그램에서 고려하는 것이 유효하다고 말하고 싶습니다.

언급URL : https://stackoverflow.com/questions/7270681/utility-class-in-spring-application-should-i-use-static-methods-or-not