토비스프링 1-1 정리( 개인저장용 )

객체지향의 설계 원칙(SOILD)

1. 단일 책임 원칙 (Single Responsiblity Principle)

2. 개방-폐쇄 원칙 (Open Closed Principle)

3. 리스코프 치환 원칙 (Liskov Substitution Principle)

4. 인터페이스 분리 원칙 (Interface Segregation Principle)

5. 의존 역전 원칙 (Dependency Inversion Principle) - 

 

빈

스프링에서는 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈이라고 부른다.

 

어플리케이션 컨텍스트

별도의 설정 정보를 참고하여 IoC를 적용하여 빈의 생성, 관계 설정 등의 제어한다.

 

 

싱글톤 레지스트리

- 스프링은 기본적으로 별다른 설정을 하지 않으면 내부에서 생성하는 Bean Object를 싱클톤으로 만든다.

(만약에 클라이언트에서 요청이 올때 마다 각 로직을 담당하는 오브젝트를 만들어서 사용한다면? => 서버의 부하가 생김)

- 스프링은 서버 환경에서 싱글톤으로 오브젝트를 사용하는것을 지지하지만 Java에서는 싱글톤으로 관리하기 어렵다.

- 스프링은 싱글톤 오브젝트를 관리하는 기능을 제공하는데 그것이 싱글톤 레지스트리

- 싱글톤 레지스트리는 private생성자 없이도 싱글톤을 가능하게 해준다.

 

 

 

코드개선 순서

- 먼저 책임(기능)이 다른 코드를 분리해서 두 개의 클래스로 만들었다(관심사 분리, 리팩토링)

- 바뀔 수 있는 클래스는 인터페이스로 구현했고 다른 클래스에서 인터페이스를 통해서만 접근하게 했다.

( 인터페이스를 정희한 쪽의 구현 방법이 달라져 클래스가 바뀌더라도 그 기능을 사용하는 클래스의 코드는 같이 수정할 필요가 없다 => 전략 패턴)

- 자신의 책임 자체가 변경되는 경우 외에 불필요한 변화가 발생하지 않도록 했고, 자신이 사용하는 외부 오브젝트의 기능은 자유롭게 확장 가능하게 했다 ( 개방 폐쇠의 원칙 )

- 결국 한쪽의 기능 변화가 있어도 다른 쪽의 변화는 요구하지 않게 했고( 낮은 결합도 ), 자신의 책임과, 기능에만 집중하는( 높은 응집도 ) 코드를 구현함

- 오브젝트가 생성되고 다른 오브젝트와 관계를 맺는 작업의 제어권을 별도의 오브젝트 팩토리를 만들어서 넘겼다.(제어의 역전Ioc)

- 설계 시점과 코드에는 클래스와 인터페이스 사이의 느스한 의존 관계만 만들어 놓고 런타임시에 실제 사용할 구체적인 의존 오브젝트를 제3자(DI컨테이너)의 도움으로 주입받아 다이내믹한 의존관계를 갖게 했다(의존관계주입DI)

- XML을 이용해 DI설정 정보를 생성