스프링 스터디 1일차 오브젝트와 의존관계 발표자 - 강한규

1. 오브젝트와 의존관계
객체지향 프로그래밍을 한다는 것은?

2. 스프링이란?
• 자바언어를 사용하는 애플리케이션 프레임워크
• 스프링 컨테이너 또는 애플리케이션 컨텍스트라는 스프링 런타임 엔진
을 제공
• IoC/DI 를 프레임워크를 기본으로 사용
• 객체지향 설계원칙과 디자인 패턴의 원리가 녹아 있음
• 개발에 바로 사용할 수 있는 다양한 기술 API들을 제공
• 개발자는 조립하듯이 개발할 수 있음

3. 스프링의 장점
• 단순함
• 단순한 객체지향 개발모델인 POJO를 지원한다
• 객체간의 관계를 간단한 JAVA Class로 표현할 수 있다
• 유연성
• 프레임워크 근간을 유지하면서 확장해서 사용가능
• Network : netty, mina
• DB : hibernate, mybatis
• 범용적 확장성
• 전자정부프레임워크, SDS, CNS, C&C, 금융권 등 다양한 분야에서 스프링을
커스터마이징 해서 사용 중

4. 스프링에서 자바의 사용
• 객체지향 프로그래밍 도구로서의 자바
• 오브젝트의 생성, 관계, 사용, 소멸의 과정을 코드로 기술
• 오브젝트의 설계
• 다양한 목적을 위해 재사용 가능한 디자인 패턴
• 지속적으로 구조를 개선하는 리팩토링
• 위의 설계를 검증하는 단위 테스트

5. 관심사의 분리
• 추상화 수준에서 다양한 객체에 대해 모델링 했을 때 분리와 확
장을 고려해서 설계하는 것
• 관심이 같은 것끼리는 하나의 객체관점으로 공통 분모를 만든
다
• 관심이 다른 것은 서로 떨어지게 해서 영향을 주지 않도록 하는
것

6. 디자인 패턴
• 문제 해결에 사용되는 재사용성을 가진 솔루션
• 템플릿 메소드 패턴
• 팩토리 메소드 패턴
• 전략 패턴
• 싱글턴 패턴

7. 관심사의 분리(추상 메소드의 사용)
• 템플릿 메소드 패턴
• 슈퍼클래스에 기본적인 로직의 흐름을 만들고 템플릿화 사용
• 팩토리 메소드 패턴
• 서브클래스에서 override와 같은 방법으로 객체의 생성을 결정하는 것
• 단점
• 다중상속이 불가능하므로 목적이나 관심사가 추가되었을 때 반영에 애
로사항이 생김
• 상속관계로 인한 객체간 종속성이 있음 ( new를 한다는 것 )

8. 관심사의 분리 예제

9. 관심사의 분리(독립적인 클래스의 사용)
• Super Class 안에 Sub Class를 가짐
• Has 상속관계
• 단점
• 확장이나 재사용을 고려하지 않은 관계에서는 두 클래스간에 종속성이 생기기 때문
에 가져와 사용하는 관점에서 기존 코드에 종속되어 변경이 어렵다
• 해결방법
• 중간에 추상속성만 가진 인터페이스를 통해 느슨한 연결을 만든다
• 또다시 문제
• 인터페이스를 통해 클래스에 접근이 가능하지만 new로 생성하면서 아직 분리가 완
벽히 되지 않음

10. 관심사의 분리 예제

11. 클라이언트 Class 생성
• 인터페이스의 사용
• 두 클래스간 관심을 분리(생성/구현)
• Super Class의 생성자에는 인터페이스를 주입해서 느슨한 의존성 생성
• 클라이언트 Class의 사용
• Super Class의 내용을 변경하지 않고 클라이언트 클래스에 Sub Class
를 생성
• Super Class와 분리 시킴으로 관계 설정의 관심사를 분산 시킴
• Super와 Sub 클래스간 느슨한 의존관계를 생성
• 구현부의 독립성 확보

12. 전략 패턴
• Client Class – Super Class – Interface – Sub Class

13. 인터페이스를 사용할 줄 안다는 것
• 높은 응집도
• 변화가 일어날 때 모듈 or 클래스에서 공통적으로 변하는 부분이 많다
는 것
• 관심사를 하나로 집중해서 묶어 둔 것
• 낮은 결합도
• 객체간 관계가 간접적으로 연결되어 서로 독립적으로 구분되거나 구현
부분에 대한 종속 없이 껍데기만 가지고 있는 것
• DI를 통해 낮은 결합도로 결합

14. 객체지향의 설계 원칙
• 개방 폐쇄 원칙
• (폐쇄) 운전자 Class  자동차 Interface (확장/개방)
운전자
창문개방()
기어조작()
자동차
창문개방()
기어자동조작()
소나타
창문개방()
기어수동조작()
마티즈

15. 객체지향의 설계 원칙
• 단일 책임 원칙
여자친구
기념일챙기기()
키스하기()
효도하기()
아부하기
남자
아부하기()
사원
어머니
기념일챙기기()
키스하기()
남자친구
효도하기()
아들
직장상사
여자친구
어머니
직장상사

16. 객체지향의 설계 원칙
• 리스코프 치환 원칙
• 서브 타입은 기반타입(base)으로 교체할 수 있어야 한다
먹다()
싸다()
사람
먹다()
앉아싸다()
여자
먹다()
서서싸다()
남자

17. 객체지향의 설계 원칙
• 인터페이스 분리 원칙
• 클라이언트는 자신이 사용하지 않는 매서드와 의존 관계를 안
맺는다
기념일챙기기()
키스하기()
효도하기()
아부하기
남자
아부하기()
사원
어머니
기념일챙기기()
키스하기()
남자친구
효도하기()
아들
여자친구
직장상사

18. 객체지향의 설계 원칙
• 의존 역전 원칙
• 변하기 어려운 것에 대해 의존하라
스노우타이어
<interface>
타이어
일반타이어 광폭타이어
자동차

19. 오브젝트 팩토리
• 객체를 생성하고 생성된 객체를 반환하는 역할을 하는 클래스

20. 설계도의 팩토리

21. 제어권 이전을 통한 관계 설정
• 절차적(능동적) 관계 VS 수동적 관계
• 능동적인 생성과 사용 VS 객체의 생성과 사용에 대해 알 수 없음
• 라이브러리 VS 프레임워크
• API 함수 사용 VS 컴포넌트의 생성과 관계설정, 생명주기를 관장하는
Manager 존재 필요

22. 스프링의 IoC
• 빈(제어권을 가진 오브젝트)
• 빈 팩토리(빈의 생성과 관계설정)
• 애플리케이션 컨텍스트(설정정보를 가지고 있는 IoC 엔진(유일
한 능동적 객체))
• @Configuration 사용(설정정보라는 표시)
• @Bean 사용(오프젝트 생성을 담당하는 IoC 메소드라는 표시)

23. 애플리케이션 컨텍스트의 동작 방식

24. 애플리케이션 컨텍스트와 싱글톤
• 동일성 VS 동등성
• 동일한 인스턴스인가?
• 싱글톤인 이유
• 서버환경에서 쓰이면서 멀티쓰레드로 자원을 사용하므로 리소스를 무
턱대고 사용할 수 없다
• 하나의 오브젝트를 공유해서 동시에 사용 즉, 내부적으로 서블릿과 같
은 멀티쓰레드를 지원하고 공유자원에 대해 접근제어도 지원해 준다고
보인다

25. 싱글톤의 단점
• 여러 쓰레드가 동시에 접근하는 방식으로 사용되면 상태값 변
화에 대해 취약점을 가진다
• 되도록 리소스는 지역변수로 사용하고 함수 파라미터와 리턴값
으로 주고받는 형식으로 사용한다
• 읽기 전용 값에 대해서는 인스턴스 변수로 사용하거나 상수나
정적변수로 사용해도 된다

26. 스프링의 DI
• 의존 관계
• A -----> B
• A가 B에 의존한다 즉, B가 변하면 A에 영향을 끼친다
• 스프링의 IoC 컨테이너는 동작방식은 인터페이스를 통해 인스
턴스를 생성하는 다이나믹한 방법이지만 의존관계를 미리 설정
함으로 의존관계를 주입한다고 할 수 있다
• 인터페이스가 변하면 그 구현체나 의존성이 주입된 객체에 영
향을 미치나 인터페이스를 사이에 둔 두 객체간 결합도는 낮다

27. 의존 관계 주입의 핵심
• 클래스 모델이나 코드에서 런타임 시점에는 의존관계가 주입되
지 않음(다이나믹 속성)
• 런타임 시점의 의존관계는 컨테이너나 팩토리 같은 제 3의 존재
가 결정
• 의존관계는 사용할 오브젝트에 대한 인터페이스를 주입 해줌으
로 만들어짐

28. 의존관계 검색과 IoC/DI 컨테이너의 응용