[ Spring ] IOC 수업 정리 - (1)
본 글은 KOSTA에서 교육을 들으면서 배웠던 내용을 복습해보고자 블로그에 올리는 글입니다. 어느덧 교육을 수강한 지 3개월이 넘어가는데요.. 드디어 웹 개발의 꽃 스프링! 과정까지 오게 되었습니다. 스프링을 잘 배우고 파이널 프로젝트까지 잘 마무리하고 싶다는 생각이 가장 큽니다. 스프링에 대해서 아주 맛보기 정도로 학습을 하였지만 느낀 점은 앞서서 배웠던 JSP, Servlet과는 다르게 구조 자체가 굉장히 어색하고 개발자들이 굉장히 효율적인 방법을 추구하는구나라는 생각이 들었습니다. 개인적인 이야기는 나중에 하고 수업내용을 정리해보도록 하겠습니다.
1. 기존 제어방식
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
interface Tool {
public void work();
}
class Hammer implements Tool {
public void work() {
System.out.println("망치 도구로 일하다");
}
}
class Spade implements Tool{
public void work() {
System.out.println("삽 도구로 일하다");
}
}
public class TestUser {
public static void main(String[] args) {
// Tool tool = new Hammer();
Tool tool = new Spade();
tool.work();
}
}
|
사용자가 도구를 사용해야 한다고 가정해봅시다. 이때 사용할 수 있는 도구는 Hammer라고 가정해봅시다. Hammer는 Tool 인터페이스를 구현하였으므로 인터페이스형(Tool) 변수에 객체의 주소 값을 넣고 work() 함수를 호출하여 도구를 사용하였습니다. 하지만 더 좋은 도구의 출현(?)으로 Spade로 바꿔야 할 상황이 온 겁니다!! 그렇다면 new Hammer()를 지우고 new Spade()로 바꾸어주었습니다. 위의 상황에서는 코드의 변경이 불가피합니다.
위의 코드의 경우 인터페이스를 통한 다형성을 사용하였기 때문에 코드의 변경이 적은 편일 겁니다. 각각의 도구를 인터페이스를 구현하지 않고 독립적인 클래스로 구현하였고 메서드명까지 다르다면 코드의 변경은 변수의 타입 선언부터 변경해주어야 합니다. 즉 추상화 또는 계층 구조화 또는 캡슐화가 되어있지 않다면 메서드의 호출부와 선언부까지 변경을 해주어야 할 것입니다. 정리하면 위의 구조는 도구를 변경할 때 조금 더 전문적인 용어로 컴포넌트를 변경할 때 코드의 수정은 불가피합니다. 잘한 점이라고 하면 계층 구조화를 시켜서 메서드 또는 소통방식을 표준화시켰다는 점입니다.
2. IOC 방식 적용
- ioc.xml
|
1
2
3
4
5
6
7
|
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="tool" class="model.Spade"></bean>
</beans>
|
cs |
|
1
2
3
4
5
6
7
8
9
10
11
|
public class TestUser2_IOC {
public static void main(String[] args) {
// IOC 방식 적용
// factory 가 spring container 역활을 한다.
// 역활 : ioc.xml 파일을 읽어서 객체를 생성한다.
ClassPathXmlApplicationContext factory = new ClassPathXmlApplicationContext("ioc.xml");
Tool tool = (Tool)factory.getBean("tool");
tool.work();
factory.close();
}
}
|
1. 기존 제어 방식과의 차이점은 도구, 즉 컴포넌트를 바꾸기 위해서 코드의 수정은 필요 없다는 점입니다. xml 파일만 수정해주면 됩니다. xml 파일의 수정도 결국엔 똑같이 코드 수정이 아니냐?라고 할 수 있지만 main 메서드의 수정과 xml 파일의 수정은 다릅니다. main 메서드를 클라이언트 부분이라고 한다면 실제 사용되는 측의 클라이언트 코드 변경의 없이 도구를 바꿀 수 있다는 것입니다. 즉 xml 파일의 변경은 spring ioc 설정, 즉 xml 부분만 수정해주면 됩니다.
위의 코드를 간략하게 설명하겠습니다. ClassPathXmlApplicationContext("ioc.xml")를 이용해서 ioc.xml을 읽어 xml에 정의해놓은 객체를 생성 후 저장해놓고 해당 객체를 요청하면 IOC컨테이너가 객체를 반환합니다. spring ioc container의 특징으로는 객체를 생성 후 해당 객체를 요청하면 같은 객체를 반환한다는 점입니다. 즉 singleton 방식으로 운용합니다.
3. IOC 방식 특징
기존 방식을 다시 한번 언급하겠습니다. 앞의 경우에서 도구를 변경할 때, 즉 컴포넌트를 변경해야 할 경우 사용하는 측의 코드도 함께 변경해야 했습니다. 이 경우는 사용자 측과 도구 측과 결합도가 높은 상태라고 볼 수 있습니다. 반면에 ioc를 적용한 코드의 특징은 다음과 같습니다.
- 컴포넌트의 사용자측과 제공하는 측의 결합도가 낮다. 즉 느슨한 결합도
- 컴포넌트의 변경 시, 즉 도구의 변경 시 프로그램의 변경은 없다.
- 컴포넌트의 변경 시 스프링 ioc 설정 ( xml )만 변경해주면 된다.
'WEB > Spring' 카테고리의 다른 글
| [ Spring ] IOC 수업 정리 - (2) (0) | 2021.11.20 |
|---|
