[토비의 스프링 3.0] 1 장 오브젝트와 의존관계

 

1장 스프링은 오브젝트에 관심이 많다.

 

(그 관심은 객체지향설계 - 디자인패턴)

 

 

1.1 초난감 DAO

 

(p56)

작동만 하는 기본적인 DAO 코드를 1절에서 보여줍니다.

(사용자 정보를 jdbc api 를 통해 db 에 저장하고 조회할수 있는 DAO)

"p58 add/get 메소드에서 매번 커넥션하고 sql 담고, 리소스 반환하고 매번"

 

1.2 DAO 분리

2절에서는 기초적인 리펙토링을 하는데

공통으로 사용하는 부분을 하나의 메소드로 빼고

슈퍼클래스를 만들어 기본 로직(커넥션가져오기, sql 생성, 실행, 반환)을 만들고

그 기능의 일부를 추상 메소드나 오버라이딩 가능한(protected) 메소드등으로 만든 뒤

서브클래스에서 구현하도록 리펙토링을 보여줍니다.

 

(p62)

먼저 관심사의 분리

중복 코드의 메소드 추출/

 

상속을 통한 확장

= 두개의 패턴이 포함되어 있다. 템플릿 메소드 패턴, 팩토리 메소드 패턴

"(p68) 예제코드"

 

 

p72

그래도 문제가 있어서

상속 안좋아. UserDao 다른목적으로 상속못해, 상속은 상하위클래스 관계 너무 밀접해.

다른 DAO 만들면 다시 중복발생이야.

 

1.3 DAO 확장

 

p74

메서드분리->상하위클래스분리->완전히 독립적인 클래스로 분리.

 

아직.

"UserDao 에서 connection 구체적 정보를 알아야해"

 

인터페이스(추상적인 느슨한 연결고리)도입과 클라이언트의 도움을 얻는 방법

 

p76

인터페이스의 도입

해결책으로 두개의 클래스가 서로 긴밀하게 연결되어 있지 않도록 중간에 추상적인 느슨한 연결고리를 만들어 주자.

추상화란 어떤 것들의 공통적인 성격을 뽑아내어 이를 따로 분리해내는 작업.

자바가 추상화를 위해 제공하는 가장 유용한 도구는 바로 인터페이스.

(그 프로젝트에 bo, dao의 인터페이스는 뭔짓거리?)

 

p78

"아직아직 ㅠㅠ"

 

p79

관계설정 책임의 분리

UserDao 를 사용하는 클라이언트에게 사용할 ConnectionMaker 를 설정해달라고 책임을 전가한다.

(나 (개발자 A) 디자인/마크업담당자는(B) 로 해주세요.)

 

p83

책임을 클라이언트에게

(팀장님 담당 디자이너 지정해주세요) 

 

 

p85

객제지향 여러가지 이론 이야기

 

원칙과 패턴

개방폐쇄원칙(OCP Open-Closed Principle) : 클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀있어야 한다.

 

객체지향 설계 원칙(SOLID)

 

SRP(Single Responsibility Principle) : 단일 책임의 원칙 http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39135552,00.htm

OCP(Open-Closed Principle) : 개방-폐쇄 원칙 http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39134727,00.htm

ISP(Interface Segregation Principle) : 인터페이스 격리 원칙 http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39139151,00.htm

LSP(Liskov Substitution Principle) : 리스코프 교체 원칙 http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39137043,00.htm
DIP(Dependency Inversion Principle) : 의존 관계 역전 원칙 http://www.zdnet.co.kr/builder/dev/modeling/0,39031637,39137043,00.htm

 

높은 응집도와 낮은 결합도(high conherence and low coupling)

 

전략패턴(Strategy Pattern) 디자인 패턴의 꽃

UserDaoTest - UserDao - ConnectionMaker 구조

 

 

p90

1.4 제어의 역전 (IoC)

Inversion of Control

 

오브젝트 팩토리

팩토리란?(p90)

 

UserDaoTest 에서 제어부분을 분리

 

설계도로서의 팩토리(p92)

 

제어 흐름 구조가 뒤바뀌는 것

(아웃소싱?)

 

프레임워크?라이브러리?

1.5 스프링의 IoC

(p97)

스프링의 등장.

빈팩토리, 애플리케이션 컨텍스트

 

빈 - 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트

스프링 빈 - 스프링 컨테이너가 생성과 관계설정, 사용 등을 제어해주는 제어의 역전이 적용된 오브젝트.

빈팩토리 - 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트

애플리케이션 컨텍스트 - 애플리케이션 전반에 걸쳐 모든 구성요소의 제어 작업을 담당하는 IoC 엔진

 

 

(p98)

애노테이션을 이용한 설정.

 

 

애플리케이션 컨텍스의 장점(p102)

클라이언트는 구체적인 팩토리 클래스를 알 필요가 없다.

애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다.

애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제공한다.

 

 

1.6 싱글톤 레지스트리와 오브젝트 스코프

애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리(singleton registry) 이기도 하다.

 

스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공한다.

 

스프링 빈의 스코프(p113)

나중에 10장에서

 

 

1.7 의존관계 주입 (DI)

(새로운용어를 만드는데 탁월한 사람들이ㅎ)

Dependency Injection

IoC 컨테이너 => 의존관계 주입 컨테이너(DI 컨테이너)

 

 

생성자가 아닌

*메소드를 이용한 의존관계 주입*

 

 

1.8 XML을 이용한 설정

 

DataSource 인터페이스로 변환 (p138)

1.9 정리

 

 

궁금 스프링 이전에 웹서버 개발은 어떻게 했나?