[토비의 스프링] Chapter 1. 오브젝트와 의존관계
토비의 스프링을 SQ3R 방식을 도입해 읽는 시도를 하고 있습니다. 목차만 보고 궁금한 점들을 작성한 뒤, 책을 읽고 답변을 정리합니다.
❓ 관심사를 분리해야 하는 이유
👉 요구사항은 끊임없이 변경되고 발전한다. 모든 관심사들이 한 곳에 응집되어 있다면 해당 오브젝트는 끊임없이 변화해야 한다. 추가로 해당 오브젝트를 의존하고 있는 다른 오브젝트에까지 영향이 갈 수 있다. 이 변화의 폭을 최소화하기 위해서 관심사를 최대한 분리해야 한다.
➕ 오브젝트끼리 의존을 제거하면 되지 않을까요?
👉 불필요한 코드의 중복이 많아질 수 있다. 예를 들어 UserDao, BoardDao, CommentDao에서 DB 연동과 관련된 설정이 필요하다고 가정해보자. 모든 Dao에서 DB 연동 코드를 작성할 것인가? DB 연동 방법이 바뀌기라도 하면 모든 Dao를 수정해야하는 일이 발생한다.
❓ 스프링이 관심사 분리를 돕는 방법
👉 IoC와 DI를 활용할 수 있다. 이에 대한 설명은 아래 다른 질문들에서 하겠다.
❓ 인터페이스를 도입해야 하는 이유
👉 한 기능에 대해 구현 방법이 여러가지 존재할 때 매번 오브젝트를 수정하는 것은 번거로운 일이다. 이런 기능에 대한 변경이나 확장을 유연하게 하기 위해서는 크게 상속과 인터페이스 두 가지 방법이 있다. Java에서 상속은 다중 상속이 불가능하다, 슈퍼 클래스의 변경이 서브 클래스에게까지 미칠 수 있다 등의 제약이 있어 인터페이스가 좀 더 유연하게 사용하기 쉽다.
➕ 관련 글
❓ 관계 설정의 책임이 분리되면 무엇이 좋은가
👉 오브젝트에서 어떤 오브젝트와 의존을 맺을지에 대한 것도 하나의 관심사다. 관심사를 분리해야 하는 이유를 생각해보자.
❓ 개방 폐쇄의 원칙이란
👉 클래스나 모듈은 확장에 대해서는 열려 있고 변경에 대해서는 닫혀 있어야한다는 의미이다. 기능을 변경하거나 확장할 수 있으면서도 그 기능을 사용하는 코드에서는 수정되지 않는다. 예를 들면 UserDao에서는 ConnectMaker라는 인터페이스를 이용해 DB 연결과 관련된 로직을 수행하고 있다. ConnectMaker를 통해 DB 연결 방법은 언제든지 바뀔 수 있다. 하지만 ConnectMaker의 변경으로 인해 UserDao의 로직은 변경될 필요가 없다. 이 경우 개방 폐쇄의 원칙을 따른다고 표현할 수 있다.
❓ 전략 패턴이란
👉 인터페이스를 통해 로직을 외부에 분리시키고 이를 구현한 클래스를 필요에 따라 바꿔 사용할 수 있게 하는 디자인 패턴. ConnectMaker라는 인터페이스를 DB 종류에 따라 MySqlConnectMaker, H2SConnectMaker, MongoDbConnectMaker 등으로 구현체를 생성하고 이를 사용하는 UserDao에서는 필요한 구현체를 사용하면 된다.
❓ IoC란
= Inversion of Control = 제어의 역전
👉 자신이 사용할 오브젝트를 선택하는 책임을 다른 대상에게 위임하는 것이다.
➕ ex - 프레임워크: 라이브러리는 애플리케이션 코드가 능동적으로 필요할 때에 라이브러리의 기능을 사용한다. 반면 프레임워크는 애플리케이션 코드가 프레임워크에 의해 사용된다. 프레임워크가 짜놓은 틀에서 수동적으로 동작하는 것이다.
❓ 스프링의 IoC 동작 방식
- bean: 스프링이 직접 생성 및 제어하는 오브젝트
- bean factory: bean 생성 및 제어를 담당하는 스프링 IoC 핵심 컨테이너
- application context: bean factory를 확장한 IoC 컨테이너. 스프링의 부가 서비스를 추가로 제공
👉 bean과 application context를 이용해 IoC를 관리한다.
❓ 싱글톤 패턴의 한계
👉 싱글톤은 private 생성자를 가지기 때문에 상속이 불가능하고 테스트하기 힘들다. 클래스 로더를 어떻게 구성하느냐에 따라 하나 이상의 오브젝트가 만들어질 수 있어 싱글톤이 하나만 만들어진다 보장하기 힘들고, 전역 상태로 사용하기 위해 싱글톤을 적용하는 올바르지 못한 상황이 만들어질 수 있다.
❓ 싱글톤 레지스트리란
👉 싱글톤을 저장하고 관리하는 스프링의 기능이다. public 생성자를 갖기 때문에 테스트를 유연하게 작성할 수 있다. 싱글톤 패턴의 일부 단점이 완화되었다.
➕ 싱글톤 레지스트리를 적용하면 싱글톤 패턴의 단점이 완화되는가?
👉 적용하면서 일부 싱글톤 패턴의 단점이 완화되기는 했지만 싱글턴 패턴의 단점을 극복하기 위해 스프링이 등장한 것은 아니다. 빈을 직접 만들고 이를 싱글턴 레지스트리로 관리하기로 했을 뿐이다.
❓ 스프링 빈 스코프의 종류
- 싱글톤: default. 오브젝트 하나만 생성
- 프로토타입: 빈 요청할 때마다 오브젝트 새로 생성
- 요청: HTTP 요청 생길때마다 생성
- 세션: 웹의 세션과 유사한 스코프
❓ DI란
= Dependency Injection = 의존관계 주입
👉 A 오브젝트가 B 오브젝트에 의존한다. B 오브젝트가 변경되면 A 오브젝트에도 영향을 미친다는 의미이다. 의존관계는 코드 상에서 직접 드러날 수도 있지만 런타임 시에 생성되는 경우도 있다. 이런 런타임 시 의존관계를 맺는 대상(의존 오브젝트)와 이를 사용하는 주체(클라이언트)를 연결해주는 작업을 의존관계 주입이라고 한다.
참고 & 도움
- 토비의 스프링 / 이일민 / 에이콘 출판
- 토비님의 토프링 읽기 모임