기술 블로그

리눅스 진단 명령어

hongyb — Tue, 17 Jun 2025 00:47:15 +0900

리눅스 진단 명령어

개발을 하다 보면 OS 상황을 모니터 해야 할 경우도 있다. 시스템 장애가 애플리케이션에만 있는 것이 아니기 때문이다. 리눅스 진단에 사용할 수 있는 명령어를 알아보고 OS 상황을 모니터링할 때 활용해 보자.

https://www.brendangregg.com/linuxperf.html [Brendan Gregg 블로그]

위에는 Brendan Gregg의 블로그에서 가져온 리눅스 분석 도구 표이다. 중요한 분석 도구부터 차례대로 알아보도록 하겠다.

CPU 모니터링

CPU를 모니터링할 때 mpstat을 사용한다. mpstat이란 사용 가능한 CPU 사용 상황을 제공한다. 데이터 출력 간격과 수행 횟수를 지정할 수 있다.

mpstat 5 3

명령어 [데이터 출력 간격] [데이터 수행 횟수] 순으로 지정해야 한다.

출력된 결과는 다음과 같다.

사진 속 결과 의미는 다음과 같다.

%usr : 애플리케이션에서 수행되는 동안 사용한 CPU 시간 비율
%nice : nice 우선순위로 애플리케이션 레벨에서 수행되는 동안 사용한 CPU 시간 비율
%sys : 커널 레벨에서 수행되는 동안 사용한 CPU 시간 비율. 인터럽트 비용은 포함되지 않는다.
%iowait : 시스템 디스크의 I/O 요청을 처리하는 동안 CPU가 유휴 상태인 시간 비율
%irq : 하드웨어 인터럽트를 CPU에서 처리하는 데 사용한 CPU 시간 비율
%soft : 소프트웨어 인터럽트를 CPU에서 처리하는 데 사용한 CPU 시간 비율
%steal : 하이퍼바이저가 가상 프로세서 처리할 때 CPU에서 대기하는 데 사용한 시간 비율
%guest : 가산 프로세서 수행하기 위해 사용한 시간 비율
%idle : 유휴 상태인 시간 비율

nice란 사용자가 nice라는 명령어를 통해 프로세스 우선순위 변경할 수 있는데 그 프로세스에 의해 수행된 시간을 의미한다.

mpstat 옵션

'I' 옵션은 인터럽트 통계 제공한다. 여기서 SUM, CPU, ALL 중 하나를 지정해야 한다.

mpstat -I [SUM | CPU | ALL]

SUM은 모든 CPU의 초당 인터럽트 수의 합
CPU는 각 CPU 별로 상세한 인터럽트 정보 제공
ALL은 둘을 합친 내용

mpstat -I SUM

intr/s는 초당 CPU가 받은 인터럽트 수이다. 이외에 다른 옵션은 mpstat 매뉴얼을 참고하자.

CPU 모니터링 방법

CPU 모니터링은 다음 순서대로 진행하자.

User CPU
System CPU
I/O Wait CPU
기타 CPU

자바 애플리케이션에서 (User CPU : System CPU) 사용 비율은 10:1 ~ 8:1 정도라고 볼 수 있다. 만약 이 비율이 1:1이나 3:2 정도라면 해당 애플리케이션이 커널 CPU를 많이 쓴다는 의미가 된다.

I/O Wait가 높다면 자바 애플리케이션에서 I/O 작업이 많다는 의미이다. 어디서 I/O가 많은지 찾아야 한다.

전반적인 상황 모니터링

vmstat : 가상 메모리 통계를 제공한다. 프로세스, 메모리, 페이장, 블록 I/O, 트랩스, 디스크, CPU 정보를 제공한다.

다음 명령어를 실행하면 5초 간격으로 데이터를 출력한다.

vmstat 5

결과는 5초간의 평균값이고, 첫 번째는 시스템 부팅된 이후의 통곗값이다.

결과를 정리하면 다음과 같다.

procs
- r : 실행하기 위해 대기 중인 프로세스 수
- b : uninterruptible sleep 상태에 있는 프로세스 수
memory
- swpd : 가상 메모리 사용한 크기
- free : 사용하지 않는 메모리 크기
- buff : 버퍼로 사용하는 메모리 크기
- cache : 캐시로 사용하는 메모리 크기
swap
- si : 초당 디스크에서 읽은 스왑 된 메모리 크기
- so : 초당 디스크로 스왑 된 메모리 크기
io
- bi : 블록 디바이스에서 받은 블록 수
- bo : 블록 디바이스로 보낸 블록 수
system
- in : clock 포함한 초당 인터럽트 수
- cs : 초당 콘텍스트 전환 개수
cpu
- us : 사용자 코드 수행하는데 소요된 시간
- sy : 커널 코드 수행하는데 소요된 시간
- id : idle 상태에서 수행된 시간
- wa : io 대기하는데 소요된 시간
- st : 가상 머신에 뺏긴 시간

프로세스별 CPU 사용량 모니터링

프로세스별 CPU 사용량 모니터링 명령어는 다음과 같다.

pidstat

디스크 사용량

디스크 사용량 명령어는 df와 du명령어가 있다. 우선 df 명령어부터 살펴보자.

df -h

Use%는 사용률을 뜻하는데 사용률이 100%가 되면 다음 에러가 발생할 수 있다.

로그가 쓰이지 않아 hang이 발생
컴파일 불가

du 명령어는 파일과 디렉터리 점유 상황을 보여준다.

du -s [디렉터리 경로]

IO 사용량

iostat

IO 모니터링 도구는 iostat이다.

iostat

시스템 부팅 이후 지금까지 통계 정보를 보여준다. 수행 시간 간격을 지정하고 싶다면 옵션으로 간격 수행 횟수를 붙여주면 된다.

결과는 다음을 뜻한다.

tps : 디바이스에 초당 전송 요청한 건수
read/s : 디바이스에 초당 읽은 데이터 블록 단위
wrtn/s : 디바이스에서 초당 쓴 데이터 블록 단위
read : 디바이스에서 지정한 간격 동안 읽은 블록 수
wrtn : 디바이스에서 지정한 간격 동안 쓴 전체 블록 수

lsof

lsof는 특정 프로세스에서 어떤 IO가 발생하는지 알려주는 명령어다. lsof에서 쓸 만한 옵션이 2가지 정도 있다. 첫 번째는 -p 옵션이다. 해당 pid를 갖는 프로세스에서 참조하는 파일의 목록을 보여준다. -c 옵션은 ‘명령어 이름’과 같은 명령어로 수행된 프로세스에서 참조하는 파일 목록을 보여준다.

lsof -p [pid]

항목의 의미는 다음과 같다.

command : 명령어 이름
PID : 프로세스 아이디
USER : 명령어 수행한 사용자 아이디
FD : 파일 설명이나 상태
TYPE : 파일 타입
DEVICE : 디바이스 정보
SIZE/OFF : 파일 크기
NODE : 로컬 파일 노드 정보
NAME : 파일 이름

Java 메모리 진단

hongyb — Wed, 11 Jun 2025 00:12:07 +0900

Java는 Garbage Collector(GC)가 알아서 사용하지 않는 객체를 메모리에서 제거한다. 그래서 메모리 릭 현상이 간간히 발생하고, 원인을 잡기 쉽지 않다. 메모리 릭이 발생하면 원인을 어떻게 찾아야 하는지 알아보겠다.

Java 메모리 영역

자바의 메모리 영역은 다음과 같다.

PC 레지스터 : 스레드의 JVM인스트럭션 주소가 저장되어 있다. 스레드별 각각 보유한다.
JVM 스택 : 지역 변수와 부분 결과를 저장한다. 메서드 호출 및 리턴 정보 보관된다. 스레드별 각각 보유한다.
힙 : 인스턴스와 배열이 할당된다. GC에 의해 관리된다.
메서드 영역 : 모든 JVM 스레드 공유하며, 클래스 구조 정보 저장한다.
런타임 상수 풀 : 클래스 및 인터페이스에 대한 constant_pool 테이블을 실행 시 참고하기 위한 저장소이다.
네이티브 메서드 스택 : 자바 언어 이외의 네이티브 언어를 호출할 경우 타 언어 스택 정보 저장한다.

OutOfMemoryError란

OutOfMemoryError는 가비지 컬렉터가 새로운 객체를 생성할 공간을 만들지 못하고, 힙 영역 메모리가 증가될 수 없을 때 발생한다. OutOfMemoryError가 왜 발생하는지 원인을 알고 싶으면 에러 로그를 잘 확인해봐야 한다. 에러로그를 살펴보겠다.

1. Exception in thread “majava.lang.OutOfMemoryError: Java heap space

메모리 크기를 너무 적게 잡아 놓거나, 메모리 크기를 지정하지 않은 경우 : 자바 옵션 중 -Xms는 JVM메모리 최소 크기를, -Xmx는 최대 메모리 크기를 지정한다.
오래된 객체들이 계속 참조되고 있어서 GC가 되지 않는 경우 : static 잘못 사용하거나 애플리케이션이 객체를 지속해서 참조할 경우 → 메모리 릭 발생
스레드 우선순위 높일 경우 : GC 처리속도보다 우선순위 높은 스레드가 메모리에 생성하는 속도가 빨라 문제 발생
큰 덩어리 객체 여러 개 있을 경우

2. Exception in thread “main”:java.lang.OutOfMemoryError: Metaspace

많은 클래스가 자바 프로세스에 로딩될 경우에 발생한다. 메타 영역 크기보다 크게 지정하면 된다. 옵션은 -XX:MaxMetaspaceSize=128m를 사용하면 된다.

3. Exception in thread “main”:java.lang.OutOfMemoryError: Requested array size exceeds VM limit

배열 크기가 힙 영역 코기보다 크게 지정되었을 때 발생

4. Exception in thread “main”:java.lang.OutOfMemoryError: request <size> bytes for <reason>. Out of swap space

네이티브 힙 영역이 부족할 때 발생한다. 즉 OS의 메모리가 부족한 경우이다.

5. Exception in thread “main”:java.lang.OutOfMemoryError: <reason> <stacktrace> (Native method)

네이티브 힙 영역 메모리 할당할 때 발생하는 메시지이다. 앞은 JVM코드에서 발견될 때 발생하고 이 경우 JNI나 네이티브 코드에서 발생한다.

[메모리 릭]
메모리 릭이란 객체가 GC 되지 않아 메모리가 부족해지는 현상이다. 코드나 클래스 로더 문제일 수 있다.

잦은 GC

OutOfMemoryError 이외에도 잦은 GC에 의해 문제 발생할 수 있다. GC는 Minot GC와 Full GC 두 가지가 있으며 보통 Full GC가 많이 발생하면 성능에 영향을 미친다. 다음 규칙을 따르면 GC를 발생시키지 않을 수 있다.

임시 메모리 사용 최소화
객체 재사용
XML 처리 시 메모리 점유하는 DOM보다 SAX 사용
많은 데이터 한 번에 보여주는 비즈니스 로직 제거
임시 메모리 많이 사용하는 부분 제거

이 외에도 GC가 자주 발생하는 원인은 여러 가지가 있다. 운영하는 서비스에 동시에 1000명이 넘는 사용자가 접속하는 경우 Full GC가 자주 발생하는 것은 당연한 현상이다.

jstat 명령어

메모리 단면(힙 덤프)은 메모리가 부족해지는 현상이 지속될 때와 OutOfMemoryError가 발생했을 때 생성해야 한다. 그러면 메모리가 부족해지는지 어떻게 알 수 있을까? jstat 명령어로 간단하게 확인할 수 있다.

다음 명령어를 입력하면 1초 간격으로 어떤 메모리 영역에서 얼마나 메모리를 사용하는지 확인할 수 있다.

jstat -gcutil [pid] 1s

E는 Eden영역, S0과 S1은 Survivor영역이다. 두 영역은 Young으로 묶을 수 있다. O는 Old영역으로 Tenured 영역으로 나뉜다. 이 Tenured영역이 GC이후에도 증가하는지 확인하면 된다.

보통 Tenured영역은 애플리케이션 동작중에 계속 증가하는 것이 기본이다. 하지만 Full GC이후에도 메모리 사용량이 증가하고 있다면 메모리 릭이 발생하고 있다는 증거이다.

이런 경우에 메모리 단면은 확인해야 하지만 한 가지 주의할 점이 있다. 메모리 사용량 분석할 때 성능에 많은 영향을 주기 때문에 운영 서버에서 확인하면 안 된다. 개발자의 PC나 개발 서버에서 문제점을 확인해야 한다. 메모리 덤프 시 다음 현상이 발생한다.

덤프 파일 생성하는 동안 서비스 불가능
덤프 생성 시 많은 시간 소요
큰 파일이 생성

메모리 단면은 JVM에 있는 객체 하나하나에 대한 정보를 담고 있다. 그래서 생성하는데 오래 걸리고 시스템 운영에 문제가 발생한다.

메모리 단면 생성

jdk에서 지원하는 jmap 명령어로 힙 덤프를 생성할 수 있다. jmap 필요 옵션은 다음과 같다.

-dump:[live,] format=b, file=<filename> : 메모리 단면 생성. live옵션은 살아있는 객체만 덤프 하라는 뜻. format을 b로 지정 시 바이너리 형태 파일 생성. file옵션에 지정된 파일 이름으로 생성. 예시) jmap -dump:format=b, file=goldmem.bin [pid]
-finalizerinfo : GC가 되려고 기다리고 있는 객체 정보 출력
-clstats : 클래스 로더의 통계 정보를 제공
-histo[:live] : 힙 영역의 메모리 점유 상태를 가장 많이 점유한 객체부터 출력
-F : -dump와 -histo 옵션과 같이 사용. 덤프가 발생되지 않을 경우 강제 발생시킬 때 사용

histo 옵션으로 실행하면 결과는 다음과 같다.

jmap -histo [pid]

메모리를 가장 많이 점유한 객체부터 데이터를 출력한다. 순번, 인스턴스 수 바이트 크기, 클리스 이름 순서로 나열되고 있다. 대문자로 시작하는 클래스는 배열 형태의 클래스를 의미하고 <>로 둘러싸인 클래스들은 JVM에서 사용하는 것이다.

몇몇의 JDK에서 jmap을 두 번 이상 사용할 수 없다. 리눅스에서 그런 경우가 발생하면, gcore로 코어 덤프를 발생시키고 그 덤프에 jmap을 사용하면 된다.

gcore -o holdmem.core [pid]

위와 같이 명령어를 입력하면 holdmem.core.[pid] 라는 파일이 생성된다. 파일이름뒤에 .pid 형식으로 프로세스 id가 붙는다. 이 파일을 jmap을 활용하여 메모리 덤프를 생성할 수 있다.

jmap [옵션] [자바 실팽 파일 위치] [코어덤프 파일]
ex) jmap -dump:format=b, file=holdmem.dump /usr/local/java/bin/java holdmem.core.1975

자동으로 힙 덤프 생성

다음 옵션을 주면 OutOfMemoryError발생 시 힙 덤프가 생성된다.

-XX:+HeapDumpOnOutOfMemoryError

힙을 원하는 정보에 저장하기 위해 다음 명령어를 입력한다.

-XX:HeapDumpPath=[경로]

[예시]

java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp

다음 옵션은 OutOfMemoryError발생 시 실행되는 스크립트를 명시할 수 있다.

-XX:OnOutOfMemoryError="명령어"

다음과 같이 활용하면 된다.

java -XX:+OnOutOfMemoryError="gcore -o gcore.dump %p" 클래스 이름

%p는 현재 실행 중인 자바 프로세스 아이디를 의미한다.

메모리 문제 Case

1. 시스템이 느릴 경우

시스템이 느리다고 항상 메모리 단면을 사용하는 것은 아니다. 그래도 원인을 찾지 못할 경우 메모리 분석 단계로 넘어가야 한다. 메모리 때문에 시스템이 느릴 경우에 다음을 의심해야 한다.

메모리를 작게 잡아 GC가 자주 발생하는 경우
임시 메모리 사용하여 GC가 자주 발생하는 경우

이 경우 jstat을 사용하자. 메모리 크기와 관련됐으면 -gccapacity 옵션을, 사용량과 관련됐으면 -gcutil 옵션을 사용하자.

2. 애플리케이션 응답하지 않을 경우

메모리 릭이 발생하면 GC 작업만 실행하고, 애플리케이션이 응답하지 않을 수 있다. 메모리 릭일 때 다음 절차를 따르자.

메모리 사용량 확인한다. 메모리 사용량 95% 이상인 경우 메모리 릭 문제 원인일 수 있다.
메모리 사용량 지속해서 높을 경우 메모리 단면 생성
apm 사용해 어떤 객체가 죽지 않고 점유되는지 확인한다.

[자바 트러블 슈팅] 스레드 진단

hongyb — Mon, 26 May 2025 14:33:32 +0900

Java 프로세스에서 스레드 단면을 분석하고 문제를 해결하는 방법을 알아보자.

스레드에서 발생할 수 있는 문제

스레드를 처리할 때 발생할 수 있는 문제는 다음과 같다.

1. 레이스 컨디션

멀티 스레드 환경에서 ‘공유 데이터’에 아무런 록 처리를 하지 않을 경우 문제 발생
여러 스레드에서 동시에 수정 시 공유 데이터 꼬여서 무한 대기 or 무한 루프

2. 데드록

두 개 이상의 스레드에서 서로의 록이 풀리기 기다리는 상황
4가지 조건이 필요[비선점, 상호배제, 점유와 대기, 순환 참조]

예시) 스레드 A에서 Data1에 록을 건 상태에서 Data2에 접근하려 한다. 스레드 B에서 Data2에 록을 건 상태에서 Data1에 접근하려 한다.

3. 스타베이션

스레드가 CPU로부터 일할 기회를 받지 못하는 경우

4. 라이브 록

응답을 요청한 스레드에서 계속해서 응답을 요청하는 작업이 계속되는 경우
데드록과 달리 CPU를 계속해서 사용한다.

록 경합을 피하는 방법

1. 코드가 아닌 데이터를 보호

자바에서 메서드를 synchronized로 감싸지 말고 데이터만 감싸라
데이터만 동시성을 막아야지 코드를 막을 필요는 없다.

2. 록 사용에 비싼 계산 하지 마라

공유 데이터를 사용 시 간단한 로직만 구현

3. 록 분리해라

공유 데이터를 하나의 록으로 설정하지 말고 최소한으로 분리해라
배열 전체가 록으로 걸지 말고 배열 요소들이 다른 록을 갖도록 분산해라

4. atomic 작업 사용하라

병렬 프로그래밍에서 제공하는 atomic연산을 사용해라

5. 동기화된 데이터 구조를 사용하라

atomic연산을 사용할 수 없으면, 내부적으로 atomic을 사용하는 데이터 구조를 사용해라

6. 읽기-쓰기 록 디자인 패턴을 사용하라

읽기와 쓰기를 위한 사용자를 분리해서 성능 저하 없이 사용 가능하다.

7. 읽기 전용 데이터를 사용하라

록을 걸지 않고 모든 스레드에서 접근할 수 있는 읽기 전용 데이터를 만들어라

8. 지역 변수, 스레드 로컬 저장소를 사용하라

스레드의 로컬에 있는 공유 변수는 다른 것으로 치환 가능하다.
ex) 배열에 있는 큰 수를 찾을 때 스레드에서 값 증가할 때마다 큰 수를 따로 저장하면 된다.

스레드 단면 자르기

앞에서 본 스레드의 문제를 찾기 위해 스레드 단면을 분석해야 한다. 시스템에 문제가 발생했을 경우 10~30초 간격으로 최소 열 번 정도 스레드 단면을 생성하자. 다음은 스레드 단면 분석을 해야 하는 경우이다.

시스템 응답 없을 때
시스템의 CPU가 떨어지지 않을 때
애플리케이션 응답 없을 때
시스템이 내 마음대로 작동하지 않을 때

스레드 단면 정보

스레드 단면은 다음 사진과 같다.

항목 정보는 다음과 같다.

스레드 이름
식별자 : 데몬 스레드일 때만 생성
스레드 우선순위 : prio 부분에 우선순위를 숫자로 나타낸다. 숫자 높을수록 우선순위 높다.
스레드 id(tid) : 다른 스레드와 구분되는 스레드 id, 해당 스레드가 점유하는 메모리 주소로 봐도 된다.
네이티브 스레드 ID(nid) : OS에서 관리하는 스레드의 ID
스레드 상태
- NEW : 아직 시작되지 않은 상태
- RUNNABLE : 수행 중인 상태
- BLOCKED : 스레드가 잠겨 있어 풀리기 기다리는 상태
- WAITING : 다른 스레드가 특정 작업 수행하여 깨울 때까지 무한정 기다리는 상태
- TIMED_WAITING : 다른 스레드가 특정 작업 수행하여 깨울 때까지 지정된 시간만큼 기다리는 상태
- TERMINATED : 종료
주소 범위

그 외 at으로 된 부분은 해당 스레드의 스택 정보이다.

스레드 단면 생성 방법

다음 명령어를 입력해 프로세스 id를 구한다

JPS

이후 다음과 같이 kill 명령어를 사용하면 된다.

kill -3 [pid]

주의할 점은 스레드 단면 생성을 위해 -3 옵션을 써야 한다. -9 옵션을 사용하면 프로세스가 죽는다.

다음과 같은 명령어를 사용해도 된다.

jstack [pid]

프로세스의 CPU 사용량을 알기 위해 다음 명령어를 사용한다.

ps -Lf -p [PID]

다음처럼 결과가 나온다.

항목은 다음과 같다.

UID : 사용자 id
PID : 프로세스 id
PPID : 부모 프로세스 id
LWP : 스레드 id
C : CPU 사용량
NLWP : 해당 프로세스에서 사용하는 스레드 수. NLWP 수
STIME : 프로세스 통제하는 터미널

스레드로 문제 해결

스레드로 해결할 수 있는 문제는 다음과 같다.

시스템이 느린 경우
- 전체 시스템이 항상 느린 경우
- 시스템 특정 기능이 느린 경우
- 특정 시간에 전체 애플리케이션이 느린 경우
- 특정 시간에 특정 애플리케이션이 느린 경우
- 특정 기능이 점점 느려질 경우
- 특정 사용자만 느려질 경우
시스템 응답이 없는 경우
- 모든 애플리케이션이 응답 없는 경우
- 특정 기능이 응답하지 않는 경우

다음은 스레드 단면으로 해결하기 애매한 경우이다.

예외 계속 발생
- 모든 사용자가 특정 기능 수행하면 예외 발생
- 특정 사용자가 특정 기능에서만 예외
- 특정 시간대에서 전체 애플리케이션 예외
- 특정 시간대에 특정 애플리케이션에 예외

시스템이 죽는 경우 스레드 단면만으로 해결하지 못한다. 왜냐하면 그 경우 스레드 단면이 생성되지 않기 대문이다. 시스템이 죽는 문제가 발생했을 때 OnError 옵션을 추가해 실마리를 남기자.

-XX:OnError="명령어"
ex) -XX:OnError="kill -e %p"

시스템이 느릴 경우 전차

시스템이 느릴 때 다음 순서로 점검하자

CPU, 메모리 리소스 사용량
외부와 연동하는 리소스 사용량
WAS 메모리 및 스레드 설정 및 사용량
Web 서버 설정 점검
OS 설정 점검
스레드 상태 점검
메모리 상태 점검

시스템 응답 없을 때 스레드 단면

스레드 단면은 시스템 응답이 없는 경우에 큰 효과를 보인다. 어떤 스레드에서 응답을 주지 않아 시스템이 멈췄는지 알 수 있다. ex) 스레드 풀이나 DB 커넥션 풀이 꽉 찼을 경우

어떤 순서로 봐야 할지 다음과 같다.

전체 스레드 개수 확인
스레드 메모리 사용량 확인
Lock 확인
Runnable 스레드 살펴보기

힙 메모리가 부족해 시스템이 응답하지 않을 수 있다. 이 경우 GC 관련 스레드가 CPU 코어를 하나 이상 100% 점유하고 있다. 이런 상황에 다음 과정을 실행한다.

스레드 단면 주기적으로 떠놓는다.
ps -Lf -p pid 명령어도 같이 수행한다.
2번에서 CPU 사용 시간이 지속해서 증가하는 스레드가 있다면 그 스레드 id 확인 후 스레드 단면에서 해당 스레드를 확인한다.
3번에서 확인한 스레드가 GC관련 스레드라면, jstat 명령어로 메모리 사용량 확인한다. ex) jstat -gcutil 5s
GC 관련 스레드가 아니라면 무한 루프에 빠지지 않았는지 확인한다.

인덱스 스캔 효율화

hongyb — Mon, 21 Apr 2025 18:20:03 +0900

인덱스 스캔 효율화 과정

인덱스 스캔 효율성은 인덱스 칼럼을 등치(=) 조건으로 사용할 때 가장 좋다. 만약 인덱스 칼럼 중 일부가 등치 조건이 아니더라도 그 칼럼이 뒤쪽 칼럼일 경우에는 비효율이 없다.

왜 그런지 내가 실제 업무에서 인덱스 스캔 효율화를 한 과정을 통해 살펴보도록 하겠다.

로그 테이블 인덱스 개선 과정

팀에서 새로운 로그 테이블을 만들었고, 그 로그 테이블에서 PK 인덱스만 있었다. PK 인덱스는 다음과 같이 설정되었다.

..., LOG_DT(로그 날짜), LOG_HMS(로그 시간), ...

로그 테이블에서 주로 사용되는 쿼리를 알아보니 처리일자를 등치 조건(=), 처리시간을 BETWEEN 조건으로 사용하고 있었다. 또한 PK에 없는 GUID라는 필드는 IN 조건으로 활용되고 있었다.

   select
        ...
    from
        ...
    where
		    ...
        LOG_DT=? 
        and (
            LOG_HMS between ? and ?
        ) 
        and (
            GUID in (
                ? , ? , ?
            )
        ) 
	    ...

위 쿼리에서 인덱스를 최대로 활용할 수 있는 인덱스는 무엇일까? 다음은 새로운 인덱스 후보이다.

…, LOG_DT, LOG_HMS, GUID, …
…, LOG_DT, GUID, LOG_HMS, …

첫 번째 인덱스를 인덱스 1, 두 번째 인덱스를 인덱스 2라고 부르겠다. 인덱스 1과, 인덱스 2를 생성 후 실험을 진행했다.

테스트 결과

약 25만 개의 로그를 생성 후 테스트 해봤다. 대부분의 RDB의 경우 메모리에 값을 캐시 한다. 따라서 정확한 테스트를 위해 쿼리 실행마다 캐시를 비워주었다. 쿼리를 작성 후 실행 계획을 살펴보았다.

인덱스 1 결과

rows : 185,626
filtered : 50

185,626건을 스캔하고 그중 50%가 최종 결과로 넘어간다는 뜻이다. 조회시간은 약 0.05s

인덱스 2 결과

rows : 216
filtered : 100

216건을 스캔하고 그중 100% 전부 최종 결과로 넘어간다. 조회시간은 약 0.005이다. 왜 이런 결과가 나왔을까?

인덱스 스캔 효율성

인덱스 선행 칼럼이 조건절에 없거나 ‘=’ 조건이 아니면 인덱스 스캔 과정에서 비효율이 발생한다.

선행 칼럼, 후행 칼럼

‘선행 칼럼’은 어떤 칼럼보다 ‘상대적으로 앞쪽’에 놓인 칼럼을 지칭할 때 사용하겠다. 반대로 ‘후행 칼럼’은 ‘상대적으로 뒤쪽’에 놓인 칼럼을 지칭할 때 사용하겠다.

다음 순서대로 인덱스가 설정되었다면 LOG_DT는 선행 칼럼, LOG_HMS는 후행 칼럼이다.

..., LOG_DT(로그 날짜), LOG_HMS(로그 시간), ...

인덱스 선행 칼럼이 조건절에 없거나 ‘=’ 조건이 아니면 인덱스 스캔 과정에서 비효율이 발생하는 이유를 알기 위해 다음 예시를 보자. 4 문자를 잘라 테이블 칼럼에 각각 저장하고 [C1 + C2 + C3 + C4] 순서대로 인덱스를 생성했다.

[인덱스 테이블]

예시 1.

위 테이블에서 ‘성능검’으로 시작하는 레코드를 검색하려면 어디서 스캔을 시작하고 멈춰야 될까?

 where c1 = '성'
 and c2 = '능'
 and c3 = '검'

‘성능검’으로 시작하는 레코드를 검색할 때 인덱스 수직적 탐색을 통해 ‘성능검사’ 레코드로 찾아간다. 거기서부터 스캔을 시작해 ‘성능계수’까지 총 3개의 레코드를 스캔하고 멈춘다. 두 건을 얻기 위해 세 건을 스캔했다.

예시 2.

‘성능’으로 시작하고 네 번째 칼럼이 ‘선’인 레코드를 검색하면 어디서 스캔을 시작하고 어디서 멈출까? 쿼리문은 다음과 같다.

 where c1 = '성'
 and c2 = '능'
 and c4 = '선'

위 질문은 ‘성능’으로 시작하고 네 번째 칼럼이 ‘선’인 레코드를 검색할 때 아래처럼 ‘성능’으로 시작하는 레코드를 모두 스캔해야 한다. 결과는 똑같이 두 건이지만, 예시 1보다 훨씬 더 많은 인덱스 레코드를 스캔해야 한다.

인덱스 조건과 필터 조건

인덱스 액세스 조건

인덱스 스캔 범위를 결정하는 조건절
인덱스 수직적 탐색을 통해 스캔 시작점을 결정하는데 영향 미친다.
인덱스 리프 블록 스캔하다 어디서 멈출지 결정 미치는 조건절

인덱스 필터 조건

테이블로 액세스 할지 결정하는 조건절
쿠리 수행 다음 단계로 전달하거나 최종 결과집합에 포함할지 결정

앞선 1번 예제에서 C1, C2, C3가 모두 인덱스 액세스 조건이었다. 2번 에제는 C1, C2가 인덱스 액세스 조건이고, C4는 인덱스 필터 조건이었다.

비교 연산자 종류와 칼럼 순서에 따른 군집성

인덱스에는 ‘같은 값’을 갖는 레코드들이 군집해 있다. ‘같은 값’을 찾을 때 ‘=’ 연산자를 사용하므로 인덱스 칼럼을 앞쪽부터 누락 없이 ‘=’ 연산자로 조회하면 조건절을 만족하는 레코드는 모두 모여 있다. 인덱스 칼럼 중 어느 하나를 누락하거나 ‘=’ 조건이 아닌 연산자로 조회하면 조건절 만족하는 레코드가 흩어진다.

다음은 인덱스 테이블이다.

아래 조건절로 인덱스 구성 칼럼을 모두 ‘=’ 조건으로 비교할 때 조건을 만족하는 레코드들이 5~7번까지 모여 있다.

where C1 = 1
and C2 = 'A'
and C3 = '나'
and C4 = 'a'

이와 달리 칼럼 중간에 범위검색 조건일 때는 다른 결과를 가져온다. 다음 조건절처럼 세 번째 칼럼 C3가 범위검색 조건인 경우는 C1부터 C3까지 세 조건을 만족하는 인덱스 레코드는 모여 있지만(2~12번), C4 조건까지 만족하는 레코드는 흩어지게 된다.(2, 3, 5, 6, 7, 11번)

where C1 = 1
and C2 = 'A'
and C3 between '가' and '다'
and C4 = 'a'

선행 칼럼이 모두 ‘=’ 조건인 상태에서 첫 번째 나타나는 범위검색 조건까지만 만족하는 인덱스 레코드는 모두 연속해서 모여 있지만, 그 이하 조건까지 만족하는 레코드는 비교 연산자 종류에 상관없이 흩어진다는 규칙을 도출할 수 있다.

즉 인덱스 스캔 범위를 결정하는 것은 인덱스 액세스 조건이고, 선행 칼럼이 ‘=’ 조건인 상태에서 첫 번째 나타나는 범위검색 조건이 인덱스 스캔 범위를 결정한다.

BETWEEN을 IN-List로 전환

범위검색 칼럼이 갖는 문제점을 어떻게 해결할까? 범위검색 칼럼이 맨 뒤로 가도록 인덱스 순서를 변경하면 좋겠지만 운영 시스템에서 쉽지 않다. 이럴 때 BETWEEN 조건을 IN-List로 바꿔주면 효과를 얻을 수 있다.

예시 1.

[인터넷 매물 + 아파트시세 코드 + 평형 + 평형 타입] 순서대로 인덱스를 설정 후 다음 BETWEEN 조건을 검색했다고 가정해 보자.

select *
from 매물아파트매매
where 아파트시세코드='A01011350900056'
and 평형 '59'
and 평형타입 = 'A'
and 인터넷매물 between '1' and '3'
order by 입력일 desc

인터넷 선두 칼럼 인터넷매물에 BETWEEN 연산자를 사용하면 나머지 조건(아파트시세코드, 평형, 평형타입)이 뿔뿔이 흩어지게 된다. 따라서 조건을 만족하지 않는 레코드까지 스캔하고서 버리는 비효율이 발생한다.

예시 2.

BETWEEN 조건절을 아래와 같이 IN-List로 바꿔보자.

select *
from 매물아파트매매
where 인터넷매물 in ('1', '2', '3')
and 아파트시세코드='A01011350900056'
and 평형 = '59'
and 평형타입 = 'A'
order by 입력일 desc

위 그림처럼 인덱스 수직 탐색이 3번 발생한다. 실행 계획을 보면 INLIST ITERATOR가 발생하는 것을 알 수 있다. IN-List 개수만큼 아파트매물이 ‘1’인 경우 ‘2’인 경우 ‘3’인 경우 UNION ALL 브랜치가 생성되고 각 브랜치마다 모든 칼럼을 ‘=’ 조건으로 검색하므로 선두 칼럼이 BETWEEN을 사용할 때와 같은 비효율이 사라진다.

주의사항

BETWEEN 조건을 IN-List 조건으로 전환 시 주의할 점은 IN-List 개수가 많지 않아야 한다. IN-List 개수가 많으면 수직 탐색 비용이 많이 발생한다. 그러면 BETWEEN 조건 때문에 리프 블록을 스캔하는 비효율보다 IN-List 개수만큼 브랜치 블록을 탐색하는 비효율이 클 수 있다.

또한 인덱스 스캔 과정에서 선택되는 레코드들이 서로 멀리 떨어져 있을 때만 유용하다.

where 고객등급 between 'C' and 'D'
and 고객번호 = 123

위와 같이 [고객등급 + 고객번호] 순으로 구성한 인덱스에서 고객번호 = 123 조건을 만족하는 레코드가 멀리 떨어져 있을 때만 BETWEEN 조건을 IN-List로 전환하는 기법이 유용하다. BETWEEN 조건 때문에 인덱스를 비효율적으로 스캔하더라도 블록 IO 측면에서 소량에 그치는 경우가 많다. 인덱스 리프 블록에는 테이블 블록과 달리 많은 레코드가 담기기 때문이다. IN-List 개수가 많아질수록 수직적 탐색 과정에서 많은 블록을 읽게 되므로 성능이 안 좋아질 수 있다.

결론

다시 로그 데이터 쿼리를 보겠다.

   select
        ...
    from
        ...
    where
		    ...
        LOG_DT=? 
        and (
            LOG_HMS between ? and ?
        ) 
        and (
            GUID in (
                ? , ? , ?
            )
        ) 
	    ...

LOG_DT는 등치(=) 조건이고, LOG_HMS는 범위(BETWEEN) 조건이다. 따라서 LOG_DT가 LOG_HMS보다 인덱스 순서가 앞서야 한다. 마찬가지로 인덱스에서 GUID도 LOG_HMS보다 앞서야 한다. GUID는 범위 조건이 아닌 In-List조건이기 때문이다. BETWEEN을 사용하는 LOG_HMS는 인덱스에 맨 뒤쪽에 있어야 한다.

참고자료

https://product.kyobobook.co.kr/detail/S000001975837

친절한 SQL 튜닝 | 조시형 - 교보문고

친절한 SQL 튜닝 | 책 제목은 필자가 애청하는 라디오 프로그램 ‘손에 잡히는 경제’ 중 ‘친절한 경제’라는 코너에서 착안했다. 어려운 경제 이슈를 일반인 눈높이에 맞게 풀어서 설명해 주는

product.kyobobook.co.kr

리팩터링

hongyb — Fri, 11 Apr 2025 00:05:28 +0900

리팩터링

https://product.kyobobook.co.kr/detail/S000001810241

리팩터링 | 마틴 파울러 - 교보문고

리팩터링 | 개발자가 선택한 프로그램 가치를 높이는 최고의 코드 관리 기술 마틴 파울러의 『리팩터링』이 새롭게 돌아왔다.지난 20년간 전 세계 프로그래머에게 리팩터링의 교본이었던 이 책

product.kyobobook.co.kr

마틴 파울러의 리팩터링 2판을 읽어보았다. 책 1장은 리팩터링 예시를 설명하고 있다. 2장은 리팩터링이 무엇인지 왜 해야 하는지를 설명하고 있다. 3장은 리팩터링이 필요한 코드 스멜 부분을 설명하고 있으며 4장은 리팩터링에 필요한 테스트를 설명하고 있다. 나머지 부분은 리팩터링 기법을 설명한 카탈로그이다. 책의 저자도 카탈로그는 필요할 때마다 찾아보는 것을 권장하기 때문에 따로 정리하지 않았다. 1장부터 3장까지 내용을 정리해 보았다.

리팩터링 정의

리팩터링 정의는 다음과 같다.

리팩터링 : 소프트웨어 겉보기 동작은 그대로 유지한 채, 코드를 이해하고 수정하기 쉽도록 내부 구조를 변경하는 기법

‘겉보기 동작’ 뜻이 애매해 보이는데 간단히 말하자면 리팩터링 전과 후의 코드가 똑같이 동작해야 한다는 뜻이다. 리팩터링의 목적은 코드의 기능이 똑같이 작동하지만 코드를 이해하고 수정하기 쉽게 만드는 것이다. 리팩터링은 프로그램의 성능이 개선되는 것과는 상관없다.

리팩터링 하는 이유

1. 소프트웨어 설계가 좋아진다.

리팩터링 하지 않으면 내부 아키텍처가 무너지기 쉽다.
규칙적인 리팩터링은 코드 구조 지탱한다.
코드 중복 제거와 같은 리팩터링은 설계 개선 작업에 중요한 역할 한다.

2. 소프트웨어 이해가 쉬워진다.

리팩터링은 코드가 잘 읽히게 도와준다
코드의 목적, 의도를 명확하게 전달하도록 개선할 수 있다.

3. 버그를 쉽게 찾을 수 있다.

코드 이해가 쉽다 → 버그를 찾기 쉽다는 뜻이다.

4. 프로그래밍 속도 높일 수 있다.

내부 설계가 잘 된 소프트웨어는 새 기능과 버그를 쉽게 고칠 수 있다.
설계가 좋을수록 빠른 기능이 누적될수록 빠른 개발이 가능하다.
리팩터링의 목적은 개발 기간을 단축하는 것이다. 기능 추가 시간 줄이고 버그 수정 시간 줄여준다.

리팩터링 시기

기능을 쉽게 추가하도록 하는 리팩터링

코드에 기능을 새로 추가하기 전에 리팩터링을 권장한다. 기능 추가 전 코드의 구조를 바꾸면 다른 작업을 하기 쉬워질 만한 부분을 찾는다.

코드를 이해하기 쉽게 만들기

코드의 의도를 명확하게 드러나도록 리팩터링 하는 것이 좋다. 조건부 로직 이상한지 살펴보고, 함수 이름 잘 지었는지 등등을 살펴보는 습관을 기르자.

쓰레기 줍기 리팩터링

수정이 간단한 코드는 바로 리팩터링 하고, 오래 걸리는 코드는 메모만 남긴 후 하던 일을 끝내고 처리하자. 이를 쓰레기 줍기 리팩터링이라고 부른다.

수시로 하는 리팩터링

리팩터링을 하려고 따로 일정을 잡지 않고 이뤄지는 리팩터링을 수시로 하는 리팩터링이라고 부른다. 기능 추가 시 새로운 코드를 작성해 넣는다고 생각하지만, 뛰어난 개발자는 새 기능을 추가하기 쉽도록 코드를 ‘수정’하는 것이 기능을 빠르게 추가하는 방법이라고 생각한다. 즉 새 기능이 필요할 때마다 소프트웨어는 이를 반영하기 위해 수정된다.

오래 걸리는 리팩터링

오래 걸리는 대규모 리팩터링(ex 라이브러리 교체 작업, 컴포넌트 빼내는 작업 등등)을 팀 전체가 하는 것을 추천하지 않는다. 원하는 방향으로 조금씩 개선하는 방법을 추천한다. 예를 들어 라이브러리 교체 시 기존 것과 새것 모두 포용하는 인터페이스부터 마련한다. 기존 코드가 인터페이스를 호출하도록 만들면, 라이브러리 교체가 쉬워진다.

리팩터링 하지 말아야 할 때

코드가 지저분해도 굳이 수정할 필요 없다면 리팩터링 하지 않는다. 내부 동작을 이해해야 할 시점에 리팩터링 하는 것을 권장한다.

리팩터링 개발 프로세스

1. 자가 테스트 코드

리팩토링은 동작이 깨지지 않아야 한다. 이를 위해 오류를 빨리 잡아야 하고, 테스트가 필요하다. 리팩터링을 위해 자가 테스트 코드를 마련해야 한다. 테스트 코드는 리팩터링을 돕고 새 기능 추가도 안전하게 진행하도록 도와준다. 견고한 테스트는 리팩터링 과정에서 생길 버그를 줄여준다.

2. 지속적 통합

개발 시 기능마다 브랜치를 따로 만드는 경우가 있다. 독립 브랜치로 작업하는 기간이 길어질수록 작업 결과를 마스터 브랜치로 통합이 어려워진다. 브랜치의 통합 주기를 짧게 관리해야 한다. 자주 마스터 브랜치와 통합하면 다른 브랜치들과의 차이가 크게 벌어지는 브랜치가 없어져서 머지의 복잡도를 낮출 수 있다.

리팩터링시에 각 팀원이 다른 사람의 작업을 방해하지 않아야 한다. 리팩터링 할 때 지속적 통합을 권장하는 이유이다. 지속적 통합을 통해 리팩터링 한 결과가 다른 팀원의 작업에 문제를 일으키면 즉시 알아낼 수 있다.

코드스멜

어떤 코드를 리팩터링 해야 할지 알아야 한다. 책의 저자는 리팩터링이 필요한 코드들에 일정한 패턴이 있다고 설명하고 있으며 이를 코드 스멜이라고 부른다. 코드 스멜은 리팩터링 하면 해결할 수 있다고 말한다. 책의 저자가 설명한 코드 스멜을 요약해 보았다.

1. 기이한 이름

변수, 함수, 클래스명만 잘 지어도 나중에 문맥을 파악하느라 헤매는 시간을 절약할 수 있다. 이름이 애매하다면 설계에 문제가 숨어 있을 가능성이 높다. 이름을 장 정리해 코드를 잘 파악하도록 하자.

2. 중복 코드

똑같은 코드 구조가 여러 곳에서 반복된다면 하나로 통합하자.

public class DuplicateCodeExample {

    // 주문 생성 시 공통으로 사용하는 로깅 코드
    public void createOrder(String orderId, double amount) {
        // 중복된 로깅 코드
        System.out.println("START: 주문 생성");
        System.out.println("Order ID: " + orderId);
        System.out.println("Amount: " + amount);
        System.out.println("END: 주문 생성");
        // 주문 생성 로직 ...
    }
    
    // 주문 취소 시도 동일한 로깅 코드가 중복됨
    public void cancelOrder(String orderId) {
        // 중복된 로깅 코드
        System.out.println("START: 주문 취소");
        System.out.println("Order ID: " + orderId);
        System.out.println("END: 주문 취소");
        // 주문 취소 로직 ...
    }
    
    // 위의 로깅 코드를 별도의 메서드로 추출하여 중복 제거가 필요함
    public void log(String action, String orderId, Double amount) {
        System.out.println("START: " + action);
        System.out.println("Order ID: " + orderId);
        if(amount != null) {
            System.out.println("Amount: " + amount);
        }
        System.out.println("END: " + action);
    }
}

위 예시처럼 로깅이 중복된다면 별도의 메서드로 추출하자.

3. 긴 함수

좋은 코드를 보면 연산하는 부분이 없어 보인다. 코드가 끝없이 위임하는 방식으로 작성되어 있기 때문이다. 짧은 함수를 사용하면 코드를 이해하고, 공유하고, 선택하기 쉬워진다.

함수를 짧게 만들기 위해 함수 이름을 잘 지어야 하고, 함수 이름을 잘 짓적극적으로 함수를 쪼개야 한다. 함수 이름은 동작 방식이 아닌 ‘의도’가 드러나게 짓는다.(how가 아닌 what으로 짓는다.) 함수 이름에 코드 목적을 드러내야 한다.

public class Order {
    private List<Item> items;

    public boolean isEligibleForFreeShipping() {
        int total = 0;
        for (Item item : items) {
            total += item.getPrice();
        }
        return total >= 50000;
    }
}

위 코드의 함수를 나누면 다음과 같아진다.

public class Order {
    private List<Item> items;

    public boolean isEligibleForFreeShipping() {
        return totalAmount() >= freeShippingThreshold();
    }

    private int totalAmount() {
        return items.stream()
                    .mapToInt(Item::getPrice)
                    .sum();
    }

    private int freeShippingThreshold() {
        return 50000;
    }
}

4. 긴 매개변수 목록

매개변수 목록이 길어지면 이해하기 어려울 때가 많다. 매개변수를 객체로 만들거나 여러 함수를 클래스로 묶자.

// 매개변수가 많다.
public void sendEmail(String to, String subject, String body, String from, String replyTo)

//다음과 같이 줄이자.
public void send(EmailMessage message)

5. 전역 데이터

전역 데이터는 코드베이스 어디에서든 건드릴 수 있고 값을 누가 바꿨는지 찾아낼 메커니즘이 없다. 대표적인 전역 데이터 형태는 전역 변수, 클래스 변수, 싱글톤이 있다.

public class AppConfig {
    public static String environment = "dev";
}

...

if (AppConfig.environment.equals("prod")) {
    // 중요한 로직 실행
}

...

AppConfig.environment = "prod"; // 갑자기 환경이 바뀌면 문제가 발생할 수 있다.

6. 가변 데이터

데이터를 변경하면 예상하지 못한 버그로 이어지는 경우가 종종 있다. 코드 다른 곳에서 다른 값을 사용한다는 생각을 하지 못한 채 수정하면 프로그램이 오작동한다. 함수형 언어를 쓴다면 데이터의 불변성을 보장하지만 대부분 프로그램 언어는 변수 값을 바꾸는 것을 지원한다. 앞에서 봤던 전역 데이터와 비슷한 경우이다.

7. 뒤엉킨 변경

뒤엉킨 변경이란 단일 책임 원칙이 지켜지지 않을 때 발생한다. 하나의 모듈이 서로 다른 이유로 인해 변경되는 일이 많을 때 발생한다.

예를 들어 데이터베이스가 추가될 때 함수 세 개를 바꿔야 하고, 금융 상품이 추가될 때마다 다른 함수 네 개를 바꿔야 하는 모듈이 발생했다면 뒤엉킨 변경이 발생했다는 뜻이다.

8. 산탄총 수술

코드를 변경할 때마다 자잘하게 수정해야 하는 클래스가 많을 때 산탄총 수술이 발생한다. 변경할 부분이 코드 전반에 퍼져있는 경우이다.

아래 예시를 보면 고객 관련 기능이 여러 곳에 흩어져 있다. 고객 코드를 변경해야 할 때 여러 클래스를 고쳐야 한다.

public class Customer {
    private String name;
    private String address;
    private String phoneNumber;

    public void printName() {
        System.out.println("Customer Name: " + name);
    }

    public void printAddress() {
        System.out.println("Customer Address: " + address);
    }

    public void printPhoneNumber() {
        System.out.println("Customer Phone: " + phoneNumber);
    }
}

public class Invoice {
    private Customer customer;

    public void printInvoice() {
        System.out.println("INVOICE");
        customer.printName();
        customer.printAddress(); // 이곳도 수정 대상
        // ...
    }
}

public class ShippingLabel {
    private Customer customer;

    public void printLabel() {
        System.out.println("SHIPPING LABEL");
        customer.printName();    // 이곳도 수정 대상
        customer.printAddress(); // 이곳도 수정 대상
        // ...
    }
}

다음과 같이 고객 관련 기능을 하나로 묶어야 한다.

public class Customer {
    private String name;
    private String address;
    private String phoneNumber;

    public String getName() {
        return name;
    }

    public String getAddress() {
        return address;
    }

    public String getPhoneNumber() {
        return phoneNumber;
    }

    public String getContactInfo() {
        return "Customer Name: " + name + "\\nCustomer Phone: " + phoneNumber;
    }

    public String getFullAddressLabel() {
        return "Customer Address: " + address;
    }
}

Customer 클래스가 변경되어도 Invoice와 ShippingLabel 클래스는 변경하지 않아도 된다.

public class Invoice {
    private Customer customer;

    public void printInvoice() {
        System.out.println("INVOICE");
        System.out.println(customer.getContactInfo());
        System.out.println(customer.getFullAddressLabel());
    }
}

public class ShippingLabel {
    private Customer customer;

    public void printLabel() {
        System.out.println("SHIPPING LABEL");
        System.out.println(customer.getContactInfo());
        System.out.println(customer.getFullAddressLabel());
    }
}

9. 기능 편애

같은 모듈에 있는 상호작용은 늘리고, 다른 모듈과의 상호작용은 최소로 줄여야 한다. 기능 편애는 어떤 함수가 자기가 속한 모듈의 함수나 데이터보다 다른 모듈의 함수나 데이터와 상호작용할 일이 많을 때 발생한다.

아래 예시를 보자. generateReport()는 CustomerReport 클래스에 있지만, 실제로는 Customer 객체의 필드를 거의 다 사용한다. 이 메서드는 사실상 Customer에 더 관심이 많다.

public class Customer {
    private String name;
    private String address;
    private int loyaltyPoints;

    public String getName() {
        return name;
    }

    public String getAddress() {
        return address;
    }

    public int getLoyaltyPoints() {
        return loyaltyPoints;
    }
}

public class CustomerReport {

    public String generateReport(Customer customer) {
        StringBuilder report = new StringBuilder();
        report.append("Name: ").append(customer.getName()).append("\\n");
        report.append("Address: ").append(customer.getAddress()).append("\\n");
        report.append("Loyalty Points: ").append(customer.getLoyaltyPoints()).append("\\n");

        return report.toString();
    }
}

10. 데이터 뭉치

데이터 항목 서너 개가 항상 함께 뭉쳐 다닐 때 데이터 뭉치라고 부른다. 서로 항상 같이 다니는 데이터들이 여러 클래스나 메서드에 반복해서 나타날 때 발생한다. 몰려다니는 데이터는 따로 클래스를 추출하는 형태로 묶는 방법을 권장한다.

다음 예제를 보면 customerName, customerAddress, customerPhone이 항상 같이 호출된다.

public class Invoice {
    public void printInvoice(String customerName, String customerAddress, String customerPhone) {
        System.out.println("Invoice for: " + customerName);
        System.out.println("Address: " + customerAddress);
        System.out.println("Phone: " + customerPhone);
    }
}

public class ShippingLabel {
    public void printLabel(String customerName, String customerAddress, String customerPhone) {
        System.out.println("Ship to: " + customerName);
        System.out.println(customerAddress);
        System.out.println("Contact: " + customerPhone);
    }
}

다음과 같이 하나의 클래스로 묶어야 한다.

public class CustomerInfo {
    private String name;
    private String address;
    private String phone;

    public CustomerInfo(String name, String address, String phone) {
        this.name = name;
        this.address = address;
        this.phone = phone;
    }

    public String getName() { return name; }
    public String getAddress() { return address; }
    public String getPhone() { return phone; }
}

11. 기본형 집착

기본 자료형(int, String, boolean 등)에 너무 의존하거나, 개념적으로 하나의 타입이 될 수 있는 값들을 그냥 기본형으로만 다루는 방법을 의미한다. 여러 String이나 int로 묶이는 값을 클래스로 표현하지 않고 계속 기본형으로만 다루는 코드 스멜이다.

다음 코드를 보자.

public class User {
    private String name;
    private String email;
    private String phone;

    public User(String name, String email, String phone) {
        this.name = name;
        this.email = email;
        this.phone = phone;
    }

    public boolean hasValidEmail() {
        return email.contains("@");
    }

    public boolean hasValidPhone() {
        return phone.length() == 10;
    }
}

email, phone을 기본형(String)으로 만들었다. 따라서 검증 로직이 User 클래스 안에 있게 된다.

12. 반복되는 switch문

무조건 switch문이나 if문이 있다고 다형성을 변경하는 것을 추천하지 않는다. switch문과 if문이 반복해서 나타날 때 리팩터링을 고민해 보자. 중복된 switch문은 조건절을 하나 추가할 때마다 다른 switch문들도 모두 찾아서 함께 수정해야 한다. 이럴 때 객체지향의 다형성은 반복된 switch문을 개선할 수 있게 해 준다.

13. 반복문

반복문을 사용할 때 map, filter와 같은 컬랙션을 사용해 보자. 로직을 스트림으로 처리 시 객체가 어떻게 처리되는지 이해하기 쉬워진다.

14. 성의 없는 요소

프로그래밍 언어가 제공하는 함수, 클래스, 인터페이스를 의미 없이 사용하는 코드를 성의 없는 요소라고 부른다. 클래스 안에 메서드가 1개만 있거나, 본문 코드를 그대로 쓴 것과 다를 바 없는 함수도 있다. 이런 의미 없는 프로그램 요소는 제거하자.

15. 추측성 일반화

언젠간 쓸지 몰라서 만들어 놓은 코드를 추측성 일반화라고 부른다. 확장성을 위한 파라미터지만 항상 null이라던가 사용되지 않는 추상 클래스나 인터페이스를 의미한다. 성의 없는 요소와 마찬가지로 제거하자.

16. 임시 필드

특정 상황에서만 값이 설정되고 그 외 상황에 null로 설정되는 필드를 임시 필드라고 부른다.

17. 메시지 체인

한 객체를 통해 다른 객체를 얻은 뒤 방금 얻은 객체에 다른 객체를 요청하는 식으로, 다른 객체를 요청하는 작업이 연쇄적으로 이어지는 코드를 말한다. getter가 꼬리를 물고 이어지거나 임시 변수들이 줄줄이 나열되는 코드를 의미한다. 다음이 대표적인 예시이다.

managerName = person.getDepartment().getManager().getName();

18. 중개자

어떤 클래스가 다른 객체의 메서드나 데이터를 대신 호출해 주는 역할만 할 때 그 클래스는 중개자 역할을 한다.

public class Person {
    private Department department;

    public String getManager() {
        return department.getManager();
    }
}

위 예제에서 Person은 Department의 중개자 역할을 한다. 보통 사용 시 문제가 되지 않지만 지나치면 문제가 된다. 클래스가 제공하는 메서드 중 절반이 다른 클래스에 구현을 위임하면 문제가 된다.

19. 내부자 거래

두 모듈이 서로의 내부 구현에 지나치게 의존하는 경우를 내부자 거래라고 부른다. 이런 경우 모듈 사이에 결합도가 높아진다. 결합도를 낮추고 투명하게 처리해야 한다.

보통 상속 구조에서 부모 자식 사이에 내부자 거래가 발생하는 경우가 있다. 다음은 예제 코드이다.

public class Employee {
    protected String name;
    protected double baseSalary;

    public Employee(String name, double baseSalary) {
        this.name = name;
        this.baseSalary = baseSalary;
    }

    public double calculateSalary() {
        return baseSalary;
    }
}

public class Salesman extends Employee {
    private double commission;

    public Salesman(String name, double baseSalary, double commission) {
        super(name, baseSalary);
        this.commission = commission;
    }

    @Override
    public double calculateSalary() {
        // 내부자 거래: 자식이 부모 필드에 직접 의존
        return baseSalary + commission;
    }
}

Salesman이 baseSalary를 직접 참조하고 있다.

20. 거대한 클래스

한 클래스가 많은 일을 하다 보면 필드 수가 늘어난다. 클래스에 필드가 많으면 중복 코드가 생기기 쉽다. 이런 경우 클래스를 추출하여 일부 필드를 따로 묶는 것을 권장한다.

21. 서로 다른 인터페이스의 대안 클래스

클래스 간의 인터페이스와 함수가 중복될 때 발생하는 코드 스멜이다. 공통되는 함수나 인터페이스를 슈퍼 클래스로 추출하는 방법을 권장한다.

22. 데이터 클래스

데이터 클래스란 데이터 필드와 getter/setter 메서드로만 구성된 클래스를 뜻한다. 변경하면 안 되는 필드는 setter를 제거한다. 다른 클래스에서 데이터 클래스의 getter/setter를 사용하는 메서드를 찾아서 데이터 클래스로 옮길 수 있는지 고민하는 게 좋다.

23. 상속 포기

객체지향 설계에서 상속을 잘못 사용했을 때 자주 나타나는 문제이다. 서브 클래스가 부모의 동작은 필요로 하지만 인터페이스는 따르지 않고 싶은 경우가 대표적인 예이다. 이럴 때 상속을 포기하고 위임(composition)을 사용하는 방법을 권장한다.

리팩터링 예시

리팩터링 책 1장에 리팩터링 예시가 나와있다. 코드가 js로 되어 있어 이 부분을 java로 다시 구현해 보았다. 리팩터링 예시에 나온 요구사항은 다음과 같다.

요구사항

연극 공연 데이터를 바탕으로 고객에게 청구서를 생성하는 프로그램이다.
특정 고객의 청구 내역을 출력하는 statement() 메서드를 제공한다.
연극 유형별 가격 계산을 해야 한다.
- 비극("tragedy")
  - 기본요금: 40,000원
  - 관객이 30명 초과 시, 초과 인원당 1,000원 추가
- 희극("comedy")
  - 기본요금: 30,000원
  - 관객이 20명 초과 시, 10,000원 추가 + 초과 인원당 500원 추가
  - 추가로, 모든 관객 수에 대해 1인당 300원 추가
관객이 30명을 초과하면 초과 인원만큼 포인트 추가.
희극("comedy")의 경우, 추가 보너스 포인트로 (관객 수 / 5)의 내림값을 추가.
결과 출력 포맷
- 연극 제목과 해당 공연의 총비용 (100으로 나누어 원화 변환)
- 공연별 관객 수
- 총비용 합계
- 적립 포인트 합계

코드 구현

위 요구사항을 코드로 구현해 보았다. Play와 Invoice를 담을 객체는 다음과 같이 설정했다.

@Getter
@Setter
public class Play {
    public Play(String name, String type) {
        this.name = name;
        this.type = type;
    }

    private String name;
    private String type;
}

@Getter
@Setter
public class Invoice {
    private String customer;
    private List<Performance> performances;

    public Invoice(String customer, List<Performance> performances) {
        this.customer = customer;
        this.performances = performances;
    }
}

청구서를 출력하는 statement 함수는 다음과 같이 작성했다.

public class Main {
    public static void main(String[] args) {
        Main main = new Main();
        String result = main.statement(main.getInvoice(), main.getPlays());
        System.out.println(result);
    }

    public  String statement(Invoice invoice, Map<String, Play> plays) {
        double totalAmount = 0.d;
        double volumeCredits = 0.d;
        NumberFormat numberFormat = NumberFormat.getInstance(Locale.US);

        StringBuilder result = new StringBuilder("청구 내역(고객명 : " + invoice.getCustomer() + ") \\n");

        for(Performance performance : invoice.getPerformances()) {
            Play play = plays.get(performance.getPlayId());
            double thisAmount = 0.d;

            switch (play.getType()) {
                case "tragedy":
                    thisAmount = 40000.d;
                    if(performance.getAudience() > 30) {
                        thisAmount += 1000 * (performance.getAudience() - 30);
                    }
                    break;
                case "comedy":
                    thisAmount = 30000.d;
                    if(performance.getAudience() > 20) {
                        thisAmount += 10000 + 500 * (performance.getAudience() - 20);
                    }
                    thisAmount += 300 * performance.getAudience();
                    break;
                default:
                    throw new RuntimeException("알 수 없는 장르:" + play.getType());
            }

            volumeCredits += Math.max(performance.getAudience() - 30, 0);
            if(play.getType().equals("comedy")) {
                volumeCredits += Math.floor((double) performance.getAudience() / 5);
            }

            result.append(play.getName()).append(": ").append(numberFormat.format(thisAmount / 100)).append(" ").append(performance.getAudience()).append("석 \\n");
            totalAmount += thisAmount;
        }

        result.append("총액:").append(numberFormat.format(totalAmount / 100)).append('\\n');
        result.append("적립 포인트:").append(volumeCredits).append("점 \\n");

        return result.toString();
    }

    private Invoice getInvoice() {
        List<Performance> performances = Arrays.asList(
                new Performance("hamlet", 55),
                new Performance("as-like", 35),
                new Performance("othello", 40)
        );

        return new Invoice("BigCo", performances);
    }

    private Map<String, Play> getPlays() {
        Map<String, Play> plays = new HashMap<>();
        plays.put("hamlet", new Play("Hamlet", "tragedy"));
        plays.put("as-like", new Play("As You Like It", "comedy"));
        plays.put("othello", new Play("Othello", "tragedy"));

        return plays;
    }
}

statement() 함수에 모든 로직이 다 들어가 있다. 요구사항이 추가되거나 변경되면 statement() 함수를 수정해야 한다. statement() 함수의 복잡도가 크기 때문에 복잡한 작업이 될 것이다. 위 함수를 리팩터링 해보겠다.

리팩터링 - statement() 함수 쪼개기

동작에 따라 함수를 추출해 보겠다. 동작에 따라 함수를 추출한다는 게 무슨 뜻일까? statement() 매서드 안에 switch 문을 보면 공연에 대한 요금을 계산하고 있다. 즉 switch문은 공연에 대한 요금을 계산하는 동작을 하고 있다. 이를 amountFor(String aPerformance)라는 함수로 추출할 것이다.

 		//함수 추출
    private double amountFor(Performance aPerformance) {
        double thisAmount = 0.d;

        switch (playFor(aPerformance).getType()) {
            case "tragedy":
                thisAmount = 40000.d;
                if(aPerformance.getAudience() > 30) {
                    thisAmount += 1000 * (aPerformance.getAudience() - 30);
                }
                break;
            case "comedy":
                thisAmount = 30000.d;
                if(aPerformance.getAudience() > 20) {
                    thisAmount += 10000 + 500 * (aPerformance.getAudience() - 20);
                }
                thisAmount += 300 * aPerformance.getAudience();
                break;
            default:
                throw new RuntimeException("알 수 없는 장르:" + playFor(aPerformance).getType());
        }
        return thisAmount;
    }

위와 같이 코드의 기능에 따라 함수를 추출할 것이다. statement() 메서드 안에 기능은 다음과 같다. 달러에 따른 가격 계산, 가격 총합 계산, 적립액 계산이다. 추출한 후 코드는 다음과 같아진다.

public class Main {
    public String statement(Invoice invoice, Map<String, Play> plays) {
        double totalAmount = 0.d;
        double volumeCredits = 0.d;

        StringBuilder result = new StringBuilder("청구 내역(고객명 : " + invoice.getCustomer() + ") \\n");

        for(Performance performance : invoice.getPerformances()) {
            volumeCredits += volumeCreditsFor(performance);
            //함수 인라인
            result.append(playFor(performance).getName()).append(": ").append(usd(amountFor(performance))).append(" ").append(performance.getAudience()).append("석 \\n");
            totalAmount += amountFor(performance);
        }

        result.append("총액:").append(usd(totalAmount)).append('\\n');
        result.append("적립 포인트:").append(volumeCredits).append("점 \\n");

        return result.toString();
    }

    //함수 추출. 달러 가격 계산
    private String usd(double aNumber) {
        NumberFormat numberFormat = NumberFormat.getInstance(Locale.US);
        return numberFormat.format(aNumber/100);
    }

    //함수 추출. 적립액 계산
    private double volumeCreditsFor(Performance performance) {
        double result = 0.d;
        result += Math.max(performance.getAudience() - 30, 0);

        if(playFor(performance).getType().equals("comedy")) {
            result += Math.floor((double) performance.getAudience() / 5);
        }
        return result;
    }

    //함수 추출. performance에서 play 객체 추출
    private Play playFor(Performance performance) {
        return plays.get(performance.getPlayId());
    }

    //함수 추출. 총합 계산
    private double amountFor(Performance aPerformance) {
        double thisAmount = 0.d;

        switch (playFor(aPerformance).getType()) {
            case "tragedy":
                thisAmount = 40000.d;
                if(aPerformance.getAudience() > 30) {
                    thisAmount += 1000 * (aPerformance.getAudience() - 30);
                }
                break;
            case "comedy":
                thisAmount = 30000.d;
                if(aPerformance.getAudience() > 20) {
                    thisAmount += 10000 + 500 * (aPerformance.getAudience() - 20);
                }
                thisAmount += 300 * aPerformance.getAudience();
                break;
            default:
                throw new RuntimeException("알 수 없는 장르:" + playFor(aPerformance).getType());
        }
        return thisAmount;
    }
}

앞에서 말한 기능에 따라 usd, volumeCreditsFor, amountFor 함수가 생성되었다. 앞에서 말한 기능을 제외하고 playFor이라는 함수가 추가로 만들어졌다. playFor 함수를 보면 변수 대신에 사용된 것을 알 수 있다.

// Play play = plays.get(performance.getPlayId());
// result.append(play.getName()) ... 
result.append(playFor(performance).getName()) ...

이를 변수 인라인하기라고 부른다.

다음은 반복문 쪼개기를 알아보겠다. 하나의 for문 안에 volumeCredits와 totalAmount를 구하는 로직이 있다. 각자 다른 기능을 하고 있기 때문에 리팩터링시 쪼개주는 것이 좋다. totalAmound와 totalVolumeCredits라는 함수로 나눠보겠다. 코드는 다음과 같다.

public class Main {
    private Map<String, Play> plays;
    private Invoice invoice;

    public  String statement(Invoice invoice, Map<String, Play> plays) {
        double totalAmount = 0.d;

        StringBuilder result = new StringBuilder("청구 내역(고객명 : " + invoice.getCustomer() + ") \\n");

        for(Performance performance : invoice.getPerformances()) {
            //함수 인라인
            result.append(playFor(performance).getName()).append(": ").append(usd(amountFor(performance))).append(" ").append(performance.getAudience()).append("석 \\n");
        }

        result.append("총액:").append(usd(totalAmount())).append('\\n');
        result.append("적립 포인트:").append(totalVolumeCredits()).append("점 \\n");

        return result.toString();
    }

    private double totalAmount() {
        double totalAmount = 0;
        for(Performance performance : invoice.getPerformances()) {
            totalAmount += amountFor(performance);
        }
        return totalAmount;
    }

    private double totalVolumeCredits() {
        double volumeCredits = 0.d;
        for(Performance performance : invoice.getPerformances()) {
            volumeCredits += volumeCreditsFor(performance);
        }
        return volumeCredits;
    }
    
    ...

한 번만 돌아도 되는 for문이 3번이나 돌게 된다. 성능이 떨어져 보일 수 있다. 책에서는 리팩터링 후 성능 개선 작업을 하라고 추천한다. 성능이 먼저인지 코드 가독성이 먼저인지는 개인적으로 고민해 볼 문제인 것 같다. 아무튼 리팩터링 작업 후 statement() 함수가 줄어든 것을 확인할 수 있다.

리팩터링 - 다형성 활용하기

조건부 로직을 다형성으로 바꿔보겠다. 코드를 보면 amountFor()와 volumeCreditsFor() 메서드가 공연료와 적립 포인트를 계산한다. 이 두 함수를 전용 클래스로 따로 옮겨보겠다. 공연 관련 데이터를 계산하는 역할을 하는 PerformanceCalculator라는 함수를 생성하겠다. 코드는 다음과 같다.

public class PerformanceCalculator {
    public PerformanceCalculator(Performance performance, Play play) {
        this.performance = performance;
        this.play = play;
    }

    private Performance performance;
    private Play play;

    public double amount(Performance performance) {
        double thisAmount = 0.d;

        switch (play.getType()) {
            case "tragedy":
                thisAmount = 40000.d;
                if(performance.getAudience() > 30) {
                    thisAmount += 1000 * (performance.getAudience() - 30);
                }
                break;
            case "comedy":
                thisAmount = 30000.d;
                if(performance.getAudience() > 20) {
                    thisAmount += 10000 + 500 * (performance.getAudience() - 20);
                }
                thisAmount += 300 * performance.getAudience();
                break;
            default:
                throw new RuntimeException("알 수 없는 장르:" + play.getType());
        }
        return thisAmount;
    }

    public double volumeCreditsFor(Performance performance) {
        double result = 0.d;
        result += Math.max(performance.getAudience() - 30, 0);

        if(play.getType().equals("comedy")) {
            result += Math.floor((double) performance.getAudience() / 5);
        }
        return result;
    }

}

statement 함수는 다음과 같이 변경된다.

public  String statement(Invoice invoice, Map<String, Play> plays) {
        double totalAmount = 0.d;

        StringBuilder result = new StringBuilder("청구 내역(고객명 : " + invoice.getCustomer() + ") \\n");

        for(Performance performance : invoice.getPerformances()) {
            performanceCalculator = new PerformanceCalculator(performance, playFor(performance));
            //함수 인라인
            result.append(playFor(performance).getName()).append(": ").append(usd(performanceCalculator.amount(performance))).append(" ").append(performance.getAudience()).append("석 \\n");
        }

        result.append("총액:").append(usd(totalAmount())).append('\\n');
        result.append("적립 포인트:").append(totalVolumeCredits()).append("점 \\n");

        return result.toString();
    }

    private double totalAmount() {
        double totalAmount = 0;
        for(Performance performance : invoice.getPerformances()) {
            totalAmount += performanceCalculator.amount(performance);
            //함수 인라인
        }
        return totalAmount;
    }

    private double totalVolumeCredits() {
        double volumeCredits = 0.d;
        for(Performance performance : invoice.getPerformances()) {
            volumeCredits += performanceCalculator.volumeCreditsFor(performance);
            //함수 인라인
        }
        return volumeCredits;
    }

    //함수 추출
    private String usd(double aNumber) {
        NumberFormat numberFormat = NumberFormat.getInstance(Locale.US);
        return numberFormat.format(aNumber/100);
    }

    //함수 추출
    private Play playFor(Performance performance) {
        return plays.get(performance.getPlayId());
    }

PerformanceCalculator를 보면 play의 타입에 따라 amount메서드와 volumeCreditsFor가 달라질 수 있다. 이를 피하기 위해 다형성을 활용하겠다. PerformanceCalculator를 상속받는 서브클래스를 준비하고 팩토리 함수를 활용해 서브 클래스를 생성하도록 하겠다.

PerformanceCalculator를 인터페이스로 만든다.

public interface PerformanceCalculator {
    double amount(Performance performance);
    double volumeCreditsFor(Performance performance);
}

PerformanceCalculator를 상속받은 TragedyCalculator와 ComedyCalculator를 만든다.

public class ComedyCalculator implements PerformanceCalculator {
    public ComedyCalculator(Performance performance, Play play) {
        this.performance = performance;
        this.play = play;
    }

    private Performance performance;
    private Play play;

    @Override
    public double amount(Performance performance) {
        double thisAmount = 30000.d;
        if(performance.getAudience() > 20) {
            thisAmount += 10000 + 500 * (performance.getAudience() - 20);
        }
        thisAmount += 300 * performance.getAudience();
        return thisAmount;
    }

    @Override
    public double volumeCreditsFor(Performance performance) {
        double result = Math.max(performance.getAudience() - 30, 0);
        result += Math.floor((double) performance.getAudience() / 5);
        return result;
    }
}

public class TragedyCalculator implements PerformanceCalculator {
    public TragedyCalculator(Performance performance, Play play) {
        this.performance = performance;
        this.play = play;
    }

    private Performance performance;
    private Play play;

    public double amount(Performance performance) {
        double thisAmount = 40000.d;
        if(performance.getAudience() > 30) {
            thisAmount += 1000 * (performance.getAudience() - 30);
        }
        return thisAmount;
    }

    public double volumeCreditsFor(Performance performance) {
        return Math.max(performance.getAudience() - 30, 0);
    }
}

이전 amount에서 switch문에 따라 해야 하는 일이 달라졌다. 새로운 장르가 추가되면 amount를 추가해야 했다. 하지만 다형성을 활용해서 그럴 필요가 없어졌다. PerformanceCalculator를 상속받은 새로운 클래스를 만들어주면 된다.

PerformanceCalculator의 서브클래스를 생성하는 생성 팩토리 메서드는 다음과 같다.

private PerformanceCalculator createPerformanceCalculator(Performance performance, Play play) {
        switch (play.getType()) {
            case "tragedy":
                return new TragedyCalculator(performance, play);
            case "comedy":
                return new ComedyCalculator(performance, play);
            default:
                throw new RuntimeException("알 수 없는 장르:" + play.getType());
        }
    }

play 타입에 따라 PerformanceCalculator를 상속받은 서브클래스의 인스턴스를 만들어 준다. Main 클래스는 다음과 같다.

public class Main {
    public static void main(String[] args) {
        Main main = new Main();
        main.plays = Main.getPlays();
        main.invoice = Main.getInvoice();
        String result = main.statement(Main.getInvoice(), Main.getPlays());
        System.out.println(result);
    }

    private Map<String, Play> plays;
    private Invoice invoice;
    private PerformanceCalculator performanceCalculator;

    public  String statement(Invoice invoice, Map<String, Play> plays) {
        double totalAmount = 0.d;

        StringBuilder result = new StringBuilder("청구 내역(고객명 : " + invoice.getCustomer() + ") \\n");

        for(Performance performance : invoice.getPerformances()) {
            performanceCalculator = createPerformanceCalculator(performance, playFor(performance));
            //함수 인라인
            result.append(playFor(performance).getName()).append(": ").append(usd(performanceCalculator.amount(performance))).append(" ").append(performance.getAudience()).append("석 \\n");
        }

        result.append("총액:").append(usd(totalAmount())).append('\\n');
        result.append("적립 포인트:").append(totalVolumeCredits()).append("점 \\n");

        return result.toString();
    }

    private double totalAmount() {
        double totalAmount = 0;
        for(Performance performance : invoice.getPerformances()) {
            totalAmount += performanceCalculator.amount(performance);
            //함수 인라인
        }
        return totalAmount;
    }

    private double totalVolumeCredits() {
        double volumeCredits = 0.d;
        for(Performance performance : invoice.getPerformances()) {
            volumeCredits += performanceCalculator.volumeCreditsFor(performance);
            //함수 인라인
        }
        return volumeCredits;
    }

    //함수 추출
    private String usd(double aNumber) {
        NumberFormat numberFormat = NumberFormat.getInstance(Locale.US);
        return numberFormat.format(aNumber/100);
    }

    //함수 추출
    private Play playFor(Performance performance) {
        return plays.get(performance.getPlayId());
    }

    private PerformanceCalculator createPerformanceCalculator(Performance performance, Play play) {
        switch (play.getType()) {
            case "tragedy":
                return new TragedyCalculator(performance, play);
            case "comedy":
                return new ComedyCalculator(performance, play);
            default:
                throw new RuntimeException("알 수 없는 장르:" + play.getType());
        }
    }

    private static Invoice getInvoice() {
        List<Performance> performances = Arrays.asList(
                new Performance("hamlet", 55),
                new Performance("as-like", 35),
                new Performance("othello", 40)
        );

        return new Invoice("BigCo", performances);
    }

    private static Map<String, Play> getPlays() {
        Map<String, Play> plays = new HashMap<>();
        plays.put("hamlet", new Play("Hamlet", "tragedy"));
        plays.put("as-like", new Play("As You Like It", "comedy"));
        plays.put("othello", new Play("Othello", "tragedy"));

        return plays;
    }
}

statement()를 Main 메서드에 만들어줬는데 InvoicePrinter라는 클래스를 생성 후 statement()를 옮기겠다. 코드는 다음과 같다.

Main 클래스

public class Main {
    public static void main(String[] args) {
        String result = new InvoicePrinter(plays(), invoice())
                .statement();
        System.out.println(result);
    }

    private static Invoice invoice() {
        List<Performance> performances = Arrays.asList(
                new Performance("hamlet", 55),
                new Performance("as-like", 35),
                new Performance("othello", 40)
        );

        return new Invoice("BigCo", performances);
    }

    private static Map<String, Play> plays() {
        Map<String, Play> plays = new HashMap<>();
        plays.put("hamlet", new Play("Hamlet", "tragedy"));
        plays.put("as-like", new Play("As You Like It", "comedy"));
        plays.put("othello", new Play("Othello", "tragedy"));

        return plays;
    }
}

InvoicePrinter 클래스

public class InvoicePrinter {
    private Map<String, Play> plays;
    private Invoice invoice;
    private PerformanceCalculator performanceCalculator;

    public InvoicePrinter(Map<String, Play> plays, Invoice invoice) {
        this.plays = plays;
        this.invoice = invoice;
    }

    public  String statement() {
        StringBuilder result = new StringBuilder("청구 내역(고객명 : " + invoice.getCustomer() + ") \n");

        for(Performance performance : invoice.getPerformances()) {
            performanceCalculator = createPerformanceCalculator(performance, playFor(performance));
            //함수 인라인
            result.append(playFor(performance).getName()).append(": ").append(usd(performanceCalculator.amount(performance))).append(" ").append(performance.getAudience()).append("석 \n");
        }

        result.append("총액:").append(usd(totalAmount())).append('\n');
        result.append("적립 포인트:").append(totalVolumeCredits()).append("점 \n");

        return result.toString();
    }

    private double totalAmount() {
        double totalAmount = 0;
        for(Performance performance : invoice.getPerformances()) {
            totalAmount += performanceCalculator.amount(performance);
        }
        return totalAmount;
    }

    private double totalVolumeCredits() {
        double volumeCredits = 0.d;
        for(Performance performance : invoice.getPerformances()) {
            volumeCredits += performanceCalculator.volumeCreditsFor(performance);
        }
        return volumeCredits;
    }

    //함수 추출
    private String usd(double aNumber) {
        NumberFormat numberFormat = NumberFormat.getInstance(Locale.US);
        return numberFormat.format(aNumber/100);
    }


    //함수 추출
    private Play playFor(Performance performance) {
        return plays.get(performance.getPlayId());
    }

    private PerformanceCalculator createPerformanceCalculator(Performance performance, Play play) {
        switch (play.getType()) {
            case "tragedy":
                return new TragedyCalculator(performance, play);
            case "comedy":
                return new ComedyCalculator(performance, play);
            default:
                throw new RuntimeException("알 수 없는 장르:" + play.getType());
        }
    }
}

[객체지향 프로그래밍] 블랙잭 카드 구현

hongyb — Sun, 9 Mar 2025 22:17:05 +0900

블랙잭 게임 만들기

https://okky.kr/questions/358197

초보 개발자에게 권장하는 객체지향 모델링 공부 방법 | OKKY Q&A

원래 다른 글타래의 답글로 적던 내용인데 다른 분들에게도 혹시 도움이 될까 싶어서 별도 글타래로 옮깁니다. 따라서 다소 맥락이 어색한 부분이 있는 점 양해부탁 드립니다. 아마도 '객체지향

okky.kr

위 글을 읽고 객체지향 프로그래밍 연습을 위해 블랙잭 게임을 만들어보게 되었습니다. 챗 지피티에게 블랙잭 룰을 물어보았고, 다음과 같이 정리했습니다.

Blackjack Game

1️⃣ 게임 기본 요구사항
✅ 카드 관련
- 카드 덱(Deck)은 52장의 카드(4개의 문양 × 13개의 값)로 구성된다.
- 카드는 랜덤하게 섞인 상태에서 게임이 시작될 때 사용된다.
- 각 카드는 특정 값(A=1, J/Q/K=10, 숫자=해당 숫자)을 가진다.
✅ 게임 시작
- 게임이 시작되면 딜러와 플레이어는 각각 2장의 카드를 받는다.
- 플레이어의 카드는 공개되며, 딜러의 카드는 1장만 공개되고 나머지 1장은 숨겨진다.
- 만약 처음 받은 2장의 카드 합이 21(블랙잭) 이면 즉시 승패가 결정된다.
    - 플레이어가 블랙잭이면 승리 (단, 딜러도 블랙잭이면 무승부)
    - 딜러가 블랙잭이고 플레이어가 블랙잭이 아니면 패배

2️⃣ 플레이어 행동 요구사항

✅ 카드 추가 요청 (Hit)
- 플레이어는 원하는 만큼 카드를 추가(Hit)할 수 있다.
- 하지만 카드 합이 21을 초과하면(Bust) 즉시 패배한다.
✅ 카드 유지 (Stand)
- 플레이어는 원하는 순간에 카드 받기를 멈출 수 있다(Stand).

3️⃣ 딜러 행동 요구사항
✅ 딜러의 카드 추가 규칙
- 모든 플레이어가 카드 추가(Hit) 또는 멈추기(Stand)를 결정한 후, 딜러의 숨겨진 카드(홀 카드)를 공개한다.
- 딜러는 16 이하의 점수일 경우 반드시 카드 한 장을 추가해야 한다.
- 딜러는 17 이상의 점수일 경우 추가 카드 없이 멈춘다.
- 딜러도 21을 초과하면(Bust) 즉시 패배하며, 플레이어가 남아 있으면 승리한다.

4️⃣ 승패 판정 요구사항
✅ 일반 승패 판정
- 플레이어가 딜러보다 높은 점수이면 승리한다.
- 플레이어와 딜러의 점수가 같으면 무승부(Push) 로 처리된다.
- 플레이어 점수가 21을 초과하면 즉시 패배하며, 딜러의 추가 행동 없이 종료된다.
✅ 블랙잭 승리 보너스
- 플레이어가 블랙잭(2장의 카드로 21)이고, 딜러는 블랙잭이 아닐 경우 배팅금의 1.5배를 받는다.

원래 ‘A’ 카드는 1 또는 11이 되지만 편의를 위해 1로 고정한 채 개발하기로 결정했습니다.

모델링

개발 전 간단하게 모델링을 해보았습니다. 다음과 같습니다.

Game 객체는 블랙잭 게임의 순서를 진행하는 역할을 맡았습니다. Dealer와 Player는 각각 딜러와 플레이어를 추상화했습니다. 두 객체 모두 딜러와 플레이어가 카드를 다루는 일을 하는 책임을 할당받았습니다. 카드 덱은 카드를 모아두고 요청에 따라 카드를 섞고 카드를 건네주는 역할을 하고 있습니다.

코드로 살펴보기

Game 객체

Game 클래스는 다음과 같이 작성했습니다.

public class Game {
    private Player player;
    private Dealer dealer;
    private Scanner sc = new Scanner(System.in);

    public Game(Player player, Dealer dealer) {
        this.player = player;
        this.dealer = dealer;
    }

    public void run() {
        System.out.println('\n' + '\n' + "Game start");

        selectTwoCards();
        if(player.getScore() == 21) {
            System.out.println("player win!!!");
            return;
        }
        hitAndStand();
        getWinner();
    }
 }

run() 메서드에서 게임이 실행됩니다. 앞서 정해둔 룰에 따라 selectTwoCards() 메서드에서 딜러와 플레이어 각각 카드 2장을 뽑고 플레이어의 점수가 21점이면 플레이어가 이긴 채로 그대로 게임이 종료됩니다. 플레이어 점수가 21점 미만이라면 카드 추가 요청(hit)과 카드 유지(stand)하는 과정을 나타내는 hitAndStand() 메서드가 실행됩니다. 이후 누가 이겼는지 결정하는 getWinner() 메서드를 실행합니다. 다음은 전체 코드입니다.

public class Game {
    private Player player;
    private Dealer dealer;
    private Scanner sc = new Scanner(System.in);

    public Game(Player player, Dealer dealer) {
        this.player = player;
        this.dealer = dealer;
    }

    public void run() {
        System.out.println('\n' + '\n' + "Game start");

        selectTwoCards();
        if(player.getScore() == 21) {
            System.out.println("player win!!!");
            return;
        }
        hitAndStand();
        getWinner();
    }

    private void getWinner() {
        if (player.getScore() > 21) {
            System.out.println("player lose!!!"); // 플레이어 점수가 21 초과 → 무조건 패배
        } else if (dealer.getScore() > 21 || player.getScore() > dealer.getScore()) {
            System.out.println("player win!!!"); // 딜러 점수가 21 초과하거나, 플레이어 점수가 더 크면 승리
        } else if (player.getScore() == dealer.getScore()) {
            System.out.println("Push");
        } else {
            System.out.println("player lose!!!"); // 나머지 경우는 플레이어 패배
        }
    }

    private void hitAndStand() {
        while (player.getScore() <= 21) {
            System.out.println("hit or stand");
            String in = sc.next();
            if(in.equals("hit")) {
                player.hit();
                System.out.println("----- cards of player -----");
                showCards(player.showCards());
                System.out.println(player.getScore());
            } else if(in.equals("stand")) {
                break;
            }
        }

        if(player.getScore() > 21) {
            return;
        }

        System.out.println("----- cards of dealer -----");
        showCards(dealer.showCards());
        dealer.hit();
    }

    private void showCards(List<Card> cards) {
        cards.forEach(System.out::println);
        System.out.println("score : " + cards.stream().mapToInt(Card::getScore).sum());
    }

    private void selectTwoCards() {
        System.out.println("----- select two cards -----");
        player.selectTwoCards();
        dealer.selectTwoCards();

        System.out.println("----- card of player -----");
        showCards(player.showCards());
        System.out.println("----- card of dealer -----");
        System.out.println(dealer.showCard());
    }
}

딜러 객체

딜러가 게임 클래스부터 받아야 하는 메시지를 정리해보았습니다. 카드 1장만 공개하기, 모든 카드 공개하기, 점수가 16 이상 나올 때까지 카드 뽑기, 점수 계산하기, 카드 2장 뽑기가 나왔습니다. 이를 반영하여 다음과 같이 인터페이스를 만들었습니다.

public interface Dealer {
    Card showCard();
    List<Card> showCards();
    void hitWhileBelowSeventeen();
    int getScore();
    void selectTwoCards();
}

구현 클래스는 다음과 같습니다.

public class DealerImpl implements Dealer {
    private CardDeck cardDeck;
    private List<Card> cardList;

    public DealerImpl(CardDeck cardDeck) {
        this.cardDeck = cardDeck;
        cardList = new ArrayList<>();
    }

    @Override
    public Card showCard() {
        return cardList.get(0);
    }

    @Override
    public List<Card> showCards() {
        return cardList;
    }

    @Override
    public void hitWhileBelowSeventeen() {
        System.out.println("--- dealer hit ---");
        while(getScore() < 17) {
            Card card = cardDeck.selectCard();
            cardList.add(card);
            System.out.println("card is " + card);
            System.out.println("current sum : " + getScore());
        }
    }

    @Override
    public int getScore() {
        return cardList.stream().mapToInt(Card::getScore).sum()
    }

    @Override
    public void selectTwoCards() {
        cardList.add(cardDeck.selectCard());
        cardList.add(cardDeck.selectCard());
    }
}

딜러가 카드와 카드덱을 참조하고 있는데 어떻게 구현하고 클래스간에 상호작용하는지 뒤에서 알아보도록 하겠습니다. 다음은 플레이어 객체를 어떻게 구현했는지 알아보겠습니다.

플레이어 객체

플레이어가 Game 객체로부터 받을 메시지는 다음과 같습니다. 카드를 모두 공개하라, 카드를 뽑아라(hit) 점수를 계산해라, 카드 2개를 뽑아라. 이 메시지를 반영하여 다음과 같이 인터페이스를 만들었습니다.

public interface Player {
    List<Card> showCards();
    void hit();
    int getScore();
    void selectTwoCards();
}

구현 클래스는 다음과 같습니다.

public class PlayerImpl implements Player {
    private CardDeck cardDeck;
    private List<Card> cardList;

    public PlayerImpl(CardDeck cardDeck) {
        this.cardDeck = cardDeck;
        cardList = new ArrayList<>();
    }


    @Override
    public List<Card> showCards() {
        return cardList;
    }

    @Override
    public void hit() {
        return cardList.stream().mapToInt(Card::getScore).sum();
    }

    @Override
    public int getScore() {
        int sum = 0;
        for(int i=0;i<cardList.size();++i) {
            sum += cardList.get(i).getScore();
        }
        return sum;
    }

    @Override
    public void selectTwoCards() {
        hit();
        hit();
    }
}

카드 객체

카드를 모양, 숫자, 점수를 프로퍼티로 갖고 있도록 추상화하였습니다. 구현한 내용은 다음과 같습니다.

public class Card {
    public Card(String shape, String number, Integer score) {
        this.shape = shape;
        this.number = number;
        this.score = score;
    }

    private String shape;
    private String number;
    private Integer score;
    public Integer getScore() {
        return score;
    }

    @Override
    public String toString() {
        return "Card{" +
                "shape='" + shape + '\'' +
                ", number='" + number + '\'' +
                '}';
    }
}

카드덱 객체

카드덱 클래스가 플레이어와 딜러로부터 받을 메시지는 ‘카드를 뽑아서 전송하라’입니다. 이에 맞춰 selectCard 메서드를 만들었습니다. 플레이어와 딜러가 같은 카드덱에 같은 인스턴스를 갖고 있도록 설계했습니다. 멀티 스레드 환경이었다면 동시성 문제가 발생했을 수 있겠지만 그렇지 않았기 때문에 동시성 처리는 따로 하지 않았습니다. 코드는 다음과 같습니다.

public class CardDeck {
    private Map<Integer, Card> cards;
    private Integer cardCount;
    Random random = new Random();

    public CardDeck() {
        this.cards = new HashMap<>();
        this.cardCount = 52;
        initializeDeck();
    }

    private void initializeDeck() {
        String[] shapes = {"♠", "♥", "♦", "♣"}; // 스페이드, 하트, 다이아몬드, 클럽
        String[] numbers = {"A", "2", "3", "4", "5", "6", "7", "8", "9", "10", "J", "Q", "K"};

        int index = 0; // 카드 고유 번호 (1~52)

        for (String shape : shapes) {
            for (String number : numbers) {
                int score = getScore(number);
                cards.put(index++, new Card(shape, number, score));
            }
        }
    }

    private int getScore(String number) {
        if (number.equals("A")) return 1; // A는 기본 11점
        if (number.equals("J") || number.equals("Q") || number.equals("K")) return 10; // J, Q, K는 10점
        return Integer.parseInt(number); // 숫자 카드 그대로 점수 사용
    }


    public Card selectCard() {
        int randomNumber = random.nextInt(cardCount);
        Card card = cards.get(randomNumber);
        cards.remove(randomNumber);
        cardCount--;
        return card;
    }
}

주목해야 할 점은 카드를 초기화하여 덱을 만드는 과정입니다.

private void initializeDeck() {
        String[] shapes = {"♠", "♥", "♦", "♣"}; // 스페이드, 하트, 다이아몬드, 클럽
        String[] numbers = {"A", "2", "3", "4", "5", "6", "7", "8", "9", "10", "J", "Q", "K"};

        int index = 0; // 카드 고유 번호 (1~52)

        for (String shape : shapes) {
            for (String number : numbers) {
                int score = getScore(number);
                cards.put(index++, new Card(shape, number, score));
            }
        }
    }

카드에 있는 모양(shapes)과 점수(numbers)를 배열로 만들어 미리 저장했습니다. 4가지 카드 모양(♠, ♥, ♦, ♣)과 13가지 카드 숫자(A, 2~10, J, Q, K)가 배열에 있어 총 52장의 숫자카드가 만들어질 예정입니다. 이후 2중 for문을 돌며 카드를 생성합니다. 여기서 인덱스는 카드 고유 번호로서 map 자료구조에서 key 값으로 활용됩니다.

느낀 점

간단한 게임 룰이지만 요구사항을 모델링하고 코드를 구현하는 과정이 결코 쉽지 않았습니다. 특히 객체 간 협력을 위해 각 객체에 적절한 책임을 부여하는 작업이 어렵게 느껴졌다. “이 역할을 이 객체가 맡는 것이 맞을까?”라는 질문이 지속적으로 떠올랐으며, 정답이 명확하지 않아 더욱 난관을 겪었습니다.

메서드를 설계할 때에는 하나의 메서드가 하나의 책임만 갖도록 노력했으며, 상위 메서드에서 도메인 로직을 다루고 하위 메서드에서 구체적인 구현을 맡기려 시도했습니다. 그러나 아직 완벽하게 만족스러운 결과를 얻지는 못했습니다 다. 좋은 코드 작성을 위해 아직 많은 훈련과 반복 학습이 필요하다는 사실을 깨달았습니다.

또한 코드를 작성하면서 람다식 활용 능력이 충분히 숙달되지 않았음을 체감했습니다. 람다식을 더욱 편리하게 사용할 수 있도록 학습과 실습이 필요하다고 느꼈습니다.

마지막으로, 함수·클래스·변수 이름을 짓는 과정에서 도메인을 충분히 반영하려 노력했으나 미흡한 부분이 있었고, 이 부분도 계속 다듬어 나가야 할 과제임을 알게 되었습니다.

https://github.com/HongYouBin/oop-blackjack-game

GitHub - HongYouBin/oop-blackjack-game

Contribute to HongYouBin/oop-blackjack-game development by creating an account on GitHub.

github.com

소프트웨어 테스트 원칙

hongyb — Sun, 10 Nov 2024 22:53:22 +0900

소프트웨어 테스트 원칙

단위 테스트

단위 테스트 : 코드의 개별 구성 요소(주로 메서드나 함수)가 올바르게 동작하는지 검증하는 테스트

단위 테스트 특집

독립적: 단위 테스트는 가능한 한 외부 종속성이나 환경의 영향을 받지 않고 개별 단위의 동작만을 검증
작은 범위: 단위 테스트는 함수, 메서드 또는 클래스와 같은 작은 단위를 테스트
자동화 가능: JUnit같은 테스트 프레임워크를 사용하여 자동화

public class Calculator {
    public int add(int a, int b) {
        return a + b;
    }
}

public class CalculatorTest {
    @Test
    void testAdd() {
        Calculator calculator = new Calculator();
        int result = calculator.add(2, 3);
        assertEquals(5, resul);
    }
}

단위 테스트 장점

높은 테스트 커버리지 : 단위 테스트는 기능 테스트로 수행하기 어렵거나 불가능한 오류 조건에 대해 쉽게 테스트할 수 있다.
팀 생산성 향상 : 대규모 어플리케이션 작업에서 단위 테스트를 사용하면 다른 컴포넌트가 준비되지 않아도 테스트 가능하다. → mock
디버깅 작업 감소 : 단위 테스트를 통해 코드 중 어디에 문제가 있는지 구체적인 부분을 알 수 있다. 애플리케이션을 일일이 디버깅할 필요가 줄어든다.
리팩터링 용이 : 리팩토링하는 과정에서 가장 중요한 것은 “결과의 변경 없이” 코드의 구조를 변경하는 것이다. 소스를 리팩터링하거나 고칠 때 오류를 만들 위험이 있다. 단위 테스트를 통해 리팩터링에 확신을 갖게 된다
기능 구현에 도움 : 단위 테스트는 코드가 독립적으로 테스트될 수 있도록 구조적 설계를 강요한다. 단위 테스트를 고려하지 않으면 테스트하기 어렵고 유지 보수하기 힘든 코드가 만들어진다.
코드 문서화 : 단위 테스트 그 자체로 API 사용 예제가 만들어진다. 테스트 코드를 작성하기만 해도 유스 케이스를 명확히 알 수 있다.
다양한 지표 제공 : 커버리지 지표 및 테스트 통과, 실패 진행사항을 추적할 수 있다.

통합 테스트

통합 테스트 : 대상 환경에서 실행 가능한 컴포넌트 간의 상호작용을 테스트

시스템의 상호작용을 통해, 단위 테스트에서는 발견하기 어려운 문제를 찾아낼 수 있다.

여러 컴포넌트가 함께 동작하는지를 확인
데이터베이스, 파일 시스템 등 외부 리소스와의 상호작용을 포함
주로 모의 객체를 사용하지 않고 실제 의존성을 테스트

상호작용	테스트 설명
객체	객체를 인스턴스화 하고 다른 객체의 메서드를 호출한다. 다른 클래스에 속한 객체 간에 어떻게 협력해서 문제를 해결할 수 있는지 확인 가능하다.
서비스	애플리케이션을 데이터베이스, 다른 외부 리소스와 함께 테스트 한다.
서브 시스템	인터페이스인 프런트엔드와 비즈니스 로직인 백엔드가 구분된 아키텍쳐를 가진 애플리케이션에서 통합 테스트 한다.

public class EmailService {
    public boolean sendEmail(String email, String message) {
        // 이메일 전송 로직 (예를 들어 실제 이메일 서버와 통신)
        return true;
    }
}

public class UserService {
    private EmailService emailService;

    public UserService(EmailService emailService) {
        this.emailService = emailService;
    }

    public boolean registerUser(String email) {
        // 사용자 등록 로직 후 이메일 전송
        return emailService.sendEmail(email, "Welcome!");
    }
}

public class UserServiceIntegrationTest {

    @Test
    void testRegisterUser() {
        // 실제 EmailService 사용, Mock 객체 사용하지 않는다
        EmailService emailService = new EmailService();
        UserService userService = new UserService(emailService);
        
        boolean result = userService.registerUser("test@example.com");
        assertTrue(result);
    }
}

시스템 테스트

시스템 테스트 : 시스템이 구체화된 요구 사항을 만족하는지 평가하기 위해 완전한 통합 환경에서 수행하는 테스트 소프트웨어가 실제 환경에서 제대로 작동하는지 확인하는 마지막 단계 중 하나이다.

시스템 테스트 목적

시스템의 종합적인 검증.
모든 모듈과 기능이 의도한 대로 작동하는지 확인.
성능, 보안, 신뢰성 등의 비기능적 요구사항도 만족하는지 확인.
의존성: 실제 데이터베이스, 네트워크, API, 파일 시스템 등 외부 리소스를 포함한 전체 환경을 설정하여 테스트합니다.

시스템 테스트 환경에서 모든 외부 시스템이 항상 사용 가능한 것은 아니기 때문에 테스트 더블이나 모의 객체를 사용한다.

테스트 더블 :

테스트 대상 객체를 대신하는 모든 대체 객체. 실제로 동작할 필요는 없고, 테스트 시에 필요한 상황을 시뮬레이션하거나 제어하기 위해 사용된다. 테스트 더블은 실제 의존성 대신 사용되므로, 테스트 환경에서 복잡한 설정이나 외부 의존성을 최소화할 수 있고, 특정 조건을 쉽게 테스

트할 수 있다.

스텁

테스트에서 사용할 수 있는 고정된 반환값이나 미리 정의된 행동을 제공
특정 입력에 대해 예상되는 출력을 반환하는 용도로 사용
외부 컴포넌트 동작을 단순화하여 미리 정해진 응답 반환

모킹

메서드 호출 여부나 호출 횟수, 호출된 인자 등을 검증
단순히 값을 반환하는 것에 그치지 않고 행동을 관찰하고, 검증

인수 테스트

인수 테스트는 애플리케이션이 사용자의 요구사항을 충족하는지, 즉 비즈니스 요구사항과 기능적 요구사항을 만족하는지 검증하는 테스트 과정. 인수 테스트는 소프트웨어가 실제로 출시되기 전에 최종 사용자가 기대한 대로 동작하는지 확인하는 마지막 단계로 볼 수 있다. → 사용자 관점

인수 테스트는 Given, When, Then 키워드를 사용하여 표현하기도 한다. Given, When, Then은 BDD(Behavior Driven Development)에서 사용하는 시나리오 기반 테스트 작성 방식의 핵심 구성 요소이다.

Given (주어진 상황) : 테스트의 초기 상태 또는 전제 조건을 설명
When (행동) : 사용자가 시스템에서 수행하는 특정 행동이나 이벤트

Then (결과) : 기대되는 결과를 설명한다. 특정 행동이 발생한 후 시스템이 어떻게 반응해야 하는지를 설명한다. 비즈니스 목표를 달성했는지 확인 가능.

[예시]

기능 : 사용자 주식 트레이드

시나리오 : 트레이드가 마감되기 전에 사용자가 판매를 요청

"Given" 나는 MSFT 주식을 100 가지고 있다. 그리고 나는 APPL 주식을 150 가지고 있다.

"When" 나는 MSFT 주식 20을 팔도록 요청했다.

"Then" 나는 MSFT 주식 80 가지고 있어야 한다. 그리고 MSFT 주식 20이 판매 요청이 실행되었어야 한다.

블랙박스 테스트 VS 화이트박스 테스트

블랙박스 테스트

블랙 박스 테스트는 시스템의 내부 상태나 동작에 대한 지식이 없을 때 수행하는 테스트다. 주로 입력과 출력에만 집중하여 시스템의 작동 여부를 확인한다. 블랙박스 테스트는 외부적인 시스템 인터페이스를 사용한다.

화이트박스 테스트

화이트박스 테스트는 소프트웨어의 내부 구조, 코드, 알고리즘을 기반으로 시스템을 테스트하는 방법. 테스트 작성자는 소프트웨어의 코드를 분석하고, 코드의 흐름이나 내부 동작을 기반으로 테스트 케이스를 설계한다. 주로 개발자가 코드의 로직과 흐름을 검증하는 데 사용한다.

장단점 비교

장점

블랙박스 테스트	화이트박스 테스트
비개발자여도 테스트 할 수 있다.	GUI가 필요하지 않다.
개발과 독립적으로 수행할 수 있다.	개발자가 제어하므로 다양한 실행 경로를 커버할 수 있다.
사용자 중심적이며, 설계 명세와 다른 부분이 무엇인지 알 수 있다.	작은 버그나 예외적인 상황에서 발생할 수 있는 결함을 찾는 데 유리하다. 특히 경계값 분석에 효과적

단점

블랙박스 테스트	화이트박스 테스트
입력할 수 있는 경우의 수 제한적	프로그래밍 지식 필요
커버되지 않은 테스트 있을 수 있다.	구현 변경시 테스트 다시 작성해야 한다.
테스트 중복 가능.	테스트와 구현 결합

빠른 사용자 피드백이 필요하거나 가능 → 블랙박스 테스트

수동으로 실행할 수 있는 테스트 스크립트나 GUI를 제공한다면 고객이 애플리케이션에 대해 직관적으로 알 수 있다.

테스트 커버리지가 필요한 경우 → 화이트박스 테스트

여러 유형의 테스트를 활용하여 코드 커버리지를 높일 수 있고, 애플리케이션을 리팩터링 하거나 개선하는 데에 유리하다.

테스트 커버리지

테스트 커버리지(Test Coverage)는 소프트웨어 테스트 과정에서 코드의 얼마나 많은 부분이 테스트되었는지를 측정하는 지표이다. 가장 기본적인 지표는 다음과 같다.

구문 커버리지 : 코드의 각 문장이 실행되었는지 측정한다. 코드 한 줄이 한 번 이상 실행된다면 충족.

public class Calculator {
    public String divide(int a) {
		    System.out.println("calculate")//1
        if (a > 0) { //2
            return "Cannot divide by zero"; //3
        }
        return String.valueOf(a); //4
    }
}

a가 음수일 시 3개의 구문만 실행 → 커버리지는 75%(3/4)

브랜치 커버리지 : 조건문(예: if-else)의 각 분기가 테스트되었는지 확인합. 코드 내 모든 분기점에서 가능한 모든 경로가 테스트되었는지 측정

public void checkNumber(int num) {
    if (num < 0) { //분기 1
        ...
    } else if(num == 0) { //분기 2
        ...
    } else { //분기 3
			  ...
    }
}

조건 커버리지 : 각 개별 조건이 true, false 값을 가질 수 있도록 테스트하는 것을 목표로 한다.

public boolean isValid(int age, boolean isMember) {
    return age > 18 && isMember;
}

age = 20, isMember = true: 두 조건 모두 true

age = 15, isMember = true: 첫 번째 조건 false, 두 번째 조건 true

age = 20, isMember = false: 첫 번째 조건 true, 두 번째 조건 false

age = 15, isMember = false: 두 조건 모두 false

얼마만큼의 코드를 자동화한 단위 테스트로 계산해야 할까? 대답할 필요조차 없다. 모조리 다 해야 한다. 모. 조. 리! 100% 테스트 커버리지를 권장하냐고? 권장이 아니라 강력히 요구한다. 작성한 코드는 한 줄도 빠짐없이 전부 테스트해야 한다. 군말은 필요 없다. ― 클린 코더 (로버트 마틴 저)

소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다. 그 밖의 매우 중요하다 할 수 있는 기능도 모두 이러한 기본적인 목적을 뒷받침하는 데 불과하다. - 에릭 에반스

높은 테스트 커버리지가 필요한 경우

핵심 기능: 핵심적인 비즈니스 로직이나 보안 관련 코드
오픈 소스나 공공 API: 많은 사용자나 다른 개발자가 사용하는 라이브러리나 API는 높은 테스트 커버리지 필요.
복잡한 코드: 복잡한 로직이 많을수록 테스트 커버리지를 높이는 것이 유리 → 복잡한 부분일수록 예상치 못한 문제들이 발생할 가능성이 높다.

테스트는 중요한 곳에 집중해야 하고 개발자에게 큰 문제가 없다는 확신을 주어야 한다. 복잡성이 높은 곳에 인지 부하로 인해 버그가 생길 가능성이 높고, 비즈니스 로직이 존재하는 도메인 모델 혹은 알고리즘에 문제가 생기면 단순히 시스템 오류로 끝나지 않는다.

테스트하기 쉬운 코드

public API 테스트

퍼블릭 API는 외부 코드나 시스템에서 의존하고 있을 가능성이 크다. API가 변경되거나 잘못 작성되면 해당 API를 사용하고 있는 모든 외부 코드가 제대로 작동하지 않을 수 있다. 변하지 않고 오류 없는 public 메서드를 만든 후 철저한 테스트를 통해 위험을 방지해야 한다.

의존성 줄이기

클래스 내에서 새로운 객체를 직접 또는 간접적으로 인스턴스화하면, 그 클래스는 해당 객체에 강하게 결합되어(타이트 커플링) 의존성이 커진다. 이는 클래스 내부에서 직접 객체를 생성하므로, 테스트 시 해당 객체를 모킹(Mock)하거나 대체하기 어려워진다.

class Vehicle {
    Driver d;
    boolean hadDriver = true;

    Vehicle(Driver d) {
        this.d = d;
    }

    private void setHadDriver(boolean hasDriver) {
        this.hadDriver = hasDriver;
    }
}

간단한 생성자 만들기

테스트 단계

테스트할 클래스 인스턴스화
클래스를 특정 상태로 설정
작업을 수행
클래스 상태 검증

생성자가 없다면 1번, 2번을 같이 수행하게 된다. 테스트 케이스에서 생성자에 클래스를 미리 정의하면 다양한 상태를 만들기 힘들다.

이를 해결하기 위해 클래스를 특정 상태로 설정하는 것은 별도의 작업으로 분리해야 한다. 테스트 케이스에서 동일한 객체를 여러 시나리오로 재사용할 때, setter를 이용해 객체의 일부 상태만 변경하면서 다양한 경우를 테스트할 수 있다. 이 방식은 객체를 매번 새로 생성하지 않으면서 테스트 코드의 중복을 줄이는 데 도움을 준다.

class Car {
    private int maxSpeed;
    
    public void setMaxSpeed(int maxSpeed) {
        this.maxSpeed = maxSpeed;
    }
}

데메테르 법칙 따르기

데메테르 법칙(Law of Demeter)은 객체 지향 설계에서 "잘 알지 못하는 객체와 상호작용하지 말라"는 원칙을 의미한다. 객체는 자신이 직접적으로 알고 있는 객체(예: 자신의 필드, 메서드 파라미터, 메서드에서 생성된 객체)와만 상호작용해야 하며, 메서드 체이닝이나 연속적인 접근을 통해 다른 객체의 내부 객체를 직접 접근하는 것을 피해야 한다.

데메테르 법칙의 구체적인 규칙

객체는 자기 자신(this)과만 상호작용해야 한다.
객체는 자신의 필드(인스턴스 변수)와 상호작용할 수 있다.
객체는 자신의 메서드에서 생성된 객체와 상호작용할 수 있다.
객체는 메서드의 매개변수로 전달된 객체와 상호작용할 수 있다.
객체는 이러한 객체들의 직접적인 메서드만 호출할 수 있다. 즉, 객체는 "친구의 친구"에게 메시지를 전달하지 않는다.

public class Order {
    private Customer customer;

    public Customer getCustomer() {
        return customer;
    }
}

public class Customer {
    private Address address;

    public Address getAddress() {
        return address;
    }
}

public class Address {
    private String city;

    public String getCity() {
        return city;
    }
}

// 데메테르 법칙 위반 코드
public class OrderService {
    public void printCustomerCity(Order order) {
        // Order -> Customer -> Address -> city에 접근
        System.out.println(order.getCustomer().getAddress().getCity());
    }
}

데메테르 법칙 위반 예시 테스트. Address, Customer, Order를 모두 모킹해야 하므로 좋지 않은 테스트이다.

public class OrderServiceTest {

    @Test
    public void testPrintCustomerCity() {
        // 여러 단계의 객체 모킹 필요
        Address mockAddress = mock(Address.class);
        when(mockAddress.getCity()).thenReturn("New York");

        Customer mockCustomer = mock(Customer.class);
        when(mockCustomer.getAddress()).thenReturn(mockAddress);

        Order mockOrder = mock(Order.class);
        when(mockOrder.getCustomer()).thenReturn(mockCustomer);

        OrderService orderService = new OrderService();
        orderService.printCustomerCity(mockOrder);

        verify(mockAddress).getCity();
    }
}

숨은 의존성과 전역 상태 피하기

숨은 의존성 : 코드에서 명시적으로 드러나지 않지만 내부적으로 다른 객체나 모듈에 의존하는 경우를 뜻한다. 숨은 의존성은 객체가 어떤 다른 객체나 리소스에 의존하고 있는지를 알기 어렵게 만든다. → 모킹 어려워진다.

OrderRepository를 모킹하기 어려워진다.

public class OrderService {
    // 숨은 의존성: OrderRepository를 직접 생성
    private OrderRepository orderRepository = new OrderRepository();

    public Order findOrderById(int id) {
        return orderRepository.findById(id);
    }
}

전역 상태 : 애플리케이션에서 여러 곳에서 공유되고 접근 가능한 상태(예: 전역 변수, 싱글톤 객체, 스태틱 필드 등)를 의미

전역 객체에만 접근을 공유하는 게 아니라 전역 객체가 참조하는 모든 객체를 공유하는 문제점 발생한다.

class Reservation {
    public void makeReservation() {
        Manager manager = Manager.getManager();
        ..
    }
}

제너릭 메서드 사용하기

정적 코드(static)을 사용 시 다형성을 활용하지 못하면 애플리케이션과 테스트에 코드를 재사용하지 않게 된다. 이런 상황은 애플리케이션과 테스트에서 코드 중복이 생길 수 있어 피하는 게 좋다.

제네릭 메서드를 사용하면 하나의 테스트 메서드로 여러 타입을 동시에 테스트할 수 있어, 테스트 코드의 양도 줄고 중복 테스트를 피할 수 있습니다.

//제너릭 사용 X -> 코드 중복
public class Utils {
    public static String getFirstString(List<String> list) {
        return list.isEmpty() ? null : list.get(0);
    }

    public static Integer getFirstInteger(List<Integer> list) {
        return list.isEmpty() ? null : list.get(0);
    }
}

//제너릭 사용
public class Utils {
    public static <T> T getFirstElement(List<T> list) {
        return list.isEmpty() ? null : list.get(0);
    }
}

@Test
public void testGetFirstElement() {
    List<String> stringList = Arrays.asList("apple", "banana", "cherry");
    List<Integer> integerList = Arrays.asList(1, 2, 3);

    // 같은 메서드를 다양한 타입으로 테스트 가능
    assertEquals("apple", Utils.getFirstElement(stringList));
    assertEquals(Integer.valueOf(1), Utils.getFirstElement(integerList));
}

상속보다는 합성

상속은 클래스 간 강한 결합을 유발한다. 반면 합성(composition)은 객체의 기능을 독립된 구성 요소로 분리하여 주입할 수 있기 때문에, 필요한 부분만을 쉽게 교체하거나 모의(mock)할 수 있어 테스트가 더 유연해진다.

상속

// Engine 클래스
public class Engine {
    public void start() {
        System.out.println("엔진이 시동을 겁니다.");
    }
}

// Car 클래스 (Engine을 상속)
public class Car extends Engine {
    public void drive() {
        System.out.println("자동차가 주행합니다.");
    }
}

합성

// Engine 클래스
public class Engine {
    public void start() {
        System.out.println("엔진이 시동을 겁니다.");
    }
}

// Car 클래스 (Engine을 합성)
public class Car {
    private Engine engine;

    public Car() {
        this.engine = new Engine();
    }

    public void startCar() {
        engine.start();
        System.out.println("자동차가 시동을 겁니다.");
    }

    public void drive() {
        System.out.println("자동차가 주행합니다.");
    }
}

// 테스트 코드에서 Mock 엔진 주입. 독립적인 테스트 가능하다.
class CarTest {
    @Test
    void testStart() {
        Engine mockEngine = Mockito.mock(Engine.class); // Mock 객체 생성
        Car car = new Car(mockEngine);
        car.start();
        verify(mockEngine).start(); // 엔진의 start 메서드가 호출되었는지 검증
    }
}

분기문보다 다형성 활용

분기문이 많으면 클래스가 복잡해지고 인스턴스화가 어려울 수 있다. 다형성을 사용하면 객체를 인터페이스나 부모 클래스를 통해 주입받기 때문에, 테스트할 때 쉽게 모의 객체로 교체할 수 있다.

코드가 다음과 같을 때 테스트 코드를 알아보자.

public class DocumentPrinter {
    public void printDocument(Document document) {
        document.pringDocument();
    }
}

public abstract class Document {
    public abstract void printDocument();
}

public class WordDocument extends Document {
    @Override
    public void printDocument() {
        printWORDDocument();
    }
}

public class PDFDocument extends Document {
    @Override
    public void printDocument() {
        printPDFDocument();
    }
}

테스트 코드는 다음과 같다.

public class DocumentPrinterMockTest {

    @Test
    void testPrintWordDocumentWithMock() {
        Document wordDocument = Mockito.mock(WordDocument.class); 
        DocumentPrinter printer = new DocumentPrinter();
        printer.printDocument(wordDocument);
      
        verify(wordDocument, times(1)).printDocument();
    }

    @Test
    void testPrintPDFDocumentWithMock() {
        Document pdfDocument = Mockito.mock(PDFDocument.class);
        DocumentPrinter printer = new DocumentPrinter();
        printer.printDocument(pdfDocument);
    
        verify(pdfDocument, times(1)).printDocument();
    }
}

결론 : 좋은 코드는 테스트 하기 쉽다.

좋은 코드는 “변경하기 쉬운”이라는 형용사를 가지고 있는데요.
이 의미는 약한 결합도를 가지고 있는 코드를 뜻하며 반대로 강결합이 되어있는 코드는 유지비용이 증감되어 저품질코드로 분류됩니다.

그렇다면 강결합으로 이루어진 코드를 테스트하기 쉬울까요?

당연히 매우 어렵습니다.

외부의 영향을 받거나 내부적으로 의존성을 가지고 있는 코드는 변경에 유연하게 대응하지 못하고 재사용하기 어려운 코드들입니다.

그렇기 때문에 테스트를 작성하기 어려운 코드가 만들어지는 것입니다.

그렇다고 테스트하기 쉬운 코드가 모두 좋은 코드가 되는 것은 아닙니다. 하지만 저희는 테스트를 작성하면서 하나의 좋은 코드의 지표를 아래와 같이 세울 수 있게 됩니다.

“만약 내가 작성한 코드가 테스트하기 어려운 코드라면 냄새나는 코드일 가능성이 높아.”

자료출처 : https://tech.inflab.com/20230404-test-code/#네번째-좋은-코드는-테스트하기-쉽다

단일 책임 원칙 : 테스트 작성 단순
의존성 주입 : mock 객체 쉽게 사용 가능
의존성 최소화 : 의존성이 적어질수록 테스트 쉬워진다.

TDD

TDD는 소프트웨어 개발 방법론 중 하나로, 테스트를 먼저 작성한 후에 그 테스트를 통과하는 코드를 작성하는 방식이다. 코드를 작성하기 전에 먼저 해당 코드가 어떻게 동작해야 할지를 테스트로 정의하는 개발 프로세스이다.

TDD 기본 싸이클

Red (실패하는 테스트 작성)
- 구현하려는 기능에 대한 테스트 코드를 작성
- 테스트가 실패하는 것을 확인함으로써, 아직 해당 기능이 없다는 것을 명확하게 인지
```
@Test
void testAdd() {
    Calculator calc = new Calculator();
    assertEquals(5, calc.add(2, 3));  // 아직 add 메서드가 구현되지 않음.
}
```

Green (테스트 통과를 위한 최소한의 코드 작성)
- 테스트를 통과시키기 위해 필요한 최소한의 코드를 작성
- 코드를 반복적으로 실행 후, 테스트가 통과되도록 작성
```
public class Calculator {
    public int add(int a, int b) {
        return a + b;  // 테스트 통과를 위한 간단한 코드 작성
    }
}
```

Refactor (리팩토링)
- 중복 제거하거나, 가독성이나 성능을 개선하는 등 더 나은 코드 구조로 리팩토링.
- 리팩토링 후에도 테스트가 여전히 통과하는지 확인하여, 기능이 깨지지 않았음을 보장

TDD의 장점

높은 코드 품질:개발자는 기능에 대한 명한 요구 사항을 이해하고 이를 테스트할 수 있는 구조로 코드를 작성하게 된다.
안정적인 리팩토링 : 리팩토링을 통해 코드의 구조를 개선할 때, 테스트 코드가 기능의 정상 동작을 보장해 주기 때문에 기능이 손상되지 않은 상태에서 안전하게 코드를 개선할 수 있다
더 나은 설계: TDD를 사용하면 테스트 가능한 코드를 작성해야 하기 때문에 자연스럽게 의존성을 줄이고 모듈화된 설계로 이어진다

TDD 단점

초기 개발 속도 저하: 코드를 작성하기 전에 테스트부터 작성해야 하기 때문에, 초기 개발 속도는 느려질 수 있다
테스트 유지보수 비용 증가: 기능이 변화할 때마다 테스트 코드를 유지보수해야 한다. 추가적인 비용 발생 가능
잘못된 테스트 설계 위험: 테스트 설계를 잘못하거나, 지나치게 구현에 의존적인 테스트를 작성하면 리팩토링 시 유지 보수 비용 증가.

BDD

BDD는 비즈니스 요구 사항을 기반으로 사용자의 동작을 정의하고, 그 동작에 대한 테스트를 작성하는 방식이다.

주로 Given-When-Then 패턴을 사용

Given: 시스템의 초기 상태(상황, 전제 조건)
When: 사용자가 시스템에 취하는 행동(액션)
Then: 그 행동에 대한 기대 결과(결과)

BDD와 TDD

테스트 케이스를 작성하는 데는 시간과 비용이 많이 들어가지만, 이미 작성된 요구사항이나 기획서를 기반으로 테스트 케이스를 작성하면 이 비용을 줄일 수 있다. BDD와 TDD는 상호 배타적인 관계가 아니라 상호 보완적인 관계이다. 프로젝트에서 BDD를 통해 시나리오를 검증하고, TDD를 통해 그 시나리오에 사용되는 각 모듈을 검증하는 방식이 효과적이다.

개발 주기 내에서 테스트하기

개발
- 개발자의 작업 장소
- SCM에 여러번 커밋한다.
- 개발 단계에서 비즈니스 로직에 대해 단위 테스트를 실행한다.

통합 단계
- 모든 컴포넌트 포함하여 애플리케이션 빌드
- 자동화된 빌드를 수행하여 애플리케이션을 패키징하는 단계이다.
- 단위 테스트와 기능 테스트 수행. 기능 테스트는 블랙박스 테스트로 실행
- 시스템 몇몇 요소가 빠져있어 일부 테스트만 실행

인수 단계, 부하 테스트 단계
- 부하 테스트 : 애플리케이션에 부하 주어 적절하게 확장하는지 확인
- 인수 단계 : 고객이 시스템을 인수하는 단계
- 통합 단계와 동일한 테스트 수행

예비 운영
- 실제 운영 배포 직전 수행하는 마지막 검증 단계
- 인수 단계에서 실행한 테스트 실행하는 것 권장

자료출처

https://tv.kakao.com/channel/3693125/cliplink/414004682

https://velog.io/@kimyj1234/TDD-BDD#bdd-기본-패턴

https://blog.wakmusic.xyz/tdd-vs-bdd-c738b507930f

https://yozm.wishket.com/magazine/detail/2471/

[헤드퍼스트 디자인패턴] 프록시 패턴

hongyb — Fri, 30 Aug 2024 01:27:45 +0900

프록시 패턴을 알아보자.

프록시 패턴

프록시 패턴

특정 객체로의 접근을 제어하는 대리인(특정 객체를 대변하는 객체)을 제공한다. 프록시 패턴은 실제 객체에 대한 접근을 제어하고, 추가적인 기능(로깅, 캐싱, 접근 제어 등)을 제공할 때 유용하다.

프록시 패턴 개념과 목적

프록시 패턴은 실제 객체와 그 객체의 대리자 역할을 하는 객체(프록시 객체) 사이에 인터페이스를 정의하여, 클라이언트가 직접 실제 객체에 접근하지 않고, 프록시 객체를 통해 접근하도록 만든다. 프록시 객체는 클라이언트의 요청을 실제 객체로 전달하고, 그 결과를 클라이언트에게 반환하는 역할을 한다.

프록시 패턴의 주요 목적은 다음과 같다.

접근 제어: 클라이언트가 실제 객체에 접근하기 전에 특정 조건을 확인하거나, 특정 사용자의 접근을 제한할 수 있다.
지연 초기화(Lazy Initialization): 실제 객체의 생성이 비용이 많이 드는 경우, 필요할 때까지 객체 생성을 지연시킬 수 있다.
로깅 및 감사(Auditing): 객체에 대한 모든 접근이나 요청을 기록할 수 있다.
원격 프록시(Remote Proxy): 실제 객체가 다른 주소 공간(예: 원격 서버)에 있는 경우, 클라이언트는 로컬 프록시를 통해 원격 객체에 접근할 수 있다.
캐싱(Caching): 결과를 캐싱하여 동일한 요청에 대해 빠른 응답을 제공한다.

프록시 패턴은 다양한 유형으로 나눌 수 있으며, 각 유형은 특정 목적을 위해 사용된다.

가상 프록시 (Virtual Proxy):
- 실제 객체의 생성 비용이 높을 때 사용된다. 프록시가 실제 객체의 생성을 지연시켜, 필요할 때까지 생성하지 않도록 한다.
- 예: 이미지 뷰어에서 이미지를 표시할 때, 이미지가 실제로 필요한 순간까지 로드를 지연시킨다.
원격 프록시 (Remote Proxy):
- 실제 객체가 다른 주소 공간(네트워크 상의 원격 서버)에 있을 때 사용된다.
- 클라이언트는 로컬 프록시를 통해 원격 객체에 접근하고, 원격 호출을 통해 작업을 수행한다.
- 예: 분산 객체 시스템에서, 클라이언트는 원격 서버의 객체를 로컬 프록시로 호출할 수 있다.
보호 프록시 (Protection Proxy):
- 실제 객체에 대한 접근을 제한할 때 사용된다.
- 프록시는 특정 사용자나 클라이언트의 권한을 확인하고, 권한이 없는 경우 접근을 거부할 수 있다.
- 예: 관리자가 아닌 사용자가 특정 파일을 삭제하지 못하도록 보호 프록시를 사용할 수 있다.
스마트 프록시 (Smart Proxy):
- 실제 객체에 대한 접근 전에 추가 작업을 수행하는 프록시.
- 예: 실제 객체의 메서드를 호출하기 전에 로깅, 인증, 캐싱, 원격 호출 처리 등을 수행할 수 있다.

프록시 패턴 클래스 다이어그램 및 구현

프록시 패턴 클래스 다이어그램은 다음과 같다.

Proxy와 RealSubject 모두 Subject 인터페이스를 구현한다. 이러면 어떤 클라이언트에서든 프록시를 주제와 똑같은 식으로 다룰 수 있다. RealSubject는 진짜 작업을 대부분 처리하는 개게이다.

Proxy는 그 객체로의 접근을 제어하는 객체이다. Proxy에는 진짜 작업을 처리하는 객체의 레퍼런스가 들어있다. 진짜 객체가 필요하면 그 레퍼런스를 사용해 요청을 전달한다.

Proxy에서 RealSubject의 인스턴스를 생성하거나, 그 객체의 생성 과정에 관여하는 경우가 많다.

위 클래스 다이어그램을 참고해서 간단한 Proxy 예제를 만들어보겠다. 가상 프록시를 구현한 예제이다.

다음과 같이 Subject 인터페이스를 정의한다.

public interface Image {
    void display();
}

RealSubject를 정의한다. Subject를 상속받고 오버라이드를 해야 한다.

public class RealImage implements Image {
    private String fileName;

    public RealImage(String fileName) {
        this.fileName = fileName;
        loadFromDisk(fileName);
    }

    private void loadFromDisk(String fileName) {
        System.out.println("Loading " + fileName);
    }

    @Override
    public void display() {
        System.out.println("Displaying " + fileName);
    }
}

Proxy 객체를 정의한다. 마찬가지로 Subject를 상속받아야 하며 RealSubject의 레퍼런스가 들어있다. 클라이언트 요청이 오면 진짜 객체의 레퍼런스를 사용해 요청을 전달한다.

public class ProxyImage implements Image {
    private RealImage realImage;
    private String fileName;

    public ProxyImage(String fileName) {
        this.fileName = fileName;
    }

    @Override
    public void display() {
        if (realImage == null) {
            realImage = new RealImage(fileName); // 실제 객체를 생성 (지연 초기화)
        }
        realImage.display(); // 실제 객체의 메서드 호출
    }
}

다음은 클라이언트 코드이다.

public class ProxyPatternExample {
    public static void main(String[] args) {
        Image image = new ProxyImage("test_image.jpg");

        // 이미지가 처음 요청될 때만 실제 객체를 생성하여 로드합니다.
        image.display(); // 로딩 후 표시
        System.out.println("");

        // 이후에는 로드된 이미지를 사용합니다.
        image.display(); // 바로 표시
    }
}

동적 프록시

동적 프록시(dynamic proxy)는 자바의 javja.lang.reflect 패키지를 활용한다. 이 패키지를 사용하면 즉석에서 하나 이상의 인터페이스를 구현하고 지정한 클래스에 메소드 호출을 전달하는 프록시 클래스를 만들 수 있다. Java의 리플렉션(Reflection) API를 사용하여 인터페이스를 구현하는 프록시 객체를 생성하며, 개발자는 프록시 객체의 메서드 호출을 처리하는 로직을 정의할 수 있다.

동적 프록시 클래스 다이어그램은 다음과 같다.

Java에서 동적 프록시는 다음 두 가지 주요 구성 요소를 사용한다

java.lang.reflect.Proxy 클래스:
- 동적 프록시 객체를 생성하는 데 사용되는 Java 표준 클래스.
- newProxyInstance() 메서드를 사용하여 런타임에 프록시 객체를 생성한다.
java.lang.reflect.InvocationHandler 인터페이스:
- 프록시 객체의 메서드 호출을 처리하는 인터페이스이다.
- invoke() 메서드를 구현하여 프록시 객체의 메서드 호출을 가로채고, 호출 전에/후에 추가 로직을 정의할 수 있다.

자바에서 Proxy 클래스를 생성해 주므로 Proxy 클래스에게 무슨 일을 해야 하는지 알려줘야 한다. 필요한 코드를 프록시 클래스에 넣을 수 없기 때문에 InvocationHandler에 넣어야 한다. InvocationHandler는 프록시에 호출되는 모든 메서드에 응답한다. Proxy에 메서드 호출을 받으면 항상 InvocationHandler에 진짜 작업을 부탁한다고 생각하면 된다.

다음은 간단한 예제이다.

Subject 인터페이스를 선언한다.

public interface Subject {
    public void request();
}

RealSubject를 구현한다.

public class RealSubject implements Subject {

    @Override
    public void request() {
        System.out.println("request method called");
    }
}

InvocationHandler를 구현한다. InvocationHandler는 Java 내부에 선언되어 있기 때문에 따로 만들 필요 없다. InvocationHandler는 invoke(Object proxy, Method method, Object[] args) 메서드만 갖고 있다.

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class InvocationHandlerImpl implements InvocationHandler {
    private Object target;

    public InvocationHandlerImpl(Object target) {
        this.target = target;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println("메서드 호출 전: " + method.getName()); // 메서드 호출 전 로그
        Object result = method.invoke(target, args); // 실제 객체의 메서드 호출
        System.out.println("메서드 호출 후: " + method.getName()); // 메서드 호출 후 로그
        return result;
    }
}

테스트 코드와 결과는 다음과 같다.

import java.lang.reflect.Proxy;

public class ProxyTest {
    public static void main(String[] args) {
        Subject subject = new RealSubject();

        Subject proxySubject = (Subject) Proxy.newProxyInstance(
                subject.getClass().getClassLoader(),
                subject.getClass().getInterfaces(),
                new InvocationHandlerImpl(subject)
        );

        proxySubject.request();
    }
}

[헤드퍼스트 디자인패턴] 상태 패턴

hongyb — Tue, 27 Aug 2024 23:56:57 +0900

상태 패턴을 알아보자.

상태 패턴

상태패턴

내부 상태가 바뀜에 따라 객체의 행동이 바뀔 수 있도록 해준다. 마치 객체의 클래스가 바뀌는 것 같은 결과를 얻을 수 있다.

요구사항

뽑기 기계가 있다고 가정해 보자. 뽑기 기계에는 '동전이 없는 상태(초기 상태)', '동전이 있는 상태', '뽑기가 나온 상태', '뽑기가 매진된 상태'가 있을 것이다. 또한 '동전 투입', 동전 반환', '손잡이 돌림', '알맹이 내보냄'과 같이 4가지 상태를 바꾸는 행동도 있다. 이것을 프로그래밍으로 어떻게 구현해야 할까?

다음과 같이 현재 상태를 저장하는 인스턴스 변수를 만들고 각 상태의 값을 정의한다고 가정해 보자.

	// 뽑기 매진 상태
    final static int SOLD_OUT = 0;
    // 동전이 없는 상태
    final static int NO_QUARTER = 1;
    // 동전이 들어간 상태
    final static int HAS_QUATER = 2;
    // 뽑기 판매 상태
    final static int SOLD = 3;

4가지 상태에 따라 동전 투입 메서드(insertCoin()), 동전 반환 메서드(ejectQuater()), 손잡이 돌리는 메서드(turnCrank()), 뽑기 내보내는 메서드(produce())를 구현해야 하고 매우 복잡해질 것이다.

insertCoin() 메서드는 다음과 같을 것이다.

	// 뽑기 매진 상태
    final static int SOLD_OUT = 0;
    // 동전이 없는 상태
    final static int NO_QUARTER = 1;
    // 동전이 들어간 상태
    final static int HAS_QUATER = 2;
    // 뽑기 판매 상태
    final static int SOLD = 3;

    private int state = SOLD_OUT;

    public void insertCoin() {
        if(state == HAS_QUATER) {
            System.out.println("You have already inserted coins.");
        } else if(state == NO_QUARTER) {
            state = HAS_QUATER;
            System.out.println("coin inserted");
        } else if(state == SOLD_OUT) {
            System.out.println("already sold out");
        } else if(state == SOLD) {
            System.out.println("The product is coming out");
        }
    }

위 코드처럼 조건문을 통해 상태를 변경하는 방법은 다음 4가지 문제를 고려하지 않고 있다.

코드는 OCP를 지키고 있지 않고 있다.
상태 전환이 복잡한 조건문 속에 숨어 있어 분명하게 드러나지 않고 있다.
바뀌는 부분을 캡슐화하지 않고 있다.
새로운 기능을 추가하는 과정이 복잡하며, 기존에 없던 새로운 버그가 생길 가능성이 높다.

이 문제를 해결하기 위해 상태 패턴을 도입해 보자.

상태 패턴 클래스 다이어그램 및 구현

상태패턴이란 내부 상태가 바뀜에 따라 객체의 행동이 바뀔 수 있도록 해준다. 마치 객체의 클래스가 바뀌는 것 같은 결과를 얻을 수 있다. 이 패턴은 객체의 상태를 캡슐화하고, 그 상태에 따른 행동을 각 상태 객체로 옮겨서 관리하는 방식으로 구현된다. 상태 패턴을 사용하면 상태 전환 로직을 상태별 클래스 안으로 캡슐화하여 코드의 유연성과 유지 보수성을 높일 수 있다.

클래스 다이어그램은 다음과 같다.

클래스 다이어그램을 참고하여 코드로 구현하도록 하겠다.

State 코드는 다음과 같다.

package state;

public abstract class State {
    public abstract void insertCoin();
    public abstract void ejectCoin();
    public abstract boolean turncrank();
    public abstract void produce();
}

State를 구현한 NoCoinState, OneCoinState, ProduceState, SoldoutState는 다음과 같다.

public class NoCoinState extends State {
    private Context context;

    public NoCoinState(Context context) {
        this.context = context;
    }

    @Override
    public void insertCoin() {
        System.out.println("you inserted a coin");
        context.setState(context.getOneCoinState());
    }

    @Override
    public void ejectCoin() {
        System.out.println("no coin to eject");
    }

    @Override
    public boolean turncrank() {
        System.out.println("no coin. please insert a coin");
        return false;
    }

    @Override
    public void produce() {
        System.out.println("no coin. please insert a coin");
    }
}

public class OneCoinState extends State {
    private Context context;

    public OneCoinState(Context context) {
        this.context = context;
    }

    @Override
    public void insertCoin() {
        System.out.println("You have already inserted a coin.");
    }

    @Override
    public void ejectCoin() {
        System.out.println("eject coin.");
        context.setState(context.getNoCoinState());
    }

    @Override
    public boolean turncrank() {
        System.out.println("turn crank");
        context.setState(context.getProduceState());
        return true;
    }

    @Override
    public void produce() {
        System.out.println("you can't produce product now");
    }
}

public class ProduceState extends State {
    Context context;

    public ProduceState(Context context) {
        this.context = context;
    }

    @Override
    public void insertCoin() {
        System.out.println("producing now..");
    }

    @Override
    public void ejectCoin() {
        System.out.println("you can't eject a coin. producing now..");
    }

    @Override
    public boolean turncrank() {
        System.out.println("producing now..");
        return false;
    }

    @Override
    public void produce() {
        context.reduceProduceCount();
        if(context.getProduceCount() > 0) {
            context.setState(context.getNoCoinState());
        } else if(context.getProduceCount() == 0) {
            context.setState(context.getSoldoutState());
        }
    }
}

public class SoldOutState extends State {
    private Context context;

    public SoldOutState(Context context) {
        this.context = context;
    }

    @Override
    public void insertCoin() {
        System.out.println("sold out");
    }

    @Override
    public void ejectCoin() {
        System.out.println("you can't eject coin");
    }

    @Override
    public boolean turncrank() {
        System.out.println("sold out");
        return false;
    }

    @Override
    public void produce() {
        System.out.println("sold out");
    }
}

4개의 클래스 모두 각자 상황에 맞춰 State 클래스 안에 있는 메서드를 오버라이드 하고 있다. 또한 공통적으로 Context를 구성하고 생성자에서 인스턴스를 받고 있다. context는 나중에 다른 상태로 전환할 때 필요한 레퍼런스이다.

Context 클래스는 다음과 같다.

public class Context {
    private State soldoutState;
    private State noCoinState;
    private State oneCoinState;
    private State produceState;
    private State randomPlusCountState;

    private State state;
    private int produceCount;

    public Context(int produceCount) {
        this.produceCount = produceCount;

        if(produceCount > 0) {
            state = noCoinState;
        } else {
            state = soldoutState;
        }

        soldoutState = new SoldOutState(this);
        noCoinState = new NoCoinState(this);
        oneCoinState = new OneCoinState(this);
        produceState = new ProduceState(this);
        randomPlusCountState = new RandomPlusCountState(this);
    }

    public void insertCoin() {
        state.insertCoin();
    }
    public void ejectCoin() {
        state.ejectCoin();
    }
    public void turnCrank() {
        if(state.turncrank()) {
            state.produce();
        }
    }

    public boolean reduceProduceCount() {
        if(produceCount <= 0) {
            return false;
        }
        produceCount--;
        return true;
    }

    public State getSoldoutState() {
        return soldoutState;
    }

    public State getNoCoinState() {
        return noCoinState;
    }

    public State getOneCoinState() {
        return oneCoinState;
    }

    public State getProduceState() {
        return produceState;
    }

    public State getRandomPlusCountState() {
        return randomPlusCountState;
    }

    public int getProduceCount() {
        return produceCount;
    }

    public void setState(State state) {
        this.state = state;
    }

    public void setProduceCount(int produceCount) {
        this.produceCount = produceCount;
    }
}

상태 패턴을 도입함으로써 다음 4가지 효과를 기대할 수 있다.

각 상태의 행동을 별개의 클래스로 국지화했다.
관리하기 힘든 조건문을 없앴다.
각 상태를 변경에는 닫혀있게 하고, State 클래스는 새로운 상태 클래스를 추가하는 확장에는 열려 있도록 했다.(OCP)
다이어그램에 가까우면서 이해하기 좋은 클래스 구조를 생산해 냈다.

위에 코드를 보면 구상 상태 클래스(State를 구현한 클래스)에서 다음 상태를 결정하고 있는데 항상 그래야 하는 건 아니다. Context에서 상태 전환 흐름을 결정할 수 있다. 상태 전환이 고정되어 있으면 상태 전환 흐름을 결정하는 코드를 Context에 넣어도 된다. 하지만 상태 전환이 동적으로 결정된다면 상태 클래스 내에 처리하는 것이 좋다. 예를 들어 State에서 NoCoinState 또는 SoldOutState로 전환하는 결정은 실행 중에 남아있는 produceCount에 의해 동적으로 결정될 수밖에 없다.

상태 전환 코드를 상태 클래스에 넣으면 상태 클래스 사이에 의존성이 생기는 단점이 있다. State 구현 코드를 보면 구상 상태 클래스를 코드에 직접 넣는 대신 Context 객체의 Getter 메서드를 써서 의존성을 최소화하려고 노력했다.

상태 패턴 VS 전략 패턴

상태 패턴과 전략 패턴의 클래스 다이어그램을 비교해 보면 비슷하다는 사실을 알게 된다. 상태 패턴을 사용할 때 상태 객체에 일련의 행동이 캡슐화된다. 상황에 따라 Context 객체에서 여러 상태 객체 중 한 객체에게 모든 행동을 맡기게 된다. 그 객체 내부 상태에 따라 현재 상태를 나타내는 객체가 바뀌게 되고, 그 결과로 Context 객체 행동오 바뀌게 된다. 중요한 점은 클라이언트는 상태 객체를 몰라도 된다는 것이다.

전략 패턴은 클라이언트가 Context 객체에게 어떤 전략 객체를 사용할지 지정한다. 전략 패턴은 주로 실행 시에 전략 객체를 변경할 수 있는 유연성을 제공한다. 일반적으로 전략 패턴은 서브클래스를 만드는 방법을 대신해서 유연성을 극대화하는 용도로 쓰인다. 상속을 사용해서 클래스의 행동을 정의하다 보면 행동을 변경할 때 마음대로 변경하기 힘들다. 하지만 전략 패턴을 사용하면 구성으로 행동을 정의하는 객체를 유연하게 바꿀 수 있다.

[헤드퍼스트 디자인패턴] 반복자 패턴과 컴포지트 패턴

hongyb — Fri, 23 Aug 2024 00:57:38 +0900

반복자 패턴과 컴포지트 패턴을 알아보자.

반복자 패턴과 컴포지트 패턴

반복자 패턴

컬렉션의 구현 방법을 노출하지 않으면서 집합체 내의 모든 항목에 접근하는 방법을 제공한다.

컴포지트 패턴

객체를 트리구조로 구성해서 부분-전체 계층구조를 구현한다. 컴포지트 패턴을 사용하면 클라이언트에서 개별 객체와 복합 객체를 똑같은 방법으로 다룰 수 있다.

H3 중제목

배열, 리스트, 맵 자료구조를 각각 3개의 클래스에서 저장한다고 가정해 보자. Client라는 객체에서 배열, 리스트, 맵 3개를 모두 조회하려면 3개의 자료구조 형태에 맞춰 코드로 구현해야 할 것이다.

Client가 배열, 리스트, 맵 등의 자료구조를 직접 조회해야 한다면, 클라이언트 코드에서 각각의 자료구조에 대해 다른 방식으로 요소에 접근해야 한다. 이는 코드의 복잡성을 증가시키고 유지보수를 어렵게 만든다. 아래는 이러한 문제를 나타내는 Java 코드 예시이다.

배열 저장 클래스

public class ArrayData {
    private String[] data;

    public ArrayData(String[] data) {
        this.data = data;
    }

    public String[] getData() {
        return data;
    }
}

리스트 저장 클래스

import java.util.List;

public class ListData {
    private List<String> data;

    public ListData(List<String> data) {
        this.data = data;
    }

    public List<String> getData() {
        return data;
    }
}

맵 저장 클래스

import java.util.Map;

public class MapData {
    private Map<String, String> data;

    public MapData(Map<String, String> data) {
        this.data = data;
    }

    public Map<String, String> getData() {
        return data;
    }
}

클라이언트 코드

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class ClientWithoutIteratorPattern {

    public static void main(String[] args) {
        // 배열 데이터
        String[] array = {"Apple", "Banana", "Cherry"};
        ArrayData arrayData = new ArrayData(array);

        // 리스트 데이터
        List<String> list = new ArrayList<>();
        list.add("Dog");
        list.add("Elephant");
        list.add("Fox");
        ListData listData = new ListData(list);

        // 맵 데이터
        Map<String, String> map = new HashMap<>();
        map.put("Key1", "Grapes");
        map.put("Key2", "Honeydew");
        map.put("Key3", "Iced Tea");
        MapData mapData = new MapData(map);

        // 배열 요소 조회
        System.out.println("Array Data:");
        for (int i = 0; i < arrayData.getData().length; i++) {
            System.out.println(arrayData.getData()[i]);
        }

        // 리스트 요소 조회
        System.out.println("\nList Data:");
        for (int i = 0; i < listData.getData().size(); i++) {
            System.out.println(listData.getData().get(i));
        }

        // 맵 요소 조회
        System.out.println("\nMap Data:");
        for (Map.Entry<String, String> entry : mapData.getData().entrySet()) {
            System.out.println(entry.getKey() + " = " + entry.getValue());
        }
    }
}

이러한 구조는 여전히 클라이언트 코드가 각 자료구조의 내부 구현에 의존하고 있으며, 자료구조가 추가되거나 변경될 때마다 클라이언트 코드를 수정해야 하는 문제가 있다.

이러한 문제를 해결하기 위해 반복자 패턴이 만들어졌다.

반복자 패턴 클래스 다이어그램 및 구현

반복자 패턴(Iterator Pattern)은 컬렉션의 구현 방법을 노출하지 않으면서 집합체 내의 모든 항목에 접근하는 방법을 제공한다. 반복자 패턴을 사용하면 집합체 내에서 어떤 식으로 일이 처리되는지 전혀 모르는 상태에서 그 안에 들어있는 모든 항목을 대상으로 반복 작업을 수행할 수 있다.

반복자 패턴 클래스 다이어그램은 다음과 같다.

Client 입장에서 Iterator 인터페이스에만 의존하고 있기 때문에 Iterator 객체만 있으면 배열로 저장되어 있든 ArrayList로 저장되어 있든 신경 쓰지 않고 작업을 처리할 수 있다.

또한 반복자 패턴을 사용하면 모든 항목에 일일이 접근하는 작업을 컬렉션 객체가 아닌 반복자 객체가 맡게 된다.

반복자 패턴 클래스 다이어그램을 참고하여 코드로 구현해 보았다.

Aggregate 인터페이스이다. createIterator()에서 Iterator를 반환해야 한다. Iterator 인터페이스는 직접 구현하지 않고, Java에 기본적으로 내장된 인터페이스를 사용했다.

import java.util.Iterator;

public interface Aggregate {
    public Iterator<MyItem> createIterator();
}

MyItem 클래스를 Aggregate를 구현한 객체(ConcreteAggregateA, ConcreteAggregateB, ConcreteAggregateC)에서 각자 다른 자료구조로 갖고 있게 된다. ConcreteAggregateA, ConcreteAggregateB, ConcreteAggregateC 모두 Aggregate 인터페이스를 구현했기 때문에 createIterator()를 오버라이드 해 iterator를 반환해야 한다.

public class MyItem {
    private String name;
    private String description;

    public MyItem(String name, String description) {
        this.name = name;
        this.description = description;
    }

    public String getName() {
        return name;
    }

    public String getDescription() {
        return description;
    }
}

public class ConcreteAggregateA implements Aggregate {
    private MyItem[] myItems;
    private final int MAX_VALUE = 10;
    private int position = 0;

    public ConcreteAggregateA() {
        myItems = new MyItem[MAX_VALUE];
    }

    public void add(String name, String description) {
        if(position >= MAX_VALUE) return;
        myItems[position] = new MyItem(name, description);
        position++;
    }

    @Override
    public Iterator<MyItem> createIterator() {
        return new ConcreteAIterator(myItems);
    }
}

public class ConcreteAggregateB implements Aggregate {
    List<MyItem> myItemList;

    public ConcreteAggregateB() {
        myItemList = new ArrayList<>();
        myItemList.add(new MyItem("hihi", "hello hello"));
        myItemList.add(new MyItem("name", "descriptioin"));
    }

    @Override
    public Iterator<MyItem> createIterator() {
        return myItemList.iterator();
    }
}

public class ConcreteAggregateC implements Aggregate {
    Map<String, MyItem> map;

    public ConcreteAggregateC() {
        this.map = new HashMap<>();

        map.put("hihi", new MyItem("map", "map description"));
    }

    @Override
    public Iterator<MyItem> createIterator() {
        return map.values().iterator();
    }
}

위 코드에서 중요한 점은 ConcreteAggregateA와 ConcreteAggregateB, ConcreteAggregateC의 차이점이다.

Java에서 Collection 인터페이스는 Iterable 인터페이스를 확장하며, 이로 인해 모든 컬렉션 클래스(ArrayList, LinkedList, HashSet 등)는 iterator() 메서드를 제공하고 있다. 따라서 Collection 인터페이스를 쓰고 있는 ConcreteAggregateB(List 사용), ConcreteAggregateC(Map 사용)은 iterator를 구현할 필요 없이 자신이 구현한 iterator() 메서드를 호출하면 된다.

이와 달리 ConcreteAggregateA의 배열(myItems)은 자체적으로 구현한 iterator를 반환하는 메서드가 없기 때문에 만들어줘야 한다. 코드는 다음과 같다.

import java.util.Iterator;

public class ConcreteAIterator implements Iterator<MyItem> {
    private MyItem[] myItems;
    int position = 0;

    public ConcreteAIterator(MyItem[] myItems) {
        this.myItems = myItems;
    }

    @Override
    public boolean hasNext() {
        if(myItems.length <= position || myItems[position] == null) {
            return false;
        }
        return true;
    }

    @Override
    public MyItem next() {
        MyItem myItem = myItems[position];
        position++;
        return myItem;
    }

    @Override
    public void remove() {
        throw new UnsupportedOperationException();
    }
}

마지막으로 Client 클래스이다.

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

public class Client {
    public static void main(String[] args) {
        List<Aggregate> aggregates = new ArrayList<>();

        ConcreteAggregateA concreteAggregateA = new ConcreteAggregateA();
        concreteAggregateA.add("aa", "aaa");
        concreteAggregateA.add("bb", "bbb");

        aggregates.add(concreteAggregateA);
        aggregates.add(new ConcreteAggregateB());
        aggregates.add(new ConcreteAggregateC());

        Client client = new Client(aggregates);
        client.printAll();
    }

    private List<Aggregate> aggregateList;
    public Client(List<Aggregate> aggregateList) {
        this.aggregateList = aggregateList;
    }

    public void printAll() {
        Iterator<Aggregate> aggregateIterator = aggregateList.iterator();
        while(aggregateIterator.hasNext()) {
            Aggregate next = aggregateIterator.next();
            print(next.createIterator());
        }
    }

    private void print(Iterator<MyItem> iterator) {
        while(iterator.hasNext()) {
            MyItem myItem = iterator.next();
            System.out.println("name : " + myItem.getName() + ", description : " + myItem.getDescription());
        }
    }
}

단일 역할 원칙

집합체에서 내부 컬렉션 관련 기능과 반복자용 메서드 관련 기능을 전부 구현한다면 컬렉션이 변경되거나, 반복자 관련 기능이 바뀌었을 때 클래스가 바뀌어야 한다. 이러한 설계는 단일 역할 원칙을 무시게 된다.

단일 책임 원칙은 "클래스는 하나의 책임만 가져야 한다"는 것을 의미한다. 더 쉽게 설명하자면 클래스가 변경되는 이유는 오직 하나여야 한다는 원칙이다. 이는 클래스가 하나의 기능만을 수행하도록 설계되어야 한다는 것을 강조한다.

어떤 클래스에서 맡고 있는 모든 역할은 나중에 코드 변화를 불러올 수 있다. 역할이 2개 이상 있으면 바뀔 수 있는 부분은 2개 이상 되는 것이다. 이 원칙에 따라 하나의 클래스는 하나의 역할만 맡아야 한다.

간단한 예시를 들어보겠다. 직원의 정보를 관리하고, 월급을 계산하며, 그 데이터를 파일로 저장하는 시스템을 개발하면 Employee 클래스는 다음과 같다.

public class Employee {
    private String name;
    private double salary;

    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    // 직원의 데이터를 가져오는 메서드
    public String getName() {
        return name;
    }

    public double getSalary() {
        return salary;
    }

    // 월급을 계산하는 메서드
    public double calculateMonthlySalary() {
        return salary / 12;
    }

    // 직원 데이터를 파일로 저장하는 메서드
    public void saveToFile() {
        // 파일 저장 로직
    }
}

위 클래스에는 여러 기능이 포함되어 있다:

직원의 기본 정보 관리 (name, salary 등의 필드와 getter 메서드).
월급 계산 (calculateMonthlySalary 메서드).
데이터를 파일로 저장 (saveToFile 메서드).

이제 "이 클래스가 왜 변경될 수 있을까?"를 생각해 보자:

급여 계산 방법이 변경: 예를 들어, 회사에서 새로운 급여 계산 규칙을 도입할 수 있다.
파일 저장 형식이 변경될 수 있다: 데이터를 파일로 저장할 때, 예를 들어, 파일 형식을 CSV에서 JSON으로 변경해야 할 수 있다.
직원의 기본 정보가 변경될 수 있다: 예를 들어, 직원의 주소나 전화번호 같은 추가 정보가 필요해질 수 있다.

이 클래스는 이 세 가지 이유 각각으로 인해 변경될 가능성이 있다. 이제 이 클래스의 한 부분이 변경되면, 의도하지 않게 다른 부분에 영향을 줄 수 있다. 예를 들어, 파일 저장 형식을 변경할 때, 급여 계산과 관련된 코드가 의도치 않게 수정될 수 있다.

이를 방지하기 위해, 클래스를 각각의 변경 이유에 따라 분리해 보자.

1. 직원 정보 관리

public class Employee {
    private String name;
    private double salary;

    public Employee(String name, double salary) {
        this.name = name;
        this.salary = salary;
    }

    public String getName() {
        return name;
    }

    public double getSalary() {
        return salary;
    }
}

2. 급여 계산

public class SalaryCalculator {
    public double calculateMonthlySalary(Employee employee) {
        return employee.getSalary() / 12;
    }
}

3. 파일 저장

public class EmployeeFileSaver {
    public void saveToFile(Employee employee) {
        // 파일 저장 로직
    }
}

이렇게 분리함으로써, 예를 들어 급여 계산 방법이 변경되더라도, 파일 저장 관련 코드를 전혀 건드리지 않아도 된다. 반대로, 파일 저장 형식을 변경해야 할 때는 급여 계산 로직에 전혀 영향을 미치지 않는다. 각 클래스는 하나의 책임만 가지고 있기 때문에, 하나의 기능을 변경할 때 다른 기능에 영향을 주지 않게 된다.

컴포지트 패턴

다음으로 컴포지트 패턴을 알아보도록 하겠다. 컴포지트 패턴이란 객체를 트리구조로 구성해서 부분-전체 계층구조를 구현한다. 컴포지트 패턴을 사용하면 클라이언트에서 개별 객체와 복합 객체를 똑같은 방법으로 다룰 수 있다. 컴포지트 패턴으로 부분-전체 계층 구조를 생성할 수 있다. 이 패턴을 사용하면 클라이언트가 개별 객체와 객체들의 그룹을 동일하게 다룰 수 있다. 컴포지트 패턴은 복잡한 구조를 간단하게 표현하고, 계층 구조를 유연하게 다루기 위한 강력한 도구이다.

클래스 다이어그램은 다음과 같다.

컴포지트 패턴의 주요 개념

구성 요소(Component):
- Component는 모든 객체들이 가져야 하는 공통 인터페이스를 정의한다. 이 인터페이스에는 트리 구조의 개별 객체와 그 집합을 동일하게 다룰 수 있는 메서드들이 포함된다.
잎(Leaf):
- Leaf는 트리 구조의 가장 작은 구성 요소로, 자식이 없는 노드이다. Leaf는 실제 작업을 수행하며, 일반적으로 재귀적으로 호출되는 메서드를 구현한다. Leaf는 더 이상 자식을 추가할 수 없는 가장 말단의 객체이다.
컴포지트(Composite):
- Composite는 자식 구성 요소(다른 Leaf 또는 Composite)를 포함할 수 있는 복합 객체이다. Composite는 자식 구성 요소를 관리하고, 트리 구조에서의 작업을 재귀적으로 수행하는 역할을 한다.

클래스 다이어그램을 참고하여 코드로 구현해 보도록 하겠다.

컴포지트 패턴 코드 구현

Component 코드는 다음과 같다.

public abstract class Component {
    public void operation() {
        throw new UnsupportedOperationException();
    }

    public String getName() {
        throw new UnsupportedOperationException();
    }

    public String getDescription() {
        throw new UnsupportedOperationException();
    }

    public void print() {
        throw new UnsupportedOperationException();
    }

    public void add(Component component) {
        throw new UnsupportedOperationException();
    }

    public void remove(Component component) {
        throw new UnsupportedOperationException();
    }

    public Component getChild(int idx) {
        throw new UnsupportedOperationException();
    }
}

어떤 메서드는 Leaf 클래스에서 어떤 메서드는 Composit 클래스에서 사용할 수 있기 때문에 모두 UnsupportedOperationException()으로 예외처리를 했다. 각 클래스는 자기 역할에 맞지 않는 케소드는 오버라이드 하지 않고 기본 구현을 사용하면 된다.

다음은 Leaf 클래스이다.

public class Leaf extends Component {
    private String name;
    private String description;

    public Leaf(String name, String description) {
        this.name = name;
        this.description = description;
    }

    @Override
    public void print() {
        System.out.println("name : " + name + ", description : " + description);
    }

    @Override
    public String getName() {
        return name;
    }

    @Override
    public String getDescription() {
        return description;
    }
}

다음으로 Composit 클래스이다.

import java.util.ArrayList;
import java.util.List;

public class Composit extends Component {
    private String name;
    private String description;
    private List<Component> childList;

    public Composit(String name, String description) {
        this.name = name;
        this.description = description;
        childList = new ArrayList<>();
    }

    @Override
    public String getName() {
        return name;
    }

    @Override
    public String getDescription() {
        return description;
    }

    @Override
    public void print() {
        System.out.println("-----composit-----");
        System.out.println("composit name : " + name + ", description : " +description);
        for(Component child : childList) {
            child.print();
        }
    }

    @Override
    public void add(Component component) {
        childList.add(component);
    }

    @Override
    public void remove(Component component) {
        childList.remove(component);
    }

    @Override
    public Component getChild(int idx) {
        return childList.get(idx);
    }
}

List<Component> childList에 자식을 저장할 수 있다.

다음으로 Client 클래스와 테스트 코드이다.

public class Client {
    private Component rootComponent;

    public Client(Component rootComponent) {
        this.rootComponent = rootComponent;
    }

    public void print() {
        rootComponent.print();
    }
}

package compositePattern;

public class CompositeTest {
    public static void main(String[] args) {
        Composit rootComposit = new Composit("root composit", "root");
        Client client = new Client(rootComposit);

        Composit child1 = new Composit("child1", "child");
        Composit child2 = new Composit("child2", "child");
        Composit child3 = new Composit("child3", "child");
        Composit child4 = new Composit("child4", "child");


        rootComposit.add(child1);
        rootComposit.add(child2);
        rootComposit.add(child3);
        child3.add(child4);

        child1.add(new Leaf("leafA1", "hi"));
        child1.add(new Leaf("leafA2", "hihi"));

        child2.add(new Leaf("leafB1", "wow"));
        child2.add(new Leaf("leafB2", "wowowow"));

        child3.add(new Leaf("leafC1", "wowowow"));
        child3.add(new Leaf("leafC2", "wowowow"));
        child3.add(new Leaf("leafC3", "wowowow"));

        child4.add(new Leaf("leafD3", "wowowowowwowow"));

        rootComposit.print();
    }
}

테스트 결과는 다음과 같다.

마무리

컴포지트 패턴과 단일 책임 원칙을 같이 배움으로써 상황에 따라 원칙을 적절하게 사용해야 함을 알 수 있다. 컴포지트 패턴은 단일 책임 원칙을 깨고 있다. 컴포지트 패턴에서 Composite 클래스는 다음과 같은 여러 책임을 가질 수 있다.

자식 요소 관리: 자식 요소를 추가하고, 제거하고, 접근하는 책임.
트리 구조 관리: 자식 요소의 순회를 관리하는 책임.
자신의 작업 수행: Leaf와 마찬가지로 자신의 작업(예: operation() 메서드에서 정의된 작업)을 수행하는 책임.

소프트웨어 설계에서 모든 원칙을 완벽하게 따르는 것은 어려울 수 있으며, 때로는 설계의 목표와 상황에 따라 특정 원칙을 일부 타협할 필요가 있다. 한 가지 원칙만 고수하는 것보다 상황에 따라 유연하게 접근하는 것이 더 좋은 설계를 이끌어낼 수 있다.