스프링에서 유틸 클래스 작성시 질문입니다.

[쿠이]

스프링에서 유틸리티 클래스를 하나 작성하려는데 이게 맞는지 궁금합니다. 여러 방법이 있겠지만

public class StringUtil { 

    public static StringUtil stringUtil = new StringUtil();

    private static final Logger logger = Logger.getLogger(StringUtil.class);

    public static StringUtil getInstance() {

    return stringUtil;

    }

} 

이렇게 클래스를 작성 한 후 

<bean id="stringUtil" class="com.cooi.common.string.StringUtil" factory-method="getInstance" />

이런식으로 한다음에 @Autowired 해서 가져와서 사용하는데 이게 맞는지 궁금합니다.

스프링에서 유틸클래스를 만드는 방법이 궁금합니다.

질문 1. 스프링에서 유틸리티 클래스 작성 방법(위의 것이 틀리다면 어떤방향으로 수정을 해야 되는지)

질문 2. bean 정의시  factory-method 를 사용했는데 이것은 인스턴스 사용시 getInstance메소드를 통해서 호출 할때마다 매번 가져오는게 맞는지 궁금합니다.

[최용은]

그냥 static method 사용하면 되지 않나요?... 

유틸은 스프링컨테이너에서 관리하는 빈으로 만들고 싶으신건가요?-_-?

2013년 5월 21일 오후 2:50, 쿠이 <phka...@gmail.com>님의 말:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 ksug+uns...@googlegroups.com에 이메일을 보내세요.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
http://groups.google.com/group/ksug?hl=ko-KR에서 그룹을 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/groups/opt_out을(를) 방문하세요.
 
 

[쿠이]

넵. 스프링에서 관리하도록 만들려고 합니다 ㅜㅜ

스태틱으로 만들어서 class.getInstance().method 호출로 사용해도 되는데.

스프링 스럽게 하려하고 하다보니 이렇게 됐네요\.

[skplanet]

보통 특별한게 아니면

static 메소드 방식으로 하면될 것 같습니다.

2013. 5. 21., 오후 2:50, 쿠이 <phka...@gmail.com> 작성:

[skplanet]

관리 하도록 하려면 보통 스프링 클래스로 생성 해서 생성 하시고

@Autowired 으로 받아서 처리 하시면될듯합니다.

2013. 5. 21., 오후 2:58, skplanet <sbc...@gmail.com> 작성:

[최용은]

유틸은 스프링 스럽게 하는게 한다니;;;; 

제 주관으로 봤을때 그럴필요 없습니다. 낭비죠...-_-;

그냥 유틸은 static method를 하시는게....

2013년 5월 21일 오후 2:58, skplanet <sbc...@gmail.com>님의 말:

[Ki-Seok Kim]

@Component 어노테이션 지정하고 Autowired 로 사용하시면 될거같습니다.

싱글톤을 원치 않으시면 @Scope 어노테이션을 사용하시면 될거같구요

2013년 5월 21일 오후 2:55, 최용은 <choi...@gmail.com>님의 말:

[쿠이]

음..그렇군요~! 감사합니다~  좀 더 고민을 해보겠스ㅡㅂ니다!

[애너벨리]

스프링에서 관리하게끔 만들고 싶으시다는것은 다른말로 스프링 빈으로 만들겠다는 뜻이고,

 

또 다른말로 객체 생성과 소멸 권한을 IoC 컨테이너에 위임하겠다는 뜻입니다.

[최영목]

유틸 클래스은 그냥 static으로 하는 것을 권장합니다. 

그리고 유틸을 싱글톤 패턴으로 만들지 않으셔도 됩니다. ^^;; 그냥 private 생성자로 막으시는 것도 한 방법입니다.

마지막으로 비즈니스와 관계없는 유틸 클래스는 최대한 의존성이 없는 것이 좋습니다. .Logger를 제외하는 것도 하나의 방법입니다. 

ps. 망치(ex. 스프링)를 들면 모든 것이 못(ex. 스프링빈)으로 보이는 경우도 많습니다. ^^

2013년 5월 21일 오후 3:13, 애너벨리 <kwo...@gmail.com>님의 말:

스프링에서 관리하게끔 만들고 싶으시다는것은 다른말로 스프링 빈으로 만들겠다는 뜻이고,

 

또 다른말로 객체 생성과 소멸 권한을 IoC 컨테이너에 위임하겠다는 뜻입니다.

--

Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 ksug+uns...@googlegroups.com에 이메일을 보내세요.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
http://groups.google.com/group/ksug?hl=ko-KR에서 그룹을 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/groups/opt_out을(를) 방문하세요.
 
 

--

- 올바른 성장과 따뜻한 나눔

- 넥스트리소프트(주) 최영목

[박 민수]

예전에 비슷한 경험이 있는데

Spring bean이 아니면 @autowired 나 @value 같은 di는 사용 못합니다.

참고 하세용 ^^

나의 iPhone에서 보냄

2013. 5. 21. 오후 3:20 최영목 <davi...@nextree.co.kr> 작성:

[Ahn Jisung]

가끔 클라이언트의 사용방법은 모두 static 호출로 충분한데 내부동작을 위해  외부 빈을 DI를 받아서 처리해야 하는 경우들이 있습니다. 

예를 들어 

class PathUtil {

static String rootPath;

public static String path(Stirng subPath) {

return rootPath+"/"+subPath;

}

}

이런 경우 rootPath를 프로필에 따라 DI 받고 싶은 경우가 있지요

이런 경우에는 InitializingBean  을 상속받아 빈으로 등록하여 DI을 받은후에 afterPropertiesSet()에서 추가 작업을 해주시면 됩니다. 

class PathUtil implements IntializingBean {

@Value("project.rootPath")

String rootPathConfig;

static String rootPath;

@Override 

public void afterPropertiesSet() {

rootPath = rootPathConfig;

}

…

…

}

2013. 5. 21., 오후 2:50, 쿠이 <phka...@gmail.com> 작성:

[최영목]

말씀대로 인스턴스 변수에 데이터를 저장하는 것과 같이 상태를 가져야하는 유틸의 경우 static이 아닌 인스턴스를 생성해야할 경우도 존재합니다. ^^

(보통 저는 이런류의 유틸을 개인적으로 helper라고 사용하고 있습니다.)

이런 경우에라도 Bean을 만들어야 하나라는 생각이 듭니다. 그냥 new 해서 만들면 되거든요 ^^;;;

예를 들어주신 PathUtil의 경우에도 rootPath가 static이어야만 하는가라는 고민이 발생할 수 있습니다. 그냥 rootPath도 parameter로 받고, 프로필에 따라서 달라지는 rootPath의 경우 properties나 다른 방법으로 받을 수 있거든요. ^^;;; (PathUtil이 상태를 가져야하는가와 같은 클래스 설계의 고민과도 연관이 됩니다.)

제가 위에서 언급한 내용은 다음 내용에 해당하는 것입니다.

"

스프링에서 유틸클래스를 만드는 방법이 궁금합니다.

질문 1. 스프링에서 유틸리티 클래스 작성 방법(위의 것이 틀리다면 어떤방향으로 수정을 해야 되는지)

"

이곳에서 스프링에서 유틸리티 클래스를 만드는 방법은 처음 글 쓰신분처럼 빈으로도 만들수 있지만 순수 자바에서 하는 것처럼 복잡하지 않은 유틸의 경우 그냥 static으로 만드는 방법을 개인적으로 권장하기 때문입니다.

그리고 나아가 스프링에서 유틸리티 클래스를 만들때 왜 빈으로 만들어야 하는지, 그리고 스프링 빈으로 어떤 클래스를 관리해야하고, 어떤 클래스는 new로 해야하는지에 대한 고민도 함께되면 좋을 것 같아서 남긴 글인데 의도가 제대로 전달이 되었는지는 모르겠습니다. ㅠㅠ

2013년 5월 21일 오후 5:12, Ahn Jisung <nar...@gmail.com>님의 말:

[Ahn Jisung]

설계의 문제가 맞긴합니다. 

그런데  설계의 방향을 PathUtil.path("/abc") 라는 형태로 정적 메소드를 사용하게 하는 것으로  결정했다면 

rootPath는 정적 메소드가 접근할수 있는 정적 클래스 변수로 저장되어야 겠지요. 

물론 저런 방식을 저도 추천하지는 않습니다. 의존성이 필요하다면 빈으로 등록되고 해당 빈을 DI 받아 쓰는게 맞다고 봅니다만, 

프로젝트의 환경에 따라  저런 정적 메소드로 도배된  빈이 필요하기도 하거든요. ^^

어떤 경우이냐 하면 프로젝트의 많은 사람들이 DI라는 개념을 잘모르고, 배울 의지도 별로 없고, XML 설정이나 기타 설정을 하라고 하면 여기저기서 에러나요!! 라고 외치는 환경인거죠 ^^

그런 경우에는 정적 메소드기반의 클래스를  Fqcade 로 제공하고, 뒤에서 제대로된 메커니즘을 가지게 하는것도 방안중 하나라고 봅니다. 

2013. 5. 21., 오후 5:29, 최영목 <scr...@swtest.co.kr> 작성:

[최영목]

"

어떤 경우이냐 하면 프로젝트의 많은 사람들이 DI라는 개념을 잘모르고, 배울 의지도 별로 없고, XML 설정이나 기타 설정을 하라고 하면 여기저기서 에러나요!! 라고 외치는 환경인거죠 ^^

"

고충을 충분히 이해하며 공감합니다. ^^;;;;

2013년 5월 21일 오후 5:48, Ahn Jisung <nar...@gmail.com>님의 말: