50~
너무많아서 읽기가 겁나지만... 해야된다 으어어어어!!!
User c/User Dao
중복된 코드를 뽑아서 분리 -> 리팩토링 메소드 추출
UserDao 를 추상화시켜서 상속받는 2개의 클래스를만든다.
왜냐하면 서로 다른 디비설정이있을때 수정이 편하기때문
책에선 템플릿 메소드 패턴 이라고 정의
-슈퍼클래스를 만들고 서브클래스에 메소드를 필요에 맞게 구현해서 사용
여기서 getConnection은 팩토리 메소드 패턴이라 부르기도 한다.
서브클래스에서 구체적인 오브젝트 생성 방법을 결정하게 되는것.
인터페이스인 UserDao(사용설명서라는 개념으로 접근?)는
그저 어떤 기능을 사용한다는 데에만 관심있고 서브클래스에서는 어떤식으로 Connection 기능을 제공하는 지에만 관심을 둔다.
여기서 주요한게 상속을 통해 기능을 구현한 것인대. 서로의 결합이 너무 강해져서 다양한
문제가 발생 할 수 있다. UserDao가 변경을 제한되고 그밑에 상속되는 서브클래스가 많아지면 ..???
getConnection이 중복이 너무많아짐.
DAO 확장
추상클래스를 만들고 이를 상속한 서브클래스에서 변화가 필요한 부분을 바꿔서
쓸수 있게 만든 이유는 변화의 성격이 다른 것을 분리해서
서로 영향을 주지 않은 채로 각각 필요한 시점에 독립적으로 변경 하기 위해 .
하지만 상속이라는 방법때문에 약간 불편함.
클래스의 분리
DB 생성 기능을 SimpleConnectionMaker에 넣는다.
클래스분리하면서 또다른 문제점이 생겼다.
- 상속을 사용 했을 대 처럼 UserDao 코드의 수정 없이 DB 커넥션 생성기능 변경 X
- makeNewConnection() 을 사용하는대 만약 다른 메소드를 사용하면? add,get 다변경해줘야됨.
- DB커넥션을 제공하는 클래스가 어떤것인지 구체적으로 알고 있어야됨.
왜냐하면 DB커넥션을 가져오는 클래스에 대해 너무 많이 알고 있기 때문에...
--------해결책
인터페이스의 도입
추상화란? 두 개의 클래스가 서로 긴밀하게 연결되어 있지 않도록 중간에 느슨한 연결고리를 만들어준다.
인터페이스는 어떤 일을 하겠다는 기능만 정의해놓은 것이다.
그런데 여기서 생성자를 생성할때 DConeectionMaker() 때문에 생성자 메소드를 직접 수정하지 않고는 자유로운 DB커넥션을 제공 못함..
이유는? 어떤 ConnectionMaker 구현 클래스를 사용할지 결정해야되서..
---- 관계설정 책임의 분리.
UserDaod의 클라이언트라고 하면 UserDao를 사용하는 오브젝트를 가리키는데..
이 오브젝트가 UserDao와 ConnectionMaker 구현 클래스 의 관계를 분리해두기 적절하기때문
요약이 안돼서 사진으로..
이때 여기서 외부에서 가져오기위해 생성자 파라미터 를 이용한다 .
다시 정리해서
관심을 분리하기 위해 클라이언트에게 관심을 넘기자.
개방 폐쇄 원칙
클래스나 모듈은 확장에는 열려 있어야 되고 변경에는 닫혀 있어야한다.
-> 높은 응집도와 낮은 결합도
응집도가 높다? 하나의 모듈 클래스가 하나의 책임 또는 관심사에 집중
응집도가 높으면 변화가 일어날때 모듈에서 변하는 부분이 큼.
ex) ConnectionMaker 인터페이스를 만들면 새로운 구현 클래스만 만들면됨.
무엇을 변경할지가 명확하고 , 다른 클래스의 수정 요구및 기능에 영향을 주지않음.
낮은 결합도
느슨한 열결 관계. 나머지는 서로 독립적..
'하나의 오브젝트가 변경이 일어날 때에 관계를 맺고 있는 다른 오브젝트에게 변화를 요구하는 정도'
전략패턴
이제까지 구현한 코드는 전략패턴에 해당됨.
제어의 역전 (IOC Inversion of Control)
-> 오브젝트 팩토리
UserDaoTest는 UserDao가 잘동작하는지 테스트만 해야되는데? ConnectionmMaker 구현 클래스 결정 책임도 맡게됨.
팩토리
분리시킬 담당클래스 만들기.
객체의 생성 방법을 결정하고 그렇게 만들어진 오브젝트 리턴 을 팩토리라고 한다.
사용이유 : 오브젝트를 생성하는쪽 -> 생성된 오브젝트를 사용하는쪽의 역할과 책임을 분리하기 위한 목적
설계도로서의 팩토리
UserDao , ConnectionMaker 로직 기술담당
DaoFactory 오브젝트 구성 및 관계정의 ( 설계도 )
오브젝트 팩토리의 활용
제어권의 이전을 통한 제어관계 역전
제어의 역전은 간단히 프로그램의 제어 흐름 구조가 뒤바뀌는 것
오브젝트가 자신의 사용할 오브젝트를 스스로 선택하거나 생성하지도않는다. 제어 권한은 다른 대상에게 위임하기 때문..?
제어의 역전 ex) 템플릿 메서드 패턴 (상속/서브클래스)
템플릿메소드는 제어의 역전이라는 개념을 활용해 문제해결하는 디자인패턴.. 어렵군..
스프링의 IOC
오브젝트 팩토리를 이용한 스프링 Ioc
애플리케이션 컨텍스트와 설정정보
빈 ? 스프링에서 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트
오브젝트 단위의 에플리케이션 컨포넌트(구성)
빈 생성과 관계설정같은 제어 담당을 Ioc 오브젝트 빈 팩토리 / 확장한 개념 애플리케이션 컨텍스트
DaoFactiory를 사용하는 애플리케이션 컨텍스트
@Configuration 오브젝트 설정을 담당하는 클래스입니다!
@Bean 오브젝트를 만들어줌
XML 과 같은 스프링 전용 설정.
DaoFactor를 사용하는 애플리케이션 컨텍스트를 만들어야된다.
ApplicationContext 타입의 오브젝트를 선언하고
new AnnotaionConfigApplicationContext
(@configuration자바코드를 설정정보로 사용하기위해)
@Bean 이름은 메소드 명임 그결과를 가져온다.
애플리케이션 컨텍스트의 동작방식
오브젝트 팩토리 < - > 스프링 애플리케이션 컨텍스트 (IOC 컨테이너 , 스프링 컨테이너,빈팩토리)
ApplicationContext 는 BeanFactory 인터페이스를 상속함
애플리케이션 컨텍스트는 애플리케이션에서 Ioc를 적용하고 관리할 모든 오브젝트에 대한 생성과 관계설정을 담당함.
생성정보와 연관관계 정보를 주로 별도의 설정정보를 통해 얻는다.
@Configuraion이 붙은 클래스는 애플리케이션 컨텍스트가 활용하는 Ioc 설정정보
DaoFactory를 오브젝트 팩토리로 직접 사용했을 때와 비교해서 애플케이션 컨텍스트를 사용
했을 대 얻을수 있는장점?
클라이언트는 구체적인 팩토리 클래스를 알필요없음
애플리케이션 컨텍스트를 사용하면 오브젝트 팩토리가 많아져도 이를 알아야하거나
직접 사용할 필요 없다.
애플리케이션 컨텍스트는 종합 Ioc 서비스를 제공해 준다
오브젝트가 만들어지는 방식 시점 전략을 다르게 가져가거나 , 자동생성 , 후처리 정보좝,,,
다양한 기능을 제공 , 또한 빈이 사용하는 기반기술 서비스나 외부 시스템과의 연동을
컨테이너 차원에서 제공
애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법 제공
빈의 이름으로 빈을 찾거나 타입만을 ㅗ빈을 검색 . 특별한 애노테이션이 설정된 빈도 찾음
스프링 Ioc의 용어 정리
개념은 중요하다 생각해서
싱글톤 레지스트리와 오브젝트 스코프
싱글톤 레지스트리로서의 애플리케이션컨텍스트
애플리케이션 컨텍스트는 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이기도 함
스프링은 기본적으로 별다른 설정 안하면 내부 생성빈 오브젝트를 모두 싱글톤으로 만듬
서버 애플리케이션과 싱글톤
스프링이 싱글톤 빈을 만드는이유? 자바 엔터프라이즈 기술을 사용하는 서버환경이기때문
스프링은 대부분 서버환경에서 사용된다.
애플리케이션 안에 제한된 수 대개 한 개의 오브젝트만 만들어서 사용하는 싱글톤 패턴의 원리임
문제점 .
private 생성자이기 때문에 상속할 수 없다.
객체지향적 설계 장점 적용이 어렵다.
테스트 하기 힘들다
서버환경에서는 싱글톤 하나만 만들어 지는것을 보장하지 못함
여러 개의 JVM에 분산돼 설치가 되는 경우 각각 독립적으로 오브젝트가 생김
싱글톤의 사용은 전역 상태를 만들 수 있기 때문에 바람직하지 못함
싱글톤 레지스트리
싱글톤의 단점 대문에 스플링은 직접 싱글톤 형태의 오브젝트를 만들고 관리기능 제공
그것이 싱글톤 레지스트리. 평범한 자바클래스를 싱글톤으로 활용해줌 (프라이빗이아닌)
싱글톤과 오브젝트의 상태
싱글톤은 멀티스레드환경이면 여러 스레드가 동시에 접근해서 사용할수있어 관리에 주의를 요함
그래서 상태정보를 내부에 갖지않는 무상태 방식으로 만듬, 여러 요청에의해 값이 읽고지워지고해서
단순히 읽기전용 정보는 싱글톤에서 인스턴스 변수로 사용해도 된다.
스프링 빈의 스코프
빈이 생성되고 존재하고 적용 범위 - 빈의 스코프 대부분의 빈은 싱글톤 스코프를 갖는다.
의존관계주입
제어의역전(IOC) 과 의존관계주입
스프링 IOC를 좀더 명확하게 표현하기위해 DI 컨테이너라고도 한다.
런타임 의존관계 설정
의존관계
