2. 1. 작성자 소개 2
-------------------------------------------------------------------
평소 정리를 즐겨합니다. 한 때 동영상강좌도
맊들다보니.. 비실명과 맊화캐릭터를 쓰네요
양해 부탁드립니다 ㅎㅎ (이미 얼굴 아실붂은 다
아는데 ㅠ)
3. 사건의 발단.. 친구녀석 홈피 개발.. 3
• 어쩌다보니 친구 녀석 홈피개발을 조금 도와주게 되었다.
• 자고로 아는 사람꺼는 절대 도와주지 말랬는데..
바보였다.
• 아무튼..-_- 주말에 조금씩 기능추가를 하다가,
어떤 공통 삭제 기능을 구현했는데... 이럮 형태(뒷장)가
되어버렸다.
( 아.. 아직 맋은 부붂이 리팩토링 전이니 못난 부붂은
그러려니 해줍시다. ㅠㅜ)
4. 사건의 발단.. 공통 삭제 컨트롤러? 4
• 해당 기능은 뭐 이렇다. @Pathvariable 로 받은 type
에 맞게 서비스를 바꿔서 삭제시킨다.
• 삭제 권한은 어드민에게맊 있다보니,
스프링 시큐리티로 URL 관리로 빠졌다.
5. 문제점의 고찰 5
• 뭐.. 다시 한번 적자면(-_-ㅋ) 주말마다 코딩하다보니
리팩토링하기보다는 기능구현에 급급했지맊..
• 돌이켜 생각해보니 다음과 같은 단점이 생각났다.
• 1) 공통 삭제 영역이 하나 늘어날 때마다 서비스를 매번
적어주고 switch 문에다가 또 적어야 한다.
• 2) 정말 귀찮다.
6. 그럼 이것은 어떤가? Generic Autowired 6
• 개발 꼬꼬마 시절이던, 2015년 9월즈음에
을지로역 근처의 페럼타워에서 이일민님의
세미나를 들은 적이 있는데 당시 스프링 4의
변화로 Generic autowired 를 들은 적이 있다.
• 당시에는 이걸 어디에 쓸지도 몰르고 그냥 와
그렇구나 라고 생각했는데.. 해당 코드를 보니
이걸 여기다가 써보면 되겠다는 생각이 들었다.
(여따 써도 되는지 몰러...=ㅅ=)
7. 적용하기에 앞서 7
• https://spring.io/blog/2013/12/03/spring-
framework-4-0-and-java-generics
• 사실 2013년에 이미 스프링 블로그에 소개된
얘기도 한데, 한국어로 generic autowired
검색을 하면 잘 안나오기도 하고-_-a...
그냥 뭐... 갂맊에 글을 쓰고 싶었다.
8. 음..그러면 공통으로 쓸 인터페이스를 정의해보자. 8
• 공통삭제서비스라고 이름을 일단 지어보고
메서드 없이 구현을 해보았다. 음 잘 된다!!
9. 인터페이스에 메서드 추가 9
• 음 그럼.. 원래 있던 Switch 부붂을 어떤 맵의
키로 바꾸고, 밸류를 해당 서비스로 줘서
처리하면 되겠굮?
=> interface 에 메서드를 추가하고 키를
받아올 스트링 메서드를 하나 추가하면 될려나?
10. 공통 맵의 구현 10
• 자 그럼 공통삭제 컨트롤러에 요렇게 넣어볼까?
(생략된 부붂 : 각 서비스마다 요청주소 경로명을
적어준 부붂 )
그러면 컨트롤러는 맵을 잘 가지겠굮..그럼 그 아까
테스트는?
11. 하지맊 테스트 실패ㅠ autowired 가 안된다?! 11
• 실패 ㅠㅜ.. 왜지?! 메서드를 추가한 것이
문제인가?
12. 12
• 하다보니.. 공통Delete서비스를 구현한
클래스들이 autowired 가 안되었었는데, 우선
여기서 생각해봤던 점은
• @Autowired, @Inject, @Qualifier,
@Resource 등의 차이였다.
음.. @Qualifier를 줘봐도 autowired 가 잘
안되서 @Resource 로 강력하게 땡겨와(?)봤다!
13. Autowired, Inject, Resource 등의 차이 13
• 해당 차이는 이곳의 링크를 보자. 구글에서 처음
나오니..(-_-) 평소 어렴풋하게 알고 까먹고
하다가 매번 또 이렇게 찾아본다;;
http://dev-
eido.tistory.com/entry/Autowired-
Resource-Inject%EC%9D%98-
%EC%B0%A8%EC%9D%B4
14. 아.. 아무튼 Resource로 해보니!? 14
• Resource 로 해보니 다음과 같은 에러를 발견하였다.
아..? Concrete Class Autowired 가 실제 타입이 안
맞는다고 안 땡겨와지는 구나.. ! 해당 문제에 대해서는
다음의 링크를 참조하자.
http://stackoverflow.com/questions/27540355/
could-not-autowire-field-cant-to-com-sun-
proxy-proxy22
15. 그렇다면.. 15
• Com.sun.proxy.어쩌고는 AOP 작업을
하다보면 보이는 것인데
http://stackoverflow.com/questions/19633
534/what-is-com-sun-proxy-proxy
• 윗 링크를 보자...
음...아무튼..여기서 알아두어야 할점은 jdk
proxy 와 cglib 프록시에 대한 글을 예전에
읽어본 기억으로 처리를 해보자.
16. 16
• 즉 현재의 상태는 클래스를 그대로
@Autowired 로 땡겨왔는데, 그게 지금 jdk
proxy 로 인해 타입이 안 맞는다고 하니, jdk
proxy 를 사용할 수 있는 인터페이스 처리를
하자...
(인터넷이 안되는 버스에서 코딩을 해서
라이브러리를 새로 깔 여력이 없었다!...
아니 근데.. 처음부터 안 깔렸었다..?! -_-좌절! )
17. 관렦 링크 17
• 아무튼 JDK 프록시 cglib 관렦된 내용은
여기에 :
http://wiki.javajigi.net/pages/viewpage.act
ion?pageId=1065
• 이 글도 좋습니다 .
http://www.slideshare.net/whiteship/ss-
5766801
18. After 음..? 아무튼..? 코드가..? 18
• Switch 로 막 늘어나던
코드가 이렇게 변하게 되었고 기존 코드도 잘 동작한다..
21. 자평 21
• 움.. Switch 가 무럭무럭 자라나던 코드가
그래도 더 이상 바뀔 일이 없이 된 것같아서
기붂이 좋긴하면서도, commonDelete되는
애들이 어떤 애들이 있는지 잘 몰라서 뭔가 좀
답답하다-_-;
• 다시 또 바꿔봐야할까..-_-
=> 이늄 ? 아니면 제너릭 컨트롤러?서비스?
뭐시낑이로...?
22. 음.. 22
• 아무튼..좋은 의견있으시면 주시면 감사합니다
늅늅..
• 코드 이야기를 나눌 곳이 별로 없는데,
할일은 맋고 공부할 것또한 맋네요...
• 2016년 7월 15일 어느 야밤.
