[디자인 패턴의 아름다움] ch 7.1 ~ ch 7.4

정리

구조 디자인 패턴 : 특정 응용 프로그램 시나리오의 문제를 해결하는 데 사용되는 클래스나 객체의 고전적인 구조

 

1. 프록시 패턴 : 원본 클래스에 연관 없는 기능을 추가할 때 사용

2. 데커레이터 패턴 : 원본 클래스와 관련이 있거나 향상된 기능을 추가할 때 사용

3. 어댑터 패턴 : 코드 호환성 문제를 해결하는 데 사용

4. 브리지 패턴 : 합성의 폭발 문제를 해결하는 데 사용

5. 퍼사드 패턴 : 인터페이스 설계에 사용

6. 복합체 패턴 : 트리 구조로 나타낼 수 있는 데이터에 사용

7. 플라이웨이트 패턴 : 재사용 문제를 해결

 

 

찾아본 내용

 

클래스 로더 (p. 318)

 

1. 클래스 하나당 클래스 로더는 하나인가?

 

2. Spring 애플리케이션당 클래스 로더는 몇 개인가?

 

기본적인 경우 (Spring Boot 앱 하나)

• JVM에 로딩된 클래스 로더 구조는 다음과 같다
• 이 경우 대부분의 애플리케이션 클래스들은 App ClassLoader 하나를 공유한다

Bootstrap ClassLoader (JDK 기본 클래스)
  └── Extension ClassLoader (JDK 확장 라이브러리)
       └── App ClassLoader (애플리케이션 클래스 로딩)
              └── [Spring 애플리케이션]

 

예외적 상황 : 클래스 로더가 여러 개인 경우

 

1) Spring DevTools 사용 시 : 클래스 로더 최소 2개 이상 존재

• DevTools는 핫 리로드를 위해 별도의 RestartClassLoader 를 사용한다
• 이 경우 기본 라이브러리는 Base ClassLoader 가, 애플리케이션 코드는 RestartClassLoader 가 로딩한다

2) 웹 컨테이너(WAR) 환경 : 각 WAR 당 클래스 로더 1개 + 공통 ClassLoader

• WAS (Tomcat, Jetty 등)는 각 WAR 파일마다 클래스 로더를 분리한다
• WAR 끼리는 클래스 공유 불가 (ServletContext ClassLoader)

3) 모듈 시스템, OSGI, 플러그인 시스템 : 클래스 로더 수 = 모듈 수

• 각 모듈/플러그인마다 자체 ClassLoader 사용
• 의도적으로 격리하거나, 특정 범위만 공유

 

 

Java의 SPI

https://www.baeldung.com/java-spi

 

스프링 DI 와의 공통점

 

스프링 DI 와의 차이점

 

 

 

 

생각해보기

7.1 절에서 프록시 패턴을 통해 인터페이스에 캐싱을 추가할 수 있다고 이미 언급한 바있다. 이번 절에서는 데커레이터 패턴을 통해 inputstream 클래스에 캐시된 읽기 데이터 기능을 추가했다. 그렇다면 캐시를 추가해야 하는 경우 프록시 패턴과 데커레이터 패턴 중 어떤 것을 선택해야 할지 생각해보자

 

두 패턴의 공통점

• 기존 기능에 어떤 부가기능을 추가하는 역할
• 인터페이스 기반으로 동작하며, 원래 객체와 동일한 API를 제공
• 기능을 가로채서 덧붙이는 구조

 

구조 및 의도의 차이

 

캐시와 관련된 선택 기준

1. 프록시 패턴 : 객체 접근의 제어에 중점

• 객체의 접근 제어가 중요한 경우
  
  • 원격 객체, 비용이 큰 객체를 매번 생성하지 않고 접근을 지연 (lazy-loading)
• 객체의 생성/사용 시점이 중요할 때 (예: 로깅, 권한 검증, 트랜잭션 등)
• 객체 외부에서의 인터페이스 주도 제어를 할 때
• 캐시가 읽기 전에 접근 권한을 확인하거나 이미 처리된 결과를 리턴하는 수준에서 사용될 때

 

2. 데코레이터 패턴 : 데이터 처리의 기능 확장에 중점

• 데이터 흐름 중간에서의 기능 조합이 중요한 경우
  • 스트림 필터링, 변환, 압축, 버퍼링 등
• 여러 기능을 조합해서 붙이고 싶을 때 (캐싱 + 압축 + 암호화 등)
• 여러 개의 데코레이터가 함께 작동할 수 있어야 할 때
• 캐시가 읽기 성능 향상을 위한 버퍼링 또는 변환 레벨에서 사용될 때