좋아하는 일 그리고 잘하는 일, 그 사이 어딘가

[2026.01.19] 만약에 우리

Kangworld — Mon, 19 Jan 2026 21:37:59 +0900

소원 같은 건 진작 잊어버렸다.

기억하는 건

같이 소원을 빌었다는 것

우리가 있었다는 것.

[웹툰] 가담항설 리뷰

Kangworld — Mon, 12 Jan 2026 23:40:28 +0900

랑또 작가의 장편 웹툰
가담항설

2025 연말에 정주행한 기념으로
짧게나마 리뷰를 남겨본다.

가담항설은 아주아주 먼 옛날 이야기이다.
한반도 역사로 따지면 초기 조선시대쯤?
농업 중심의 한 국가가 있었다.

이 나라에는 아주 큰 근심거리가 있었는데
가뭄, 홍수, 천둥번개, 태풍, 해일 등
천재지변이 끊이질 않았다.

왕은 날씨를 다스리던 용을 찾아가 제안을 한다.
"당신을 위해 1000년을 기도해서
인간의 모습과 불노불사의 능력을 만들어 줄 테니
자연을 이롭게 다스려 달라."

용은 이 제안을 받아들이고
1000년이라는 긴 시간 동안 잠에 빠지게 된다.
이때 용은 전국에서 가장 빼어난 사군자를 곁에 두고 잠에 드는데
훗날 이는 용을 보필하는 네 명의 호위무사가 된다.

1000년 동안 하루도 빠짐없이 기도를 받았으면 좋았겠지만...
날짜를 세는 관료의 실수로 하루 일찍 깨어나면서
불노의 몸은 얻었지만 불사의 몸은 아닌
역린을 지닌 존재가 된다.

용의 등장으로 나라는 눈에 띄게 안정되었으나
그의 등장으로 입지가 좁아진 세력이 용을 암살하려 했고
그 과정에서 용이 가장 아끼던 사군자 춘매가 목숨을 잃는다.

이 사건 이후 용은 더 이상
인간을 믿지 않았고
날씨를 이롭게 다스리지 않았으며
공포로 나라를 다스리는
이른바 폭군이 되어버리고 만다.

그러던 어느 날,
한 신하가 춘매를 살릴 수 있다며 천동지라는 물건을 언급한다.
천동지는 가담항설에서 정말 정말 중요하게 다뤄지는 물건으로
깊은 염원을 담아 적으면 소원이 이뤄지는 아주 아주 신비한 종이다.
만화 드래곤볼로 치면 드래곤볼쯤 되겠다.

천동지는 매년 한 마을에서 조공으로 바쳐온 귀중한 물건으로
춘매를 살리기 위해선 여러 장의 천동지가 필요했고
마지막 하나의 천동지만을 남겨둔 상태에서
이를 징수하기 위해 관군으로 둔갑한 용이
마을에 잠입하는 것으로 가담항설 1화가 시작된다.

세계관도 너무 매력적이지만
캐릭터들의 대사 하나하나
울림이 있어 여운이 남는다.

개추!

[2026.01.01] 소 잃고 뇌 약간 고침

Kangworld — Thu, 1 Jan 2026 23:53:57 +0900

2026.01.01 목요일

누군가의 버팀목이 된다는 것이
매우 지치고 괴로운 일이었다.

돌이켜보니
내가 누군가의 버텀목이란 사실이
나를 지탱하고 있었음을.

그때의 난 몰랐다.

[2024.08.11] 혼자 떠난 일본 여행 (2)

Kangworld — Sun, 11 Aug 2024 14:44:55 +0900

2024.07.24 수요일

아침 일찍 달려간 금각사

사찰 전체가 빤짝빤짝 빛난다.

금빛 전각을 제외하고 크게 볼 게 없었던

금각사에서 내려와 대나무숲으로 가기 위해 버스를 기다리던 중 비가 내리기 시작

비가 내린 이후 온도가 내려가면서 교토 여행이 (너무 * 100) 즐겁기 시작

비 오는 풍경이 너무 좋아서

지하철에서 내리니 비가 그쳤다

대나무숲 입장

대나무인 척

대나무가 바람에 흔들리는 소리, 새가 지저귀는 소리.

는 사진으로 못 담지만 대충 좋았다는 의미

여행에서 제일 좋았던 가츠라강

한 30분 정도 강을 바라보며 앉아있었다.

크게 무슨 생각을 하진 않았고 평온한 느낌에 교토에 오길 잘 했다는 생각이 들었다.

강원도 살 때 이런 느낌의 강에서 가족들과 종종 낚시를 하곤 했다.

또다시 가족과 고향 생각에 울컥했던

새 들은 무슨 생각 하며 살까?

북적이는 걸 피해서 일부러 사람 없는 민가를 가로질러 버스 타러 갔다.

이날도 진짜 더웠는데 민가에서 마주친 어떤 아주머니가 "아츠이네~ 아츠이 아츠이" 말을 걸어오셨다.

뭔가 덥다 의미 같았는데 춥다는 의미의 사무이밖에 몰라서 멋쩍은 웃음만 지으며 호다닥 도망치듯 걸어갔다.

노부부가 운영하는 소바 집

대표 메뉴인 텐뿌라 주문

한국에서 먹는 소바와 다른 점은 찍어 먹는 쯔유에 있는 것 같다.

정말 달고, 짜고, 가쓰오부시 향이 그득한 메밀면 찍어 먹기 최적의 소스

숙소에서 좀 쉬다가 도착한 카모강

낮에 비가 와서 그런지 강이 엄청 불어있었다.

맥주 한 캔 사들고 강가에 앉아 홀짝홀짝 마셨다.

강을 바라보며 생각을 정리한 것 같은데 구체적으로 뭘 생각했는지 기억은 안 나는..

아마 회사 생활을 비롯한 20대 직장인의 흔한 고민이 아니였을지

저녁 늦게 도착한 이자카야

첫 주문으로 가라아게

약간 오버 쿠킹됐다;

맛은 슴슴했다. 난 짭짤한 가라아게가 좋다고!!

정말 맛있게 먹었던 숙성 사시미 오마카세

최고는 오징어

찰기가 어마어마해서 저 초록 잎에서 잘 떨어지지도 않았다.

씹으면 쫀득한 오징어가 잇몸 사이사이를 밀고 들어온다.

오징어 특유의 단맛은 말해 뭐해

메뉴 명은 horse mackerel 구이

horse가 붙어있길래 말고기인줄 알았다 ㅋㅋ;

한국말로 하면 전갱이 구이

딱 쥐포 맛

[2024.08.05] 상반기 일상 & 혼자 떠난 일본 여행 (1)

Kangworld — Mon, 5 Aug 2024 23:06:10 +0900

2024.01.09 화요일

강릉 버드나무 브루어리

겨울 굴은 항상 옳다

2024.04.09 화요일

인천 랜더스 필드

존맛 크림 새우

째정

80세까지 계속 야구해줘...

2024.04.16 화요일

회사 근처 볼링장

비 정기적 볼링 동호회 모임

첫 모임에 비하면 장족의 발전

2024.05.31 금요일

고척 스카이돔

선발 오원석 매우 호투했던 걸로 기억

2024.07.23 화요일

대망의 일본 여행

교토 2박 3일, 오사카 2박 3일

간사이 국제공항에서 교토로 넘어가기 위해 탄 JR 하루카

바보처럼 왕복 티켓의 출발일을 두 개 다 여행 출발일로 발권했다;

다행히 교토역 안내 센터에서 날짜를 바꿀 수 있었다.

영어 가능한 직원분들이 계셔서 천만다행

기차에서 마신 녹차

오

타

니

날씨가 정말 좋았던 교토

날씨가 너무 좋은 나머지 체감 온도 38도를 가볍게 찍는다.

사우나 불가마 들어갔을 때 숨이 턱 막히는 것처럼

역에서 내리면 잠시 숨이 안 쉬어진다;

숙소에 짐 맡기고 바로 달려갔던 우나기동 맛집.

너무 맛있었다.

점심먹고 도착한 청수사

한국과 비슷하면서도 다른 느낌

교토 특유의 고즈넉함이 느껴져서 정말 좋았다.

청수사 메인 스팟에서 바라본 교토 시내

교토 타워가 보인다.

여행 중 알게 된 사실인데, 쿄토는 교토 타워보다 높은 건물은 짓지 못한다고 한다.

엄밀히 말하면 교토 타워보다는 아닌데 대충 뭐 그렇다.

청수사에서 내려오며 찍은 가옥

역사와 전통이 있어 보여서 찍었다.

저녁 가까이 도착한 철학의 길

아주 작은 하천과 돌길인데 사람도 없고 너무 평온했다.

어렸을적에 이런 곳에서 자주 놀곤 했는데

그래서 그런지 고향 생각에 울컥했던

늦은 저녁 도착했던 이자카야에서의 첫 안주, 호르몬 폰즈

대창과 유자 소스 아는 맛의 조합인데 너무 맛있었다.

기분이 너무 좋아버린 나머지 대충 찍어버린 맥주

그 이후의 안주와 술은 이성을 잃고 사진 찍는 걸 까먹었다.

[Redis] Sorted Set : 기본 명령어

Kangworld — Wed, 24 Apr 2024 23:32:11 +0900

Sorted Set

Redis의 Sorted Set은 말 그대로 정렬된 집합을 표현하는 자료구조로, 각 요소는 고유한 멤버와 스코어 한 쌍으로 이루어진다. 스코어는 멤버의 순서를 결정하는 데 사용된다. Sorted Set의 대표적인 기능으로 멤버의 추가, 삭제, 검색을 제공하며, 스코어를 기반으로 한 업데이트, 조회 또한 제공한다.

Sorted Set의 특성은 다음과 같다 :

1. 고유한 멤버 : 멤버는 고유한 값으로 구성된다.

2. 정렬된 상태로 저장 : 스코어에 따라 정렬되어 저장된다.

3. 빠른 조회 : 내부적으로 skip list로 구현되어 있어 조회 시 O(log(N))의 시간 복잡도를 갖는다.

4. 유연한 조회 : 스코어 기준으로도 멤버를 조회 가능하다.

Sorted Set의 이러한 특성은 랭킹 시스템의 리더보드, 우선순위 큐, 세컨더리 인덱싱 구현에 유용하게 사용된다.

주요 명령어

다음은 Redis에서 Sorted Set을 사용하는 몇 가지 기본적인 명령어와 그 예시이다.
공식 사이트가 매우 친절하다. 커맨드를 날려보며 학습할 수 있어서 매우 유용하다.

ZADD

멤버 추가

ZADD key score member [score member ...]

ZADD myzset 1 helloworld

ZREM

멤버 제거

ZREM key member [member ...]

ZREM myzset helloworld

ZSCORE

멤버 스코어 반환

ZSCORE key member

ZSCORE myzset helloworld

ZINCRBY

스코어 증가. 멤버가 없다면 생성 (increase or insert)

ZINCRBY key increment member

ZINCRBY myzset 100 helloworld

ZCOUNT

주어진 스코어 범위 내의 멤버 수 반환

ZCOUNT key min max

ZCOUNT myzset 100 200

다음과 같이 스코어와 +inf를 사용하면 스코어 100의 내림차순 등수를 계산할 수 있다.

ZINCRBY myzset 100 +inf

ZRANK

멤버 순위 계산. 낮은 스코어부터 0번 순위 부여하며 동점시 멤버를 사전순으로 다시 정렬해서 순위를 부여한다.

ZRANK key member

ZRANK myzset helloworld

ZREVRANK

멤버 역순위 계산. 높은 스코어부터 0번 순위 부여

ZREVRANK key member

ZREVRANK myzset helloworld

ZRANGE

지정된 범위 값으로 멤버를 검색한다.

기본적으로 순위 기반 검색이며 BYSCORE 옵션을 명시하면 스코어 기반으로 검색한다.

ZRANGE key start stop [BYSCORE | BYLEX] [REV] [LIMIT offset count]   [WITHSCORES]

ZRANGE myzset 0 1
ZRANGE myzset 90 100 BYSCORE

ZREVRANGE

지정된 범위 값으로 멤버를 역순으로 조회한다. ZRANGE의 반대 개념으로 ZRANGE에 REV 옵션을 명시하는 것과 동일하다. 6.2.0부터 Deprecated 되었으니 가급적 ZRANGE를 사용하자.

ZREVRANGE key start stop [WITHSCORES]

ZREVRANGE myzset helloworld 0 1

ZRANGEBYLEX

멤버의 사전식 순서를 기준으로 특정 문자열 범위 내에 있는 멤버를 조회한다. ZRANGE의 BYLEX 옵션을 명시하는 것과 동일하다. 6.2.0부터 Deprecated 되었으며 주의 사항으로 모든 멤버가 같은 스코어를 가질 때 유효하다.

ZRANGEBYLEX key min max [LIMIT offset count]

ZADD myzset 0 a 0 b 0 c 0 d 0 e 0 f 0 g
ZRANGEBYLEX myzset [a [b
1) "a"
2) "b"

[2024.01.01] 해피 뉴 이어~~!

Kangworld — Mon, 1 Jan 2024 20:48:54 +0900

2024.01.01 월요일

잘 가 2023, 2024도 행복한 일만 가득하길!

[Java] 공변성으로 알아보는 제네릭과 와일드카드

Kangworld — Wed, 6 Dec 2023 23:21:27 +0900

서론

공변성과 제네릭 그리고 와일드카드에 대해서 알아보고 마지막으로 @SafeVarargs 어노테이션을 소개로 마무리한다.

공변성과 배열

자바의 공변성은 하위 클래스의 객체를 상위 클래스의 참조 변수로 참조할 수 있는 성질을 의미한다. 다르게 말하면 상속 관계에서 파생된 클래스의 객체가 부모 클래스의 객체처럼 취급될 수 있음을 말한다.

자바에서 공변성을 만족하는 대표적인 예시가 바로 배열이다. 예를 들어, 배열의 원소 타입이 상속 관계를 가질 때, 배열 자체의 타입 간에도 상속 관계가 유지된다. 간단히 말하면 하위 타입의 배열은 상위 타입의 배열로 취급될 수 있다.

@Test
void test_array() {
    Number[] numbers = new Number[4];
    numbers[0] = 1;
    numbers[1] = 1L;
    numbers[2] = 1.0f;
    numbers[3] = 1.0d;
}

Number와 상속 관계에 있는 Interger, Long, Float, Double을 배열에 할당할 수 있을 뿐 아니라

@Test
void test_array() {
    Integer[] integers = new Integer[10];
    Number[] numbers = integers;
}

공변성을 만족하기에 Integer[]가 Number[]로 취급될 수 있다.

@Test
void test_array() {
    Integer[] integers = new Integer[10];
    Number[] numbers = integers;

    assertThrows(ArrayStoreException.class, () -> numbers[0] = 1.0); // Heap pollution
}

그런데 다음과 같이 작성된 코드는 ArrayStoreException 예외를 발생시킨다. 그 이름에서 알 수 있듯 배열에 무언가 잘못 삽입하려고 할 때 발생하는 예외로, 선언된 타입과 할당하려는 타입이 호환되지 않을 때 발생한다. 즉, Number 배열로 참조되는 Interger 배열에 double을 삽입하면 힙 오염(Heap pollution)이 발생하므로 언어 차원에서 이를 감지하고 예외를 발생하는 것이다.

그런데 여기서 한 가지 재밌는 사실은 이러한 에러가 컴파일 시점에는 감지가 안되지만 런타임 시점에는 감지된다는 것이다. 이는 배열이 런타임에 실제 타입 정보를 유지하기에 가능한 것으로 이를 Reifiable Type이라고 한다.

자바에서 대표적인 Reifiable Type으로는 원시 타입(int, double, char...), 원시 타입의 배열(int[], double[], char[]...), 원시 타입 래퍼(Integer, Double...), 원시 타입 래퍼의 배열 (Integer[], Double[]...)이 있다. 반대로 컴파일 과정에서 타입 정보가 소거되는 Non-Reifiable Type으로는 제네릭 타입(T, List<T>)이 있다.

제네릭의 출생

제네릭을 논하기 전에, 제네릭이 없던 시절과 등장함으로써 어떤 문제들이 해결됐는지 이해해야 한다.

제네릭 이전에는 컬렉션과 같은 자료구조를 다음과 같이 사용했다.

@Test
void test_list() {
    List list = new ArrayList();
    list.add(123);
    list.add(456);
}

깔끔해(?) 보이지만 문제는 타입 안정성이 부족해서 코드를 잘못 작성하면 컴파일은 될지언정 런타임에 에러가 발생했다. 비단 타입 안정성만의 문제를 넘어 코드의 가독성 저하, 유지 보수의 어려움, 잦은 타입 캐스팅 문제도 존재했다.

 ```
    List list = new ArrayList();
    list.add(123);
    list.add("hello");
    
    for (int i = 0; i < list.size(); i++) {
        String element = (String) list.get(i);  // ClassCastException !!
        System.out.println(element);
    }
````

결국 이러한 문제를 해결하기 위해 컴파일 타임에 타입을 명시하는 제네릭이 등장함으로써 타입의 안정성을 확보하고 코드의 일반화와 재사용성 그리고 타입 캐스팅의 번거로움을 해소했다. 제네릭이 컴파일 이후에 소거되는 이유도 여기서 유추할 수 있는데, 컴파일 타임에 타입 안정성을 보장함으로써 제 역할을 다 한 제네릭이 컴파일 이후에 소거되는 것은 어느 정도 합리적이어 보인다.

제네릭의 약점

마냥 좋아 보이던 제네릭도 완벽하지는 않았다.

@Test
void test_list() {
    List<Integer> integers = new ArrayList<>();
    List<Number> numbers = new ArrayList<>();
}

위 코드는 Non-Reifiable Type 규칙에 의해 컴파일 결과가 다음과 같다.

@Test
void test_list() {
    List integers = new ArrayList<>();
    List numbers = new ArrayList<>();
}

여기서 제네릭 타입이 가진 약점이 발생하는데, 컴파일 과정에서 타입 정보가 사라지므로 앞선 배열의 예제처럼 런타임 시점에 힙 오염을 언어 차원에서 감지할 방법이 없다.

@Test
void test_list() {
    List<Integer> integers = new ArrayList<>(); // List integers
    List<Number> numbers = new ArrayList<>(); // List numbers

    numbers = integers; // compile error
    numbers.add(1.0); // List add 1.0 no problem !
}

만약 위 코드에서 컴파일 에러마저 없었다면 런타임 시점에 마지막 라인에서 힙 오염이 발생한다는 사실을 알 수 없다. 그렇다 컴파일 에러는 최후의 보루였던 것이다. 이러한 이유로 타입 간의 상속 관계가 배열에서 유지되지만 리스트는 유지되지 않고 컴파일 에러를 내뱉는다. 즉 배열은 공변성 반대로 리스트는 불공변성이란 사실을 알 수 있다.

@Test
void print_test() {
    List<Integer> integers = Arrays.asList(1, 2, 3);
    List<Long> longs = Arrays.asList(1L, 2L, 3L);
    List<Float> floats = Arrays.asList(1.0f, 2.0f, 3.0f);
    List<Double> doubles = Arrays.asList(1.0, 2.0, 3.0);

    print(integers); // compile error
    print(longs);    // compile error
    print(floats);   // compile error
    print(doubles);  // compile error
}

private void print(List<Number> numbers) {
    numbers.forEach(System.out::println);
}

예제 코드에서 볼 수 있듯 리스트의 불공변성은 다형성을 활용하지 못하는 단점으로까지 이어지는데 자바는 이러한 문제를 해결하기 위해 와일드카드 문법을 제공한다.

와일드카드

타입 안정성, 가독성, 코드의 유지 보수 증진을 위해 등장한 제네릭이 오히려 실용성이 떨어지는 상황이 생기면서 자바는 특단의 조치를 취하게 되는데 바로 와일드카드의 등장이다. 와일드카드라는 말 그대로 어떤 타입도 될 수 있으면서 동시에 알 수 없는 타입을 표현할 때 사용한다.

와일드카드의 불특정 타입이라는 개념을 활용하면 앞선 코드를 다음과 같이 수정할 수 있다.

@Test
void test_list() {
    List<Integer> integers = Arrays.asList(1, 2, 3);
    List<Long> longs = Arrays.asList(1L, 2L, 3L);

    print(integers);
    print(longs);
}

private void print(List<?> list) {
    list.forEach(System.out::println);
}

하지만 여기에는 몇 가지 제약 사항이 존재하는데 와일드카드로 선언된 컬렉션의 요소를 읽기는 가능하지만 쓰기는 불가능하다.

private void print(List<?> list) {
    list.forEach(System.out::println); // ok !
    
    list.add(new Object());
}

이는 제네릭과 와일드카드의 주요한 특성 중 하나인 타입 안정성을 보존하는 특성에서 기인한다.

list.forEach(System.out::println);와 같은 읽기 연산은 해당 타입이 구체적으로 어떤 타입인지 모르지만 적어도 Object 타입으로 반환할 수 있다. 반면 list.add(new Object());와 같은 쓰기 작업은 해당 컬렉션에 어떤 타입이 들었는지 알 수 없기에 쓰기 연산을 제한한다. 다음 예제 코드만 봐도 와일드카드에서 쓰기 연산이 불가능한 이유를 바로 이해할 수 있을 것이다.

@Test
void test_list() {
    List<Integer> integers = Arrays.asList(1, 2, 3);
    List<?> wildcards = integers;

    wildcards.add("hello world!"); // compile error!
}

제네릭과 공변성, 반공변성

와일드카드의 읽기 쓰기 문제를 해결하기 위해 자바는 한 번 더 특단의 조치를 하게 되는데, 바로 한정적 와일드카드의 등장이다.

상한 경계 와일드카드 <? extends Class>

읽기 문제부터 살펴보면, 캐스팅 안정성을 확보하려면 '최소한 어떤 타입'인지 제한할 필요가 있어 보인다. 와일드카드에 extends 키워드를 추가하면 앞서 언급한 최소한의 타입을 제한할 수 있고 이를 두고 상한 경계 와일드카드라고한다.

@Test
void test_wildcard() {
    List<? extends Number> numbers;
    numbers = new ArrayList<Integer>(); // ok!!
    numbers = new ArrayList<Number>(); // ok!!

    for (Number n : numbers) {} // ok!!
    for (Object o : numbers) {} // ok!!
    for (Integer i : numbers) {} // error!!
}

읽기는 명시된 타입과 그 부모 타입으로 가능하지만 그 외의 타입에 대해서는 실제 List<Double>을 참조할 수 있기에 Integer로 읽을 수 없고 Double도 동일한 논리로 읽기 불가능하다.

@Test
void test_wildcard() {
    List<? extends Number> list = new ArrayList<>();

    list.add(1); // error! could be List<Double>
    list.add(1.0); // error! could be List<Integer>
}

쓰기는 어떠한 타입도 불가능한데, 가령 List<Double>을 참조할 수 있기에 Integer 삽입이 불가능하고 비슷한 논리로 List<Integer>를 참조할 수 있게 Double 삽입 불가능하다.

하한 경계 와일드 카드 <? Super Class>

단순히 와일드카드를 사용 했을 때 어떠한 값도 쓰지 못했지만 super 키워드를 추가하면 제한적으로 쓰기 가능한데 이를 두고 하한 경계 와일드카드라고 한다.

@Test
void test_wildcard() {
    List<? super Integer> list;
    list = new ArrayList<Integer>();
    list = new ArrayList<Number>();
    list = new ArrayList<Object>();

    list.add(new Integer(1));
}

쓰기는 명시된 타입과 그 자식 타입으로 가능하지만 그 외의 타입에 대해서는 List<Integer>를 참조할 수 있기에 Number와 Object로는 쓰기 불가능하다.

@Test
void test_wildcard() {
    List<? super Integer> list = new ArrayList<>();

    Object o = list.get(0);
}

읽기는 기본적으로 Object로만 읽을 수 있다. 가령 List<Object>를 참조할 수 있기에 Integer와 Number로 읽기 불가능하고 오직 Object로만 읽었을 때 안정성을 보장받을 수 있기 때문이다.

여기까지 이해했다면 자연스럽게 한 가지 사실을 알 수 있는데, 바로 한정적 와일드카드의 등장으로 리스트가 공변성과 반공변성의 성질을 갖게 됐다는 것이다.

@SafeVarargs

제네릭과 가변 인수를 함께 사용하면 컴파일러가 경고를 보내는데 이제는 그 이유를 알 수 있다.

public void foo(List<String>... args) {

}

public void foo(List<String>... args)는 실제로 public void foo(List<String>[] args)와 동일하고 Non-Reifiable Type 규칙에 따라 컴파일된 최종 형태는 public void foo(List[] args)이다.

private void foo(List<String>... args) {
    Object[] objects = args; // Object[] = List[]
    objects[0] = Arrays.asList(1);

    String str = args[0].get(0); // ClassCastException !!
}

컴파일된 최종 형태를 상상하며, 타입 소거와 배열의 공변성을 교묘하게 이용하면 다음과 같이 힙 오염이 가능하므로 컴파일러가 경고를 표시할 뿐만 아니라 메서드 호출 코드에도 경고 메시지가 나타난다. 이러한 상황에 메서드에 잠재적인 위험이 없다는 것을 명시적으로 알리기 위해 @SafeVarargs 어노테이션을 사용한다.

@SafeVarargs
private void foo(List<String>... args) {
}

Java 7에 최초로 도입된 당시 생성자, static 메서드, final 메서드에만 허용됐는데 Java 9부터는 private 메서드에도 @SafeVarargs를 달아줄 수 있다.

JMH(Java Microbenchmark Harness) 사용 예제

Kangworld — Sun, 19 Nov 2023 23:17:08 +0900

JMH(Java Microbenchmark Harness)

JMH는 Java 언어로 작성된 코드의 성능을 측정하는 도구로, 특히 벤치 마이크로벤치마크를 수행하는 데 사용한다. 마이크로벤치마크는 작은 단위의 코드에 대한 경과 시간, 명령어 처리 속도 등을 측정하는 프로그램을 의미한다. 이는 성능 최적화나 코드 변경에 대한 영향을 정량적으로 측정할 때 유용하게 사용할 수 있다.

환경 설정

신뢰할 수 있는 결과를 얻기 위해서는 Maven을 사용해서 jar 파일로 빌드하고 이를 실행해서 테스트하길 권장하고 있다. IDE에서 실행하는 테스트는 결과의 신뢰성이 떨어진다는게 공식 문서의 입장이다.

샘플 maven project 생성

$ mvn archetype:generate -DinteractiveMode=false 
    -DarchetypeGroupId=org.openjdk.jmh -DarchetypeArtifactId=jmh-java-benchmark-archetype 
    -DgroupId=org.sample -DartifactId=test -Dversion=1.0

혹은 maven dependency 추가

<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-core</artifactId>
    <version>1.36</version>
</dependency>
<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-generator-annprocess</artifactId>
    <version>1.36</version>
</dependency>

jar 파일로 테스트시 plugin 추가

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>2.0</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <finalName>jmh-ex</finalName>
                <transformers>
                    <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <mainClass>org.openjdk.jmh.Main</mainClass>
                    </transformer>
                </transformers>
            </configuration>
        </execution>
    </executions>
</plugin>

예제 코드

기본적으로 JMH에서 지원하는 어노테이션 기반으로 테스트 코드를 작성하면 된다.
다음은 HashSet, TreeSet, LinkedHash의 순회 속도를 비교하는 간단한 예제이다.

@State(Scope.Benchmark)
@Fork(1)
@Warmup(iterations = 2)
@Measurement(iterations = 3, time = 1, timeUnit = TimeUnit.SECONDS)
@BenchmarkMode(Mode.AverageTime)
public class BenchmarkSet {

    private int size = 1_000_000;
    private Set<String> hashSet;
    private Set<String> treeSet;
    private Set<String> linkedHashSet;

    @Setup(Level.Invocation)
    public void setup() {
        hashSet = new HashSet<>();
        treeSet = new TreeSet<>();
        linkedHashSet = new LinkedHashSet<>();

        for (int i = 0; i < size; i++) {
            String str = UUID.randomUUID().toString();

            hashSet.add(str);
            treeSet.add(str);
            linkedHashSet.add(str);
        }
    }

    @TearDown
    public void tearDown() {
        hashSet = null;
        treeSet = null;
        linkedHashSet = null;
    }

    @Benchmark
    public String iterateHashSet() {
        Iterator<String> iterator = hashSet.iterator();
        String res = null;

        while (iterator.hasNext())
            res = iterator.next();

        return res;
    }

    @Benchmark
    public String iterateTreeSet() {
        Iterator<String> iterator = treeSet.iterator();
        String res = null;

        while (iterator.hasNext())
            res = iterator.next();

        return res;
    }

    @Benchmark
    public String iterateLinkedHashSet() {
        Iterator<String> iterator = linkedHashSet.iterator();
        String res = null;

        while (iterator.hasNext())
            res = iterator.next();

        return res;
    }

}

jar 패키징 후 실행하면

# packaging
mvn clean package

# run
java -jar target/benchmark-ex.jar

각 테스트에 대한 결과를 얻을 수 있다.

Benchmark                           Mode  Cnt     Score       Error  Units
BenchmarkSet.iterateHashSet        thrpt    3  3286.341 ±  2083.538  ops/s
BenchmarkSet.iterateLinkedHashSet  thrpt    3  6190.420 ± 11425.523  ops/s
BenchmarkSet.iterateTreeSet        thrpt    3  3402.930 ±  8328.370  ops/s

어노테이션

@State

벤치마크 메서드에서 사용할 변수를 메서드 외부에서 초기화하고 파라미터로 전달받을 수 있는데, 이때의 파라미터를 "state" 변수라고 한다. 클래스에 @State 어노테이션을 기재했을 때 유효하고 어노테이션의 모드별로 파라미터의 상태를 다르게 가져갈 수 있다.

public class MyBenchmark {

    @State(Scope.Thread)
    public static class MyState {
        public int a = 1;
        public int b = 2;
        public int sum ;
    }


    @Benchmark @BenchmarkMode(Mode.Throughput) @OutputTimeUnit(TimeUnit.MINUTES)
    public void testMethod(MyState state) {
        state.sum = state.a + state.b;
    }

}

Thread	Thread 별로 상태 객체 생성
Group	Thread 그룹별로 상태 객체 생성
Benchmark	모든 쓰레드가 동일 상태 객체 공유

@Setup, @TearDown

상태(@State) 클래스의 메서드에 기재하는 어노테이션으로, @Setup 메서드는 벤치마크가 시작되기 전에 호출되고, @TearDown 메서드는 벤치마크가 종료되고 호출된다.

public class MyBenchmark {

    @State(Scope.Thread)
    public static class MyState {

        @Setup(Level.Trial)
        public void doSetup() {
            sum = 0;
            System.out.println("Do Setup");
        }

        @TearDown(Level.Trial)
        public void doTearDown() {
            System.out.println("Do TearDown");
        }

```

@Setup과 @TearDown이 호출되는 레벨을 지정할 수 있는데 다음과 같은 옵션이 있다.

Trial	벤치마크를 실행할 때마다 호출되며 벤치마크의 실행은 fork를 의미
Iteration	벤치마크 메서드의 iteration이 돌 때마다 호출
Invocation	벤치마크 메서드가 호출될 때마다 호출

참고로 Setup이나 TearDown 작업은 벤치마크 성능 측정에 포함되지 않는다.

@Fork

벤치마크를 수행할 때 몇 번의 프로세스(= fork)를 생성할지 지정하는 데 사용한다. 여기서 fork는 독립적인 JVM에서 벤치마크를 실행하는 것을 의미한다. 예를 들어, @Fork(3)이라고 선언하면 각 벤치마크는 세 번 별도의 프로세스에서 실행되고 이렇게 실행된 결과를 취합해서 최종 성능을 계산한다. 일관성을 높이기 위해 사용되며 기본 값은 5로 설정되어 있다.

@Warmup

벤치마크를 실행하기 전에 웜업을 몇 번 수행할지 지정하는 데 사용된다. 웜업은 벤치마크 메서드가 실제 측정되기 전에 JVM을 최적화하고, JIT 컴파일러가 코드를 더 효율적으로 변환하도록 하는 작업이다.

@Measurement

벤치마크를 몇 번 반복해서 측정할지 지정하는 데 사용된다. 측정은 실제 벤치마크 측정이 수행되는 단위를 말한다. 예를 들어, 다음과 같이 기재하면 벤치마크 메서드를 3회 반복하고 측정을 1초 동안 수행한다.

@Measurement(iterations = 3, time = 1, timeUnit = TimeUnit.SECONDS)

@BenchmarkMode

벤치마크 결과를 어떤 형태로 측정할지 결정하는 어노테이션으로, 다음과 같은 옵션을 제공한다.

Throughput	1초당 얼마나 많은 작업을 수행하지는 측정
AverageTime	평균 실행 시간 측정
SampleTime	최대, 최소 시간등을 포함한 시간 측정
SingleShotTime	메서드 단일 실행 시간 측정 (JVM 워밍업 없이 cold start에 유용하게 사용)
All	모든 모드를 측정한다.

IDE에서 직접 실행한다면 다음과 같이 main 메서드를 작성하고 실행한다.

@State(Scope.Benchmark)
public class BenchmarkSet {
    ```
    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(BenchmarkSet.class.getSimpleName())
                .forks(1)
                .warmupIterations(2)
                .measurementIterations(2)
                .measurementTime(TimeValue.seconds(1))
                .timeUnit(TimeUnit.SECONDS)
                .mode(Mode.AverageTime)
                .build();

        new Runner(opt).run();
    }
}

Dead Code 제거

Dead Code란 프로그램의 실행 흐름에서 실제 사용되지 않는 코드를 의미한다. 성능 측정 도중에는 이러한 Dead Code가 JIT 컴파일러에 의해 최적화되어 벤치마크 결과가 왜곡될 수 있다. 예를 들어, JVM이 어떤한 계산 결과가 전혀 사용되지 않음을 알면 코드를 제거할 수 있는데 아래 코드가 이에 해당한다.

public class MyBenchmark {

    @Benchmark
    public void testMethod() {
        int a = 1;
        int b = 2;
        int sum = a + b;
    }

}

JVM은 sum에 할당된 값이 전혀 사용되지 않음을 감지하고 데드 코드로 간주해서 int sum = a + b; 코드를 제거한다. 결과적으로 a와 b의 사용처가 사라지면 자연스럽게 이 변수들도 마찬가지로 데드 코드로 간주되어 메서드에는 어떠한 코드도 남아있지 않게 되면서 벤치마크의 결과를 신뢰할 수 없게 된다.

여기엔 두 가지 해결 방안이 있는데

첫째는 계산 결과를 벤치마크 메서드 반환값으로 사용하는 것이고

둘째는 JMH에서 제공하는 Blackhole을 사용하는 것이다.

메서드 반환값으로 사용

다음과 같이 계산된 값을 반환하면 호출하는 쪽에서 값을 사용할 수 있으니 JVM이 코드를 삭제하는 불상사는 없어진다.

만약 데드 코드로 제거될 수 있는 여러 값을 만드는 경우 값을 담는 컨테이너 객체를 만들어서 반환해야 한다.

public class MyBenchmark {

    @Benchmark
    public int testMethod() {
        int a = 1;
        int b = 2;
        int sum = a + b;

        return sum;
    }
}

Blackhole

JMH에서 제공하는 Blackhole은 계산 결과를 "소비(consume)" 하는데 사용되는 클래스로 다음과 같이 사용한다.

public class MyBenchmark {

   @Benchmark
   public void testMethod(Blackhole blackhole) {
        int a = 1;
        int b = 2;
        int sum = a + b;
        blackhole.consume(sum);
    }
}

Blackhole을 메서드의 매개변수로 받고 blackhole.consume(result)과 같이 결과를 소비하는 형태로 사용한다. 이렇게 하면 벤치마크에서 계산한 결과를 실제로 사용하지 않더라도 JIT 최적화 등을 방지해서 벤치마크 결과가 왜곡되지 않도록 한다.

[2023.11.12] 생존

Kangworld — Sun, 12 Nov 2023 22:47:44 +0900

2023.04.14 금요일

몸 푸는 추신수

승요답게 경기는 승리

2023.06.04 일요일

어느 한적한 도시의 자라 거북이

너무 빤질거려서 모형인 줄

2023.09.30 토요일

올해도 어김없이 자란 엄빠 밭의 롬복

매웠다

한동안 블로그 활동을 안 했다

회사일도 바빴지만

블로그를 대하는 내 태도가 불량해졌다.

어느 순간 글 쓰는 게 조금 귀찮고 부담스럽달까...

마음은 조금씩 떠나갔지만

공부는 꾸준히 해왔고

조만간 다시 끄적이겠다는 다짐은 있었는데

이렇게 길어질지 몰랐다.

어떤 개념을 잘 정리해서 퍼블릭한 공간에 올리는 것과

그냥 머릿속에 저장하는 건

지식을 대하는 태도나 이해하는 측면에서 깊이가 다른 것 같다.

그런 의미에서 다시 블로그의 필요성을...

[리팩토링] 악취 25 : 주석

Kangworld — Thu, 16 Feb 2023 15:19:54 +0900

✍️ 악취 25 : 주석

주석이 많다는 것은 코드에 악취가 많다는 방증이기도 하다. 주석이 많이 달린 코드를 리팩토링의 대상으로 선정해서 리팩토링을 적용한다면 코드가 가진 문제점을 해결하면서 동시에 주석이 필요 없어질 수도 혹은 주석의 내용이 간결하고 명확해질 수 있다.

주석이 많이 달린 코드 뭉치는 '함수 추출하기'를 사용해서 별도의 메서드로 분리할 수 있고, 장황하고 긴 이름의 메서드는 '함수 선언부 변경하기'를 적용할 수 있다. 주석에 명시된 시스템의 규약을 '어서션 추가하기'로 변경할 수도 있다.

여기 주석 악취를 해결하기 위한 세 가지 리팩토링 기법이 있다.

1. "함수 추출하기" 주석이 달린 코드 뭉치가 있다면

2. "함수 선언부 변경하기" 주석이 달린 장황하고 긴 이름을 가진 메서드가 있다면

3. "어서션 추가하기" 시스템의 규약을 코드로 표현하기

본 포스팅에서 관심 있게 살펴볼 리팩토링은 시스템의 규약을 주석이 아닌 코드로 표현하는 '어서션 추가하기'이다.

어서션 추가하기

코드로 표현하지는 않았지만 기본적으로 가정하고 있는 조건들이 있다. 그런 조건은 코드를 이해하거나 '주석'을 읽으면서도 확인할 수 있지만 Assertion을 보고 직관적으로 이해하는 방법도 있다.

Assertion은 if나 switch와 달리 '항상' true를 기대하는 조건을 표현할 때 사용된다. 개발 과정에서 Assertion에서 실패한다면 프로그래머의 실수로 판단해서 논리적인 오류에 대응하거나 방어 코드를 작성할 수 있다.

주석으로 작성된 규약을 Assertion으로 변경할 수 있다.

public class Customer {

    /**
     * discountRate은 0 보다 커야한다.
     */
    private double discountRate;

    public Customer(double discountRate) {
        this.discountRate = discountRate;
    }

    public double applyDiscount(double amount) {
        return amount - (this.discountRate * amount);
    }
}

Assertion 적용

* Assertion은 별도의 옵션이 없다면 런타임에 조건을 체크하지 않으며 오버헤드가 있기에 상용 코드에선 포함하지 않고 개발 코드에서만 사용하는 것을 권장한다. 따라서 개발 과정에서 Assertion으로 시스템의 홀을 발견했다면 Assertion을 제거하고 반드시 논리적 오류를 수정하거나 방어 코드로 변경해야 한다.

public class Customer {

    private double discountRate;

    public Customer(double discountRate) {
        assert discountRate > 0;

        this.discountRate = discountRate;
    }

    public double applyDiscount(double amount) {
        return amount - (this.discountRate * amount);
    }

}

// 방어 코드 추가
public Customer(double discountRate) {
    if(discountRate <= 0)
        throw new IllegalArgumentException();

    this.discountRate = discountRate;
}

[리팩토링] 악취 24 : 상속 포기

Kangworld — Wed, 15 Feb 2023 23:13:45 +0900

✍️ 악취 24 : 상속 포기

서브 클래스에 필드와 메서드가 빈약하다면 서브 클래스가 가져야 할 필드나 메서드를 슈퍼클래스에서 가지고 있을 확률이 크다. 서브 클래스를 제거하거나 서브 클래스로 '필드/메서드 내려주기'를 적용하면 문제는 해결된다.

만약 서브 클래스가 슈퍼 클래스의 기능은 재사용 하고 싶지만 인터페이스가 가진 규약은 따르고 싶지 않다면 '슈퍼 클래스 또는 서브 클래스를 위임으로 변경하기'를 고려해야 한다.

여기 상속 포기 악취를 해결하기 위한 두 가지 리팩토링 기법이 있다.

1. '필드/메서드 내려주기'

2. '슈퍼 클래스 또는 서브 클래스를 위임으로 변경하기'

필드/메서드 내려주기

슈퍼 클래스에서 할당량(Quota)를 선언했고 서브 클래스가 이를 상속을 받는 구조이다.

public class Employee {

    protected Quota quota;

    protected Quota getQuota() {
        return new Quota();
    }

}

public class Engineer extends Employee {

}

public class Salesman extends Employee {

}

Salesman만 할당량(Quota)을 필요로 한다면 슈퍼 클래스 과도한 책임이므로 필드와 메서드를 내려준다.

public class Employee {

}

public class Salesman extends Employee {

    protected Quota quota;

    protected Quota getQuota() {
        return new Quota();
    }
}

public class Engineer extends Employee {

}

슈퍼 클래스 또는 서브 클래스를 위임으로 변경하기

슈퍼 클래스가 가진 기능을 재사용하고 싶지만 인터페이스가 가진 규악은 따르고 싶지 않다면 상속 구조를 위임으로 변경할 수 있다. List를 상속받아 구현한 Stack vs List를 위임해서 구현한 Stack이 그 대표적인 예시이다.

List의 get은 인덱스 기반으로 동작하는 반면 Stack의 peek은 최상위 엘리먼트에 대해서 동작한다. Stack 입장에선 List가 제공하는 기능을 재사용하고 싶지만 peek만 보더라도 본래의 기능적 규약을 위반했다.

public class SimpleList {

    protected List<Integer> list = new ArrayList<>();

    public boolean add(int value) {
        return list.add(value);
    }

    public int get(int index) {
        return list.get(index);
    }
    
    ...
}

public class SimpleStack extends SimpleList {

    ...
    
    public int peek() {
        if (isEmpty())
            throw new RuntimeException();

        return get(size() - 1);
    }

    public int pop() {
        if (isEmpty())
            throw new RuntimeException();

        return remove(size() - 1);
    }
}

인터페이스가 가진 기능적 규약을 지키기 어렵다면 과감히 상속을 버리고 위임으로 변경하는 것을 고려해야 한다.

public class SimpleStack {

    private SimpleList list = new SimpleList();

    ...
    
    public int peek() {
        if (list.isEmpty())
            throw new RuntimeException();

        return list.get(size() - 1);
    }

    ...
}

[리팩토링] 악취 23 : 데이터 클래스

Kangworld — Tue, 14 Feb 2023 09:08:34 +0900

✍️ 악취 23 : 데이터 클래스

필드와 getter/setter만 가지는 클래스를 '데이터 클래스'라고 한다. 데이터 클래스의 존재는 코드의 위치가 적절하지 않다는 방증이기도 한데, 일반적으로 필드와 필드를 사용하는 메서드는 한 클래스에 모아서 최소한의 정보만 노출하며 제 기능을 제공해야 하기 때문이다. 다만 예외적으로 데이터 전달을 위한 용도라면 필드와 getter 만으로 클래스를 작성할 수 있다.

public 필드를 가지고 있다면 '레코드 캡슐화하기'를 적용해 보고, 불필요하게 공개된 필드는 'getter 제거하기'를 변경되지 않아야 할 필드에는 'setter 제거하기'를 통해 외부로 공개되는 정보는 최소화하고 클래스가 제공하는 기능에만 집중하도록 유도할 수 있다. 파편화된 필드와 메서드를 한 클래스로 모으기 위해 '함수 추출하기'와 '함수 옮기기'도 적용할 수 있다.

여기 데이터 클래스 악취를 해결하기 위한 세 가지 리팩토링 기법이 있다.

1. "레코드 캡슐화하기" public 필드가 있다면

2. "getter/setter 제거하기" 불필요한 공개와 수정을 제거

3. "함수 추출하기/옮기기" 파편화된 필드와 메서드를 한 곳으로

본 포스팅에서 관심 있게 살펴볼 리팩토링은 public 필드를 제거하기 위한 '레코드 캡슐화하기'이다.

레코드 캡슐화하기

리팩토링의 저자 마틴 파울러는 다음과 같은 클래스를 '레코드'라고 정의했다.

레코드란 public 필드로 구성된 클래스를 말한다.

외부의 누구나 필드를 직접 참조하고 동시에 수정 가능하다면 객체의 상태를 예측하기 어려워 문제가 발생할 여지가 많아진다. 이런 경우 캡슐화를 적용해서 허용된 메서드로만 값을 참조하고 수정하도록 제어한다면 객체의 상태를 보다 수월하게 관리하고 추적할 수 있다.

레코드 클래스

//before
public class Organization {

    public String name;

    public String country;

}

getter/setter 메서드가 필드를 감추는 목적도 있지만 내부에 로직을 작성함으로써 추상화의 이점도 가져갈 수 있다.

//after
@Getter
@AllArgsConstructor
public class Organization {

    public String name;

    public String country;

    public void setCountry(String country) {
        if (country == null || country.isEmpty())
            throw new IllegalArgumentException();

        this.country = country.toLowerCase();
    }
}

[리팩토링] 악취 22 : 서로 다른 인터페이스의 대안 클래스 *

Kangworld — Mon, 13 Feb 2023 16:06:26 +0900

✍️ 악취 22 : 서로 다른 인터페이스의 대안 클래스

유사한 기능과 목적을 가진 클래스가 서로 다른 인터페이스를 구현하고 있다면 그 목적은 유사할지언정 상호 대체가 불가능한 구조로, 다르게 말하면 다형성을 활용할 수 없는 문제점이 발생한다. 비슷한 일을 서로 다른 규악으로 지원한다면 관리 문제도 발생한다.

중복된 인터페이스를 제거하고 '함수 선언 변경하기'와 '함수 옮기기'를 사용해서 하나의 인터페이스만을 구현하도록 구조를 변경할 수 있다. 하지만 인터페이스를 수정할 수 없는 상황도 존재한다. 외부 모듈 혹은 라이브러리를 참조하는 케이스가 그 대표적인 예시이다. 본 포스팅에선 인터페이스의 수정이 불가능한 상황에서 리팩토링을 적용하는 예제를 소개하려 한다.

예제 : 적용 전

가정해 봅시다. '이메일을 전송하는 기능'과 '알람을 전송하는 기능'이 서로 다른 인터페이스로 정의되었음을.

public interface EmailService {

    void sendEmail(EmailMessage emailMessage);
}

public interface AlertService {

    void add(AlertMessage alertMessage);
}

public class EmailMessage {

    private String title;
    private String to;
    private String from;
}


public class AlertMessage {

    private String message;
    private String to;
}

비슷하지만 서로 다른 인터페이스로 그 기능을 제공하고 있다면 다형성을 활용할 수 없고 관리가 어렵다는 문제가 있다.

public class OrderManager {

    private AlertService alertService;

    public void alertOrder(Order order) {
        AlertMessage alertMessage = AlertMessage.builder()
                .message(order.getOrder() + "is ordered")
                .to(order.getEmail())
                .build();

        alertService.add(alertMessage);
    }
    
}

public class ShippingManager {

    private EmailService emailService;

    public void notifyShipping(Shipping shipping) {
        EmailMessage emailMessage = EmailMessage.builder()
                .title(shipping.getOrder() + "is shipped")
                .to(shipping.getEmail())
                .from("no-reply@knagworld.co.kr")
                .build();

        emailService.sendEmail(emailMessage);
    }

}

예제 : 적용 후

인터페이스를 변경하는 것이 베스트지만, 그렇지 못한 케이스에선 '어댑터 패턴'을 적용하는 것도 하나의 방법이 될 수 있다.

Order와 Shipping을 감싸는 인터페이스를 정의한다.

public interface Notification {
}

각각의 구현체는 AlertMessage와 EmailMessage를 제공한다.

@AllArgsConstructor
public class AlertNotification implements Notification {

    private Order order;

    public AlertMessage toAlertMessage() {
        return AlertMessage.builder()
                .message(order.getOrder() + " is ordered")
                .to(order.getEmail())
                .build();
    }
}

@AllArgsConstructor
public class EmailNotification implements Notification {

    private Shipping shipping;

    public EmailMessage toEmailMessage() {
        return EmailMessage.builder()
                .title(shipping.getOrder() + " is shipped")
                .from("no-reply@kangworld.co.kr")
                .to(shipping.getEmail())
                .build();
    }
}

클라이언트는 추상화된 Notification과 NotificationService 만으로 코드를 전개하고, 구체적인 AlertMessage와 AlertService, EmailMessage와 EmailService는 구현체에서 처리하도록 변경한다.

public interface NotificationService {

    void sendNotification(Notification notification);
}

public class OrderManager {

    private NotificationService notificationService;

    public void alertOrder(Order order) {
        Notification notification = new AlertNotification(order);

        notificationService.sendNotification(notification);
    }
}

public class AlertNotificationService implements NotificationService {

    private AlertService alertService;

    @Override
    public void sendNotification(Notification notification) {
        AlertNotification alertNotification = (AlertNotification) notification;

        alertService.add(alertNotification.toAlertMessage());
    }

}

[리팩토링] 악취 21 : 거대한 클래스

Kangworld — Sun, 12 Feb 2023 22:26:33 +0900

✍️ 악취 21 : 거대한 클래스

어떤 클래스가 하는 일이 너무 많아지면 필드도 많아지고 필드를 사용하는 메서드도 많아진다. 시간이 지날수록 내부 코드의 결합도는 증가하고 한 클래스에 너무 많은 일을 담당하니 코드를 이해하기도 수정하기도 어려워진다. 단일 책임 원칙을 고수하라는 이유도 바로 이런 문제점 때문이다.

여러 클라이언트가 공통적으로 호출하는 메서드가 있다면 '함수 추출하기'를 만약 여기에 항상 같이 사용되는 변수까지 있다면 '클래스 추출하기'로 리팩토링을 확장할 수 있다. 여러 클래스에 중복된 필드와 중복된 메서드가 있다면 상속을 사용한 '슈퍼 클래스 추출하기'를 적용할 수 있다.

여기 거대한 클래스를 해결하기 위한 두 가지 리팩토링 기법이 있다.

1. "함수 추출하기, 클래스 추출하기" 공통된 요소들이 존재한다면

2. "슈퍼 클래스 추출하기" 여러 클래스에 공통된 요소들이 존재한다면

본 포스팅에서 관심 있게 살펴볼 리팩토링은 '슈퍼 클래스 추출하기'이다.

슈퍼 클래스 추출하기

두 개 이상의 클래스에서 비슷한 요소(필드, 메서드)가 존재한다면 상속을 적용하고, 슈퍼 클래스로 '필드 올리기'와 '메서드 올리기'를 적용할 수 있다.

Department와 Employee 모두 'name' 필드와 '월간, 연간 비용' 계산 메서드라는 비슷한 요소가 존재한다.

public class Department {

    private String name;

    private List<Employee> staff;

    public double totalMonthlyCost() {
        return staff.stream().mapToDouble(Employee::getMonthlyCost).sum();
    }

    public double totalAnnualCost() {
        return totalMonthlyCost() * 12;
    }
}

public class Employee {

    private Integer id;

    private String name;

    private double monthlyCost;

    public double annualCost() {
        return monthlyCost * 12;
    }
}

두 클래스의 슈퍼 클래스를 정의해서 중복되는 요소를 제거해 보자.
연간 비용을 구하는 로직은 두 클래스 동일하다. 다만 월간 비용을 구하는 로직이 서로 다르기에 그 구현을 서브 클래스에 위임했다. 일종의 팩토리 메서드 패턴이 적용된 케이스이다.

public abstract class Party {

    public String name;

    public abstract double getMonthlyCost();

    public double annualCost() {
        return getMonthlyCost() * 12;
    }
}

public class Department extends Party {

    private List<Employee> staff;

    public Department(String name, List<Employee> staff) {
        super(name);
        this.staff = staff;
    }

    @Override
    public double getMonthlyCost() {
        return staff.stream().mapToDouble(Employee::getMonthlyCost).sum();
    }
}

@Getter
public class Employee extends Party {

    private Integer id;

    private double monthlyCost;

    public Employee(String name, Integer id, double monthlyCost) {
        super(name);
        this.id = id;
        this.monthlyCost = monthlyCost;
    }
}

[리팩토링] 악취 20 : 내부자 거래

Kangworld — Sat, 11 Feb 2023 22:13:32 +0900

✍️ 악취 20 : 내부자 거래

어떤 모듈이 다른 모듈의 정보를 지나치게 많이 알고 있다면 혹은 모듈이 지나치게 많은 것을 공개하고 있다면 강한 결합도가 발생할 수 있다. 이 중에서도 다른 모듈의 정보를 지나치게 많이 알고 있는 상황을 '내부자 거래'라고 한다.

다른 모듈의 정보를 지나치게 많이 요구한다면 필드나 메서드의 위치가 적절한지 생각해 보고 '함수 옮기기' 혹은 '메서드 옮기기' 리팩토링을 적용할 수 있다. 다른 여러 모듈에서도 동일한 현상이 발생한다면 자주 요구되는 필드와 메서드 혹은 클래스를 '별도의 모듈로 분리' 할 수 있다. 동시에 정보를 최대한 감추기 위해 '위임 숨기기' 도 적용할 수 있다.

여기 내부자 거래 악취를 해결하기 위한 세 가지 리팩토링 기법이 있다.

1. "함수/메서드 옮기기" 적절한 위치로 옮겨서 캡슐화하기

2. "모듈로 분리하기" 여러 모듈의 참조를 캡슐화된 한곳에서 제공하기 위해

3. "위임 숨기기" 최소한의 정보만을 공개하기 위해

본 포스팅에서 관심있게 살펴볼 리팩토링은 "함수/메서드 옮기기"이다.

함수 옮기기

티켓의 FastPass 조건을 검사할 때 CheckIn이 티켓의 너무 많은 정보를 알아야 한다.

@AllArgsConstructor
@Getter
public class Ticket {

    private DateTime purchasedDate;
    private boolean isPrime;

}

public class CheckIn {

    public boolean isFastPass(Ticket ticket) {
        DateTime earlyBirdDate = new DateTime(2022, 1, 1, 0, 0);
        return ticket.isPrime() && ticket.getPurchasedDate().isBefore(earlyBirdDate);
    }
}

클라이언트에 너무 많은 정보를 제공하고 있음은 메서드의 위치가 적절하지 않다는 방증이기도 하다. FastPass 여부를 Ticket의 책임으로 전환하자.

@AllArgsConstructor
public class Ticket {

    public static final DateTime EARLY_BIRD_END_DATE = new DateTime(2000, 1, 1, 0, 0);

    private DateTime purchasedDate;
    private boolean isPrime;

    public boolean isFastPass() {
        return isPrime && purchasedDate.isBefore(EARLY_BIRD_END_DATE);
    }

}

[리팩토링] 악취 19 : 상속 (2)

Kangworld — Fri, 10 Feb 2023 20:08:34 +0900

✍️ 악취 19 : 상속

객체지향에서 상속은 코드 재사용과 기능 확장이라는 장점이 있지만 상속이 적절하지 않은 케이도 분명 있다.
서브 클래스는 슈퍼 클래스의 모든 기능을 지원해야 한다.(List를 상속받는 Stack이 적절한가?)
서브 클래스는 슈퍼 클래스가 가진 기능적 규약을 위반해선 안 된다. (리스코프 치환 원칙)
서브 클래스는 슈퍼 클래스의 변경에 취약한 다르게 말하면 둘의 결합도가 매우 높다.
무엇보다 다중 상속이 불가능하다.

상속은 매우 유용한 기능이지만 적절하지 못한 구조라고 판단하면 위임의 형태로 변경하는 것이 유용할 때가 있다.

여기 상속 악취를 해결하기 위한 두 가지 리팩토링 기법이 있다.

1. "슈퍼 클래스를 위임으로 변경하기"

2. "서브 클래스를 위임으로 변경하기"

본 포스팅에서 관심있게 살펴볼 리팩토링은 "서브 클래스를 위임으로 변경하기"이다.

서브 클래스를 위임으로 변경하기

객체가 특정 상황에 예외적인 로직을 수행한다면 보통은 상속을 사용해서 일반적인 로직은 슈퍼 클래스에, 예외적인 로직은 서브 클래스에 작성한다. 하지만 상속은 반드시 한 클래스로부터만 받을 수 있기에 시간이 지남에 따라 슈퍼 클래스가 다른 클래스로 대체될 수 있다. 이처럼 상속 구조에서 상속이 아닌 구조로 변경해야할 위임을 사용할 수 있다.

Customer 클래스와 이를 상속받아 기능을 확장한 VipCustomer가 있다.

@AllArgsConstructor
@Getter
public class Customer {

    protected int id;

    /**
     * 장기 고객
     */
    protected boolean isLongTermCustomer;

    /**
     * 멤버십 보유 여부
     */
    protected boolean hasMembership;

    public boolean canUseRoomService(){
        return isLongTermCustomer && hasMembership;
    }

    public double discountRate() {
        double discount = 0.1;
        if (hasMembership)
            discount += 0.1;

        return discount;
    }
}

public class VipCustomer extends Customer {

    private VipBenefit benefit;

    public VipCustomer(int id, boolean isLongTermCustomer, boolean hasMembership, VipBenefit benefit) {
        super(id, isLongTermCustomer, hasMembership);

        this.benefit = benefit;
    }

    @Override
    public boolean canUseRoomService() {
        return isLongTermCustomer || hasMembership;
    }

    @Override
    public double discountRate() {
        return super.discountRate() + benefit.getExtraDiscount();
    }

    public boolean canUsePrivateRoom() {
        return benefit.getAccessibleSpace().contains("PrivateRoom");
    }
}

@AllArgsConstructor
@Getter
public class VipBenefit {

    private double extraDiscount;

    private List<String> accessibleSpace;
}

만약 VipCustomer가 Customer 상속을 포기해야한다면 위임(Delegate)으로 대체할 수 있다. 기존 VipCustomer의 로직을 실행할 대리인 VipCustomerDelegate를 생성한다.

@AllArgsConstructor
@Getter
public class VipCustomerDelegate {

    private VipBenefit benefit;

    public boolean canAccessLounge(boolean isLongTermCustomer, boolean hasMembership) {
        return isLongTermCustomer || hasMembership;
    }

    public double discountRate(double baseRate) {
        return baseRate + benefit.getExtraDiscount();
    }

    public boolean canUsePrivateRoom() {
        return benefit.getAccessibleSpace().contains("PrivateRoom");
    }
}

대리인 VipCustomerDelegate를 Customer에 추가해서 delegate가 존재하면 작업을 위임하고 없다면 본 로직을 수행한다.

@AllArgsConstructor
@Getter
public class Customer {

    private int id;

    private boolean isLongTermCustomer;

    private boolean hasMembership;

    /**
     * 서브 클래스를 위임으로
     */
    private VipCustomerDelegate delegate;

    public static Customer createCustomer(int id, boolean isLongTermCustomer, boolean hasMembership) {
        return new Customer(id, isLongTermCustomer, hasMembership);
    }

    public static Customer createCustomer(int id, boolean isLongTermCustomer, boolean hasMembership, VipBenefit benefit) {
        Customer customer = new Customer(id, isLongTermCustomer, hasMembership);
        customer.delegate = new VipCustomerDelegate(benefit);

        return customer;
    }

    public Customer(int id, boolean isLongTermCustomer, boolean hasMembership) {
        this.id = id;
        this.isLongTermCustomer = isLongTermCustomer;
        this.hasMembership = hasMembership;
    }

    public boolean canAccessLounge() {
        return delegate != null ? delegate.canAccessLounge(isLongTermCustomer, hasMembership)
                : isLongTermCustomer && hasMembership;
    }

    public double discountRate() {
        double discount = 0.1;
        if (hasMembership)
            discount += 0.1;

        return delegate != null ? delegate.discountRate(discount) : discount;
    }

    public boolean canUsePrivateRoom() {
        return delegate != null ? delegate.canUsePrivateRoom() : false;
    }
}

[리팩토링] 악취 19 : 상속 (1)

Kangworld — Thu, 9 Feb 2023 18:54:55 +0900

✍️ 악취 19 : 상속

상속은 매우 유용한 기능이지만 적절하지 못한 구조라고 판단하면 위임의 형태로 변경하는 것이 유용할 때가 있다.

여기 상속 악취를 해결하기 위한 두 가지 리팩토링 기법이 있다.

1. "슈퍼 클래스를 위임으로 변경하기"

2. "서브 클래스를 위임으로 변경하기"

본 포스팅에서 관심있게 살펴볼 리팩토링은 "슈퍼 클래스를 위임으로 변경하기"이다.

슈퍼 클래스를 위임으로 변경하기

서브 클래스는 슈퍼 클래스의 모든 기능을 지원해야 한다. 슈퍼 클래스의 일부 기능만 지원한다면 상속 구조가 올바른지 의심해야 한다. List를 상속받은 Stack 구현이 그 대표적인 예시이다.

심플한 형태의 List 클래스 add, get, remove, isEmpty를 메서드를 지원한다.

public class SimpleList {

    protected List<Integer> list = new ArrayList<>();

    public boolean add(int value) {
        return list.add(value);
    }

    public int get(int index) {
        return list.get(index);
    }

    public int remove(int index) {
        return list.remove(index);
    }

    public int size() {
        return list.size();
    }

    public boolean isEmpty() {
        return list.isEmpty();
    }
}

SimpleList를 상속한 SimpleStack 클래스도 기본적인 연산 push, peek, pop을 제공한다.

public class SimpleStack extends SimpleList {

    public int push(int value) {
        add(value);

        return value;
    }

    public int peek() {
        if (isEmpty())
            throw new RuntimeException();

        return get(size() - 1);
    }

    public int pop() {
        if (super.isEmpty())
            throw new RuntimeException();

        return remove(size() - 1);
    }
}

그렇다면... SimpleStack이 SimpleList를 상속받는 게 올바를까?
Stack은 최상위 엘리먼트를 타깃으로 연산을 하기 때문에 SimpleList의 인덱스 기반 메서드가 온전한 방향으로 사용되고 있다고 보긴 어렵다. 다르게 말하면 슈퍼 클래스의 모든 기능을 지원하지 않는 케이스에 해당하고 러프하게 보면 리스코프 치환 원칙에도 위배된다.

이처럼 상속 구조가 올바르지 못한 구조라고 판단이 되면 상속을 '위임'으로 변경할 수 있다.

public class SimpleStack {

    private SimpleList list = new SimpleList();

    public int push(int value) {
        list.add(value);

        return value;
    }

    public int peek() {
        if (list.isEmpty())
            throw new RuntimeException();

        return list.get(size() - 1);
    }

    public int pop() {
        if (list.isEmpty())
            throw new RuntimeException();

        return list.remove(size() - 1);
    }

    public int size() {
        return list.size();
    }

    public boolean isEmpty() {
        return list.isEmpty();
    }
}

[리팩토링] 악취 18 : 중재자

Kangworld — Wed, 8 Feb 2023 15:42:44 +0900

✍️ 악취 18 : 중재자

메서드 호출을 위해 중간에 거쳐가는 존재를 말 그대로 중재자라고 한다. 구조에 따라서 중재자가 필요할 수도 불필요할 수도 있다. 다만 과도한 위임이 발생해서 메서드 호출마다 항상 중재자를 거쳐가야 한다면 중재자를 제거하는 방향으로 리팩토링할 수 있다.

여기 중재자 악취를 해결하기 위한 리팩토링 기법이 있다.

1. "중재자 제거하기" 중재자를 거치지 않고 클라이언트가 직접 객체를 사용하기

중재자 제거하기

'중재자 제거하기'는 캡슐화를 제거하고 메시지 체인을 사용한단 의미에서 '위임 숨기기'와 반대된다. 오히려 위임을 드러내는 리팩토링이다.

* 개인적으로 메시지 체인보단 캡슐화로 필요한 정보만 제공하는것이 더 객체지향스럽다고 생각한다. 실제로도 대부분의 업무에선 캡슐화를 하는 쪽이 절대 다수였다. 다만 예외적인 상황은 존재한다. 예를들어, 내부 객체에 필드가 추가되면 중재자 메서드도 함께 추가돼야한다. 즉, 필드가 추가될때마다 중재자 메서드도 선형적으로 증가하는 케이스라면 위임을 제거하기도 했다.
* 결론! 캡슐화의 정도에 따라 "중재자 제거하기"와 "위임 숨기기"를 적절히 조절하는 것을 고려하자.

클라이언트가 Person의 Information에 직접 접근하는 것을 감추고자 위임 숨기기를 적용한 케이스.

@AllArgsConstructor
public class Person {

    @Getter
    private int personId;
    private Information info;

    // 중재자
    public String getName() {
        return info.getName();
    }
    
    // 중재자
    public String getAddress() {
        return info.getAddress();
    }
}

@AllArgsConstructor
@Getter
public class Information {

    private String name;
    private String address;
}

class PersonTest {
    
    @Test
    void test() {
        Person person = new Person(1, new Information("kang", "seoul"));
        String address = person.getAddress();

        assertEquals("seoul", address);
    }
}

반대로 위임이 과도하고 클라이언트가 메시지 체인 구조를 알아도 무방하다고 판단되면 중재자를 제거하고 메시지 체인을 사용하도록 변경할 수 있다.

@AllArgsConstructor
@Getter
public class Person {

    private int personId;
    private Information info;
}

class PersonTest {

    @Test
    void test() {
        Person person = new Person(1, new Information("kang", "seoul"));
        String address = person.getInfo().getAddress();

        assertEquals("seoul", address);
    }
}

[리팩토링] 악취 17 : 메시지 체인

Kangworld — Tue, 7 Feb 2023 11:00:39 +0900

✍️ 악취 17 : 메시지 체인

객체에 메시지를 전달해서 기능을 수행한단 의미에서 '메시지란 메서드 호출'을 의미한다. 즉, 메시지 체인이란 연속된 메서드 호출을 의미한다.

// 메시지 체인
person.getInfo().getAddress();

메시지 체인이 리팩토링의 대상이 되는 이유는 클라이언트가 메서드 호출을 위해 너무 많은 것을 알아야 한다는 것이다.

가령 클라이언트는 Person에 Info 필드가 있고, Info에 Address 필드가 존재함을 이해해야 하만 원하는 정보를 얻을 수 있기 때문이다. 심지어 체인 구조가 변경되면 모든 클라언트의 코드가 변경된다는 단점도 존재한다.

여기 메시지 체인을 해결하기 위한 두 가지 리팩토링 기법이 있다.

1. "위임 숨기기" 메시지 체인을 캡슐화하기

2. "함수 추출하기, 함수 옮기기" 메시지 체인을 함수로 추출하고, 적절한 위치로 함수 옮기기

본 포스팅에서 관심 있게 살펴볼 리팩토링은 '위임 숨기기'이다.

위임 숨기기

메시지 체인은 위임 숨기기를 통해서 끊어낼 수 있다. 위임 숨기기는 일종의 캡슐화에 해당하는 방식으로, 클라이언트에게 최소한의 정보만을 제공하기 위해 사용된다.

* 캡슐화란 클래스의 필드와 메서드를 감싸서 최소한의 정보만을 제공하는 정보 은닉 개념이다. 클래스가 불필요하게 많은 정보를 외부에 제공하면 원하지 않은 방향으로 데이터가 조작될 수 있고, 작은 수정만으로도 클라이언트 코드의 많은 수정이 요구될 수 있다.

필드를 private으로 선언한다든지, 필드에 접근은 getter/setter로만 제어하는 방식이 캡슐화의 일종이다. 그뿐만 아
니라, 객체지향에서 캡슐화를 배울 때, 필드만 캡슐화의 대상인 듯 말하지만, 메서드 자체도 캡슐의 대상이 된다.

클라이언트가 Person의 Address를 알기 위해선 반드시 Info의 존재를 알아야한다.

// before
@AllArgsConstructor
@Getter
public class Person {

    private int personId;
    private Information info;
}


@AllArgsConstructor
@Getter
public class Information {

    private String name;
    private String address;
}

class PersonTest {

    @Test
    void test() {
        Person person = new Person(1, new Information("kang", "seoul"));
        String address = person.getInfo().getAddress();

        assertEquals("seoul", address);
    }
}

위임을 숨긴다면 클라이언트는 getAddress만 알아도 Address를 알 수 있다. 메시지 체인의 구조 변경과 같은 내부 구현이 변경되더라도 클라이언트 코드는 그대로 유지되는 장점도 있다.

// after
@AllArgsConstructor
public class Person {

    @Getter
    private int personId;
    private Information info;

    public String getAddress() {
        return info.getAddress();
    }
}

class PersonTest {

    @Test
    void test() {
        Person person = new Person(1, new Information("kang", "seoul"));
        String address = person.getAddress();

        assertEquals("seoul", address);
    }
}

[리팩토링] 악취 16 : 임시 필드 *

Kangworld — Mon, 6 Feb 2023 12:00:08 +0900

✍️ 악취 16 : 임시 필드

클래스의 필드가 특정 상황에만 값을 갖고 그 외의 상황에는 null 또는 기본 값 혹은 임의의 값을 가질 때 이를 '임시 필드'라고 한다. 만약 클래스가 일반 필드와 임시 필드를 동시에 갖는다면 해당 클래스와 관련된 코드를 이해하기 어려워진다. 가령 임시 필드가 언제부터 제대로 된 값을 갖는지, 임시 값의 유무에 따른 동작이 어떻게 달라지는지 이해하는 건 결코 쉬운 일이 아니다.

여기 임시 필드를 세 가지 리팩토링 기법이 있다.

1. "클래스 추출하기" 임시 필드를 다루는 전용 클래스를 생성하기

2. "함수 옮기기" 기존에 임시 필드를 사용하는 메서드를 전용 클래스의 메서드로 옮기기

3. "특이 케이스 추출하기" 특정한 경우에 해당하는 클래스 만들기

본 포스팅에서 관심 있게 살펴볼 리팩토링은 "특이 케이스 추출하기"이다.

특이 케이스 추출하기

어떤 필드의 특정 값에 따라 동작이 달라지는 코드가 반복적으로 등장한다면 해당 필드를 감싸는 별도의 클래스를 정의할 수 있다. 예외적인 기능을 한 클래스에서 관리하는 장점이 있고 동시에 코드를 이해하기 한 결 쉬워진다. 여기에 적용하는 디자인 패턴을 "특이 케이스 패턴"이라고 부르며 Null Object 패턴이 그 대표적인 예시이다.

"unknown"이라는 특정 값에 따라서 메서드의 동작이 달라지는 코드가 반복적으로 등장한다.

public class CustomerService {

    public String customerName(Customer customer) {

        String customerName;
        if (customer.getName().equals("unknown")) {
            customerName = "visitor";
        } else {
            customerName = customer.getName();
        }

        return customerName;
    }

    public Benefits getBenefits(Customer customer) {
        return customer.getName().equals("unknown") ? new BasicBenefits() : customer.getBenefits();
    }

    public int getPurchaseCount(Customer customer) {
        return customer.getName().equals("unknown") ? 0 : customer.getPurchaseHistory().getPurchaseCount();
    }

}

특정 값에 따른 행위를 클라이언트 메서드에서 처리하지말고 Customer를 상속받는 별도의 클래스를 정의해서 예외 로직을 작성한다.

public class UnknownCustomer extends Customer {

    public UnknownCustomer() {
        super("unknown", new BasicBenefits(), new NullPurchaseHistory());
    }

    @Override
    public String getName() {
        return "visitor";
    }

    @Override
    public boolean isUnknown() {
        return super.isUnknown();
    }
    
}

public class NullPurchaseHistory extends PurchaseHistory {

    public NullPurchaseHistory() {
        super(0);
    }
    
}

클라이언트는 필드의 값이 무엇인지 관심 없고 그저 추상화된 메서드를 호출할 뿐이다. 다만 CustomerService를 호출하는 쪽에서 필드값을 보고 Customer 그대로 전달할지 UnknownCustomer로 변환해서 전달할지 판별해야 한다.

public class CustomerService {

    public String customerName(Customer customer) {
        return customer.getName();
    }

    public Benefits benefits(Customer customer) {
        return customer.getBenefits();
    }

    public int purchaseCount(Customer customer) {
        return customer.getPurchaseHistory().getPurchaseCount();
    }

}

[리팩토링] 악취 15 : 추측성 일반화

Kangworld — Sat, 4 Feb 2023 12:30:10 +0900

✍️ 악취 15 : 추측성 일반화

지금 당장 불필요함에도 나중에 필요할 것 같다는 추측으로 코드를 일반화 시켜 작성했지만 결국엔 사용되지 않는 상황이 발생한다. 모든 경우가 그렇진 않지만 특정 기능을 구현한 코드보다 일반화시킨 코드가 더 복잡하고 이해하기 어려운 경우가 많다. 그렇기에 일반화된 코드가 범용적으로 사용하지 않는다면, 앞으로도 그럴 계획이 없다면 리팩토링을 적용해볼만 하다.

여기 추측성 일반화를 위한 네 가지 리팩토링 기법이 있다.

1. "계층 합치기", 추상 클래스를 만들었지만 유효하지 않다면

2. "함수 인라인, 클래스 인라인", 불필요한 위임이 있다면

3. "함수 선언 변경하기", 재사용을 고려해 추가했지만 사용하지 않는 매개변수가 존재한다면

4. "죽은 코드 제거하기", 실행되지 않는 코드라면

본 포스팅에서 관심있게 살펴볼 리팩토링은 "죽은 코드 제거하기"이다.

죽은 코드 제거하기

메서드의 도입부에서 customer의 null 여부를 체크했기에, ofNullable로 한 번 더 체크하는 것은 무의미하다.

// before
public class OrderService {

    public List<Order> findCustomerOrders(Customer customer, List<Order> orders) {
        if (customer == null || orders == null)
            return Collections.emptyList();

        int customerId = Optional.ofNullable(customer).map(Customer::getId).orElse(0);

        return orders.stream()
                .filter(Objects::nonNull)
                .filter(o -> o.getCustomerId() == customerId)
                .collect(Collectors.toList());
    }
}


// after
public class OrderService {

    public List<Order> findCustomerOrders(Customer customer, List<Order> orders) {
        if (customer == null || orders == null)
            return Collections.emptyList();

        int customerId = customer.getId();

        return orders.stream()
                .filter(Objects::nonNull)
                .filter(o -> o.getCustomerId() == customerId)
                .collect(Collectors.toList());
    }
}

[MySQL] MySQL JSON 함수 예제

Kangworld — Tue, 24 Jan 2023 23:33:17 +0900

✍️ 서론

MySQL 5.7부터 JSON 타입을 지원하면서 JSON 타입을 다루기 위한 여러 함수들이 추가되었다. 관련 함수의 사용법을 예제와 함께 정리해 보려 한다.

테이블 + 데이터 생성

예제 테이블 생성

CREATE TABLE user (
  id INT(11) NOT NULL,
  info JSON NULL,
  PRIMARY KEY (id))
ENGINE = InnoDB;

예제 데이터 생성

INSERT user
VALUES(1, '{"name": "kangworld", "age": 20 "address": "seoul", "hobby": ["baseball", "bowling"]}');

mysql> SELECT * FROM user;
+----+----------------------------------------------------------------------------------------+
| id | info                                                                                   |
+----+----------------------------------------------------------------------------------------+
|  1 | {"age": 20, "name": "kangworld", "hobby": ["baseball", "bowling"], "address": "seoul"} |
+----+----------------------------------------------------------------------------------------+

JSON 함수 예제

1. JSON_OBJECT ([key, val[, key, val] ...])

JSON_OBJECT는 key-value 입력값을 JSON 객체로 반환한다.

mysql> SELECT JSON_OBJECT("name", "kangworld", "age", 10, "address", "seoul", "hobby", CAST('["baseball", "bowling"]' AS JSON));
+------------------------------------------------------------------------------------------------------------------+
| JSON_OBJECT("name", "kangworld", "age", 10, "address", "seoul", "hobby", CAST('["baseball", "bowling"]' AS JSON)) |
+------------------------------------------------------------------------------------------------------------------+
| {"age": 10, "name": "kangworld", "hobby": ["baseball", "bowling"], "address": "seoul"}                           |
+------------------------------------------------------------------------------------------------------------------+

응용해서 INSERT 쿼리에 활용 가능하다.

mysql> INSERT user 
VALUES(2, JSON_OBJECT("name", "helloworld", "age", 15, "address", "LA", "hobby", CAST('["soccer", "bowling"]' AS JSON)));
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM user;
+----+----------------------------------------------------------------------------------------+
| id | info                                                                                   |
+----+----------------------------------------------------------------------------------------+
|  1 | {"age": 20, "name": "kangworld", "hobby": ["baseball", "bowling"], "address": "seoul"} |
|  2 | {"age": 15, "name": "helloworld", "hobby": ["soccer", "bowling"], "address": "LA"}     |
+----+----------------------------------------------------------------------------------------+

2. JSON_ARRAY([val[, val] ...])

JSON_ARRAY는 입력을 JSON 배열로 반환한다.

mysql> SELECT JSON_ARRAY("baseball", "bowling", 10);
+---------------------------------------+
| JSON_ARRAY("baseball", "bowling", 10) |
+---------------------------------------+
| ["baseball", "bowling", 10]           |
+---------------------------------------+

3. column -> path (= JSON_EXTRACT)

연산자 ->로 JSON value에 접근할 수 있다.

mysql> SELECT id, info->'$.name', info->'$.age' FROM user;
+----+----------------+---------------+
| id | info->'$.name' | info->'$.age' |
+----+----------------+---------------+
|  1 | "kangworld"    | 20            |
+----+----------------+---------------+

연산자 ->는 JSON_EXTRACT와 동일하다.

mysql> SELECT id, JSON_EXTRACT(info, '$.name'), JSON_EXTRACT(info, '$.age') FROM user;
+----+------------------------------+-----------------------------+
| id | JSON_EXTRACT(info, '$.name') | JSON_EXTRACT(info, '$.age') |
+----+------------------------------+-----------------------------+
|  1 | "kangworld"                  | 20                          |
+----+------------------------------+-----------------------------+

value가 JSON 배열이라면 인덱스를 지정해야 한다.

# 두 쿼리 동일
mysql> SELECT info->'$.hobby[0]' FROM user;
mysql> SELECT JSON_EXTRACT(info, '$.hobby[0]') FROM user;
+----------------------------------+
| JSON_EXTRACT(info, '$.hobby[0]') |
+----------------------------------+
| "baseball"                       |
+----------------------------------+

* WHERE 절에 응용

mysql> SELECT * FROM user WHERE JSON_EXTRACT(info, '$.name') LIKE '%kang%';
+----+----------------------------------------------------------------------------------------+
| id | info                                                                                   |
+----+----------------------------------------------------------------------------------------+
|  1 | {"age": 20, "name": "kangworld", "hobby": ["baseball", "bowling"], "address": "seoul"} |
+----+----------------------------------------------------------------------------------------+

4. JSON_INSERT(json_doc, path, val[, path, val] ...)

JSON 데이터에 새로운 key-value를 추가하기 위해 사용된다. key가 없다면 입력되고 key가 있다면 입력은 무시된다.

# "$.gender", "W" 무시됨
mysql> SELECT JSON_INSERT(info, "$.gender", "M", "$.gender", "W") FROM user;
+-------------------------------------------------------------------------------------------------------+
| JSON_INSERT(info, "$.gender", "M", "$.gender", "W")                                                   |
+-------------------------------------------------------------------------------------------------------+
| {"age": 20, "name": "kangworld", "hobby": ["baseball", "bowling"], "gender": "M", "address": "seoul"} |
+-------------------------------------------------------------------------------------------------------+

5. JSON_REPLACE(json_doc, path, val[, path, val] ...)

JSON 데이터의 value를 수정하기 위해 사용된다. key가 있으면 수정되고 key가 없다면 수정은 무시된다.

mysql> SELECT JSON_REPLACE(info, "$.address", "gimhae", "$.abc", "abc") FROM user;
+-----------------------------------------------------------------------------------------+
| JSON_REPLACE(info, "$.address", "gimhae", "$.abc", "abc")                               |
+-----------------------------------------------------------------------------------------+
| {"age": 20, "name": "kangworld", "hobby": ["baseball", "bowling"], "address": "gimhae"} |
+-----------------------------------------------------------------------------------------+

6. JSON_SET(json_doc, path, val[, path, val] ...)

JSON 데이터의 입력 혹은 수정을 위해 사용된다. key가 없다면 key-value가 입력되고 key가 있다면 value가 수정된다.

#age 수정, gender 추가
mysql> SELECT JSON_SET(info, "$.age", 99, "$.gender", "M") FROM user;
+-------------------------------------------------------------------------------------------------------+
| JSON_SET(info, "$.age", 99, "$.gender", "M")                                                          |
+-------------------------------------------------------------------------------------------------------+
| {"age": 99, "name": "kangworld", "hobby": ["baseball", "bowling"], "gender": "M", "address": "seoul"} |
+-------------------------------------------------------------------------------------------------------+

7. JSON_QUOTE(string)

string을 큰따옴표로 감싸서 JSON value 형태로 변환한다. (동시에 내부의 큰따옴표와 특정 문자를 이스케이프 문자로 변환한다.)

mysql> SELECT JSON_QUOTE('hellow world');
+----------------------------+
| JSON_QUOTE('hellow world') |
+----------------------------+
| "hellow world"             |
+----------------------------+

* JSON_CONTAINS는 문자열만 받는 반면 다양한 타입을 변환하고 싶다면 CAST(value AS JSON)을 사용하면 된다.

# integer
mysql> SELECT CAST(10 as JSON);
+------------------+
| CAST(10 as JSON) |
+------------------+
| 10               |
+------------------+

# array
mysql> SELECT CAST('[10,20]' as JSON);
+-------------------------+
| CAST('[10,20]' as JSON) |
+-------------------------+
| [10, 20]                |
+-------------------------+

# string 
mysql> SELECT CAST('"hello world"' as JSON);
+-------------------------------+
| CAST('"hello world"' as JSON) |
+-------------------------------+
| "hello world"                 |
+-------------------------------+

8. JSON_CONTAINS(target, candidate[, path])

JSON 데이터 candidate가 target 혹은 target path에 존재하는지 판단하기 위해 사용된다.

(1) JSON_CONTAINS(target, candidate) case

# path 없는 케이스
mysql> SELECT JSON_CONTAINS(info, JSON_OBJECT("age", 20)) FROM user;
+--------------------------------------------+
| JSON_CONTAINS(info, JSON_OBJECT("age",20)) |
+--------------------------------------------+
|                                          1 |
+--------------------------------------------+

(2) JSON_CONTAINS(target, candidate, [, path]) case

# path가 포함된 케이스
mysql> SELECT JSON_CONTAINS(info, JSON_QUOTE('kangworld'), '$.name') FROM user;
+--------------------------------------------------------+
| JSON_CONTAINS(info, JSON_QUOTE('kangworld'), '$.name') |
+--------------------------------------------------------+
|                                                      1 |
+--------------------------------------------------------+

[리팩토링] 악취 14 : 성의없는 요소

Kangworld — Mon, 16 Jan 2023 23:45:32 +0900

✍️ 악취 14 : 성의없는 요소

개발과정에서 정의된 변수, 메서드, 클래스가 시간이 지남에 따라 필요 없는 경우가 있다. 가령 확장성을 고려해서 미리 추가된 변수와 기능들이 그러한 경우에 속한다. 혹은 리팩토링의 결과로 더 이상 필요 없는 요소들이 나올 수 있다. 리팩토링 책의 저자는 이와 같은 요소를 '성의 없는 요소'라고 정의했다.

재사용을 고려해서 함수 추출하기 리팩토링이 적용된 어느 메서드가 계속해서 재사용이 되지 않고 한 곳에서만 사용한다면 '함수 인라인'을 적용할 수 있다. 이와 유사하게 클래스의 경우라면 '클래스 인라인'을 적용하면 된다.

여기 성의 없는 요소 악취를 해결하기 위한 세 가지 리팩토링 기법이 있다.

1. "함수 인라인"

2. "클래스 인라인"

3. "계층 합치기" 불필요한 상속 구조 제거

본 포스팅에서 관심 있게 살펴볼 리팩토링은 불필요한 상속 구조를 해결하기 위한 '계층 합치기'이다.

계층 합치기

상속 구조를 리팩토링 하는 과정에서 일부 하위 클래스를 삭제하거나, 기능을 올리고 내리다 보면 상위 클래스와 하위 클래스의 차이가 없는 경우가 발생한다. 이러한 경우 계층 합치기 리팩토링을 적용할 수 있다.

여기 등급에 따른 서로 다른 할인율과 혜택을 받는 클래스가 상속의 형태로 정의되어 있다.

@AllArgsConstructor
@Getter
public abstract class Customer {

    protected double baseDiscountRate;

    public double getDiscountRate() {
        return baseDiscountRate;
    }
    
    public abstract int applyDiscount(int price, int deliveryFee);
    
}

public class GoldCustomer extends Customer {

    private int monthlyPoint;

    public GoldCustomer(double baseDiscountRate, int monthlyPoint) {
        super(baseDiscountRate);
        this.monthlyPoint = monthlyPoint;
    }

    @Override
    public int applyDiscount(int price, int deliveryFee) {
        int discountedPrice = price;
        if (monthlyPoint > 0) {
            int pointDiscount = Math.min(discountedPrice, monthlyPoint);

            discountedPrice -= pointDiscount;
            monthlyPoint -= pointDiscount;
        }

        discountedPrice *= (1.0 - getDiscountRate());

        return discountedPrice + deliveryFee;
    }
}

public class VipCustomer extends Customer {

    private int freeDeliveryCnt;

    public VipCustomer(double baseDiscountRate, int freeDeliveryCnt) {
        super(baseDiscountRate);
        this.freeDeliveryCnt = freeDeliveryCnt;
    }

    @Override
    public double getDiscountRate() {
        return baseDiscountRate + 0.2;
    }

    @Override
    public int applyDiscount(int price, int deliveryFee) {
        int discountedPrice = price;
        discountedPrice *= (1.0 - getDiscountRate());

        if (freeDeliveryCnt > 0) {
            freeDeliveryCnt--;

            return discountedPrice;
        }

        return discountedPrice + deliveryFee;
    }
}

만약 VipCustomer 클래스가 사라져서 상속이 무의미해질 때, Customer 클래스와 GoldCustomer를 하나로 묶을 수 있다.

@AllArgsConstructor
@Getter
public class Customer {

    private double baseDiscountRate;
    private int monthlyPoint;

    public double getDiscountRate() {
        return baseDiscountRate;
    }

    public int applyDiscount(int price, int deliveryFee) {
        int discountedPrice = price;
        if (monthlyPoint > 0) {
            int pointDiscount = Math.min(discountedPrice, monthlyPoint);

            discountedPrice -= pointDiscount;
            monthlyPoint -= pointDiscount;
        }

        discountedPrice *= (1.0 - getDiscountRate());

        return discountedPrice + deliveryFee;
    }

}

[리팩토링] 악취 13 : 반복문

Kangworld — Tue, 10 Jan 2023 23:55:07 +0900

✍️ 악취 13 : 반복문

프로그래밍 언어 초기엔 for와 while을 사용해서 반복문을 구현했지만, 비교적 최근 Java와 같은 언어에서 함수형 프로그래밍을 지원하게 되며 반복문의 대안인 파이프라인이 등장했다. Java의 Stream이 대표적인 예시인데, Collection의 Stream을 열고 중개 오퍼레이션을 호출하며 연산을 수행하는 일련의 흐름을 Stream pipeline이라 부른다. 파이프라인을 사용하면 코드가 간결해지고 의도가 명확하게 드러나 가독성이 증가한다는 장점이 있기에 충분히 활용할만하다.

하지만 파이프라인이 고전적인 반복문보다 항상 좋다고 말하긴 어렵다. 반복문이 보다 효율적이고 가독성이 좋은 경우는 무수히 많기에 적절한 판단을 거쳐서 사용해야 한다.

여기 반복문 악취를 해결하기 위한 리팩토링 기법이 있다.

1. "반복문을 파이프라인으로" 파이프라인 오퍼레이션으로 의도를 명확하게

반복문을 파이프라인으로 바꾸기

Java 기준, 고전적인 반복문을 Stream과 중개 오퍼레이션을 사용해서 구현한다면 코드의 가독성이 증가한다.

고전적인 반복문으로 구현된 코드를 Stream pipeline 형태로 변경해 보자.

@AllArgsConstructor
@Getter
public class Employee {

    private int id;

    private String type;
}

public class EmployeeService {

    public List<Integer> findManagerIds(List<Employee> employees){
        List<Integer> managerIds = new ArrayList<>();

        for(Employee employee : employees){
            if(employee.getType().equals("manager")){
                managerIds.add(employee.getId());
            }
        }

        return managerIds;
    }
}

public class EmployeeService {

    public List<Integer> findManagerIds(List<Employee> employees){
       return employees.stream()
               .filter(e->e.getType().equals("manager"))
               .map(Employee::getId)
               .collect(Collectors.toList());
    }
}

[리팩토링] 악취 11 : 기본형 집착 (2)

Kangworld — Mon, 2 Jan 2023 23:27:16 +0900

✍️ 악취 11 : 기본형 집착 (2)

표현하려는 데이터가 심플하다면 언어가 제공하는 기본 타입으로도 충분히 구현할 수 있지만, 표현할 데이터 구조가 복잡해지고 제공할 기능이 복잡해진다면 단순 기본형으로 원활한 기능을 구현하기 어렵다. 가령 단순 화씨온도를 표현하고 싶다면 실수형으로 가능하겠지만 화씨, 섭씨 등 다양한 온도를 표현하고 싶다면 별도의 클래스로 제공하는 것이 더 합리적일 것이다.

여기 기본형 집착 악취를 해결하기 위한 두 가지 리팩토링 기법이 있다.

1. "기본형을 객체로 바꾸기"

2. "조건부 로직을 다형성으로 바꾸기"

조건부 로직을 다형성으로 바꾸기

비슷하지만 서로 다른 것을 표현하는 경우 문자열, 열거형, 숫자 등을 사용하기도 한다. 가령 고객의 등급을 표현할 때 열거형을 사용하는 것이 한 예시이다.

public enum Grade {
    SILVER, GOLD, VIP
}

이렇게 비슷하지만 다른 것을 표현하는 변수들은 종종 if문에 사용되어 서로 다른 로직을 처리하는 분기문의 플래그로 사용되기도 한다. 만약 플래그 변수가 분기문에서 자주 사용되고 동시에 분기마다 서로 다른 로직을 수행하고 경우에 따라 특정 타입에만 유효한 필드가 있다면 본 리팩토링을 고려해 볼 수 있다.

아래 클래스와 같이 type으로 서로 다른 것을 표현하고, type을 보고 서로 다른 로직을 수행하기보단, type에 따른 별도의 서브 클래스 혹은 구현체를 정의해서 코드를 분리하는 것이 더 효율적이다.

@AllArgsConstructor
public class Employee {

    private String type;

    private List<String> availableProjects;

    public int vacationHours() {
        switch (type) {
            case "full-time":
                return 120;
            case "part-time":
                return 80;
            case "temporal":
                return 32;
            default:
                throw new IllegalArgumentException();
        }
    }

    public boolean canAccessTo(String project) {
        switch (type) {
            case "full-time":
                return true;
                
            case "part-time":
            case "temporal":
                return availableProjects.contains(project);
            default:
                throw new IllegalArgumentException();
        }
    }
}

Employee를 추상 클래스로 변경하고 속성에 따라 별도의 서브 클래스를 정의해서 각각의 표현과 로직을 분리하는 것이 좋다.

@AllArgsConstructor
@NoArgsConstructor
public abstract class Employee {

    protected List<String> availableProjects;

    public abstract int vacationHours();

    public boolean canAccessTo(String project){
        return availableProjects.contains(project);
    }
}

public class FullTimeEmployee extends Employee {

    @Override
    public int vacationHours() {
        return 120;
    }

    @Override
    public boolean canAccessTo(String project) {
        return true;
    }
}

public class PartTimeEmployee extends Employee {

    public PartTimeEmployee(List<String> availableProjects) {
        super(availableProjects);
    }

    @Override
    public int vacationHours() {
        return 80;
    }

}

[리팩토링] 악취 11 : 기본형 집착 (1)

Kangworld — Mon, 2 Jan 2023 17:33:20 +0900

✍️ 악취 11 : 기본형 집착

여기 기본형 집착 악취를 해결하기 위한 두 가지 리팩토링 기법이 있다.

1. "기본형을 객체로 바꾸기"

2. "조건부 로직을 다형성으로 바꾸기"

기본형을 객체로 바꾸기

개발 초기엔 기본 타입으로 표현한 데이터를 기능이 추가됨에 따라, 구조가 확장됨에 따라 더 다양한 형태로 표현해야 하는 경우가 발생한다. 앞서 언급했던 예시와 동일하게, 화씨로만 표현하던 데이터를 섭씨로도 제공해야 하는 경우가 그러하다.

STEP 1 : 문제 파악

@AllArgsConstructor
@Getter
public class Order {

    private String priority;
}

public class OrderProcessor {

    public long numberOfHighPriorityOrders(List<Order> orders) {
        return orders.stream()
                .filter(o -> o.getPriority() == "high")
                .count();
    }
}

위 구조는 크게 두 가지 문제점을 가지고 있다.

1. priority는 type safety가 보장되지 않는다. 막말로 어떤 String 값이 와도 우선순위로 간주된다.

2. 우선순위 계산을 위한 별도의 메서드가 없고 외부에서 계산하고 있다.

STEP 2 : Order의 책임으로

priority의 type safety 보장과 우선순위 계산을 Order의 책임으로 구현해 보자.

@Getter
public class Order {

    private static final List<String> LEGAL_PRIORITY = Arrays.asList("low", "normal", "high");

    private String priority;

    public Order(String priority) {
        validate(priority);

        this.priority = priority;
    }

    public boolean higherThan(String priority) {
        validate(priority);

        return index(this.priority) > index(priority);
    }

    private void validate(String priority) {
        if (!LEGAL_PRIORITY.contains(priority))
            throw new IllegalArgumentException(priority);
    }

    private int index(String priority) {
        return LEGAL_PRIORITY.indexOf(priority);
    }

}

public class OrderProcessor {

    public long numberOfHighPriorityOrders(List<Order> orders) {
        return orders.stream()
                .filter(o -> o.higherThan("normal"))
                .count();
    }
}

위 구조는 여전히 문제점이 있다. 가장 큰 문제로, Order가 너무 많은 정보를 알고 있고 동시에 너무 많은 일을 처리한다. 가령 Order는 우선순위 검증을 위해 LEAGAL_PRIORITY도 알아야 하고, 우선순위 계산을 위한 메서드를 가지고 있다. 이는 너무 많은 기능이 Order에게 집중되었다고 볼 수 있다.

STEP 3 : Priority의 책임으로

기본형이었던 Priority를 클래스로 변경하고 Order에게 부여했던 책임을 Priority로 옮겨보자.

@Getter
public class Priority {

    private static final List<String> LEGAL_PRIORITY = Arrays.asList("low", "normal", "high");

    private String value;

    public Priority(String value) {
        if (!LEGAL_PRIORITY.contains(value))
            throw new IllegalArgumentException(value);

        this.value = value;
    }

    public boolean higherThan(Priority priority) {
        return index(this) > index(priority);
    }

    private int index(Priority priority) {
        return LEGAL_PRIORITY.indexOf(priority.value);
    }

}

@Getter
public class Order {

    private Priority priority;

    public Order(Priority priority) {
        this.priority = priority;
    }

}

public class OrderProcessor {

    public long numberOfHighPriorityOrders(List<Order> orders) {
        Priority normal = new Priority("normal");

        return orders.stream()
                .filter(o -> o.getPriority().higherThan(normal))
                .count();
    }
}

[리팩토링] 악취 10 : 데이터 뭉치

Kangworld — Mon, 2 Jan 2023 15:47:55 +0900

✍️ 악취 10 : 데이터 뭉치

여러 클래스에 동일한 혹은 유사한 필드가 반복적으로 등장하거나, 메서드에 전달하는 매개변수 목록이 유사한 경우 이렇게 뭉쳐 다니는 데이터는 한곳으로 모아두는 것이 좋다.

여기 데이터 뭉치를 해결하기 위한 두 가지 리팩토링 기법이 있다.

1. "클래스 추출하기" 동일한, 유사한 필드를 하나의 클래스로

2. "매개변수 객체 만들기" 동일한, 유사한 매개변수를 하나의 클래스로

클래스 추출하기

아래 두 클래스 모두 학년과 반 번호라는 공통된 필드를 사용 중이라면, 두 필드를 하나의 클래스로 추출할 수 있다.

@AllArgsConstructor
@Getter
public class Student {

    private String name;

    private int grade;

    private int classNo;

    public String getGradeClassNo() {
        return grade + "-" + classNo;
    }
}

@AllArgsConstructor
@Getter
public class Teacher {

    private String name;

    /**
     * 담당 학년, 반 번호
     */
    private int grade;
    private int classNo;

    public String getGradeClassInCharge() {
        return grade + "-" + classNo;
    }
}

공통된 필드를 GradeClassNo 클래스로 추출했다.

@AllArgsConstructor
public class GradeClassNo {

    private int grade;

    private int classNo;

    @Override
    public String toString() {
        return grade + "-" + classNo;
    }
}

@AllArgsConstructor
public class Student {

    private String name;

    private GradeClassNo gradeClassNo;

    public String getGradeClassNo() {
        return gradeClassNo.toString();
    }
}

@AllArgsConstructor
public class Teacher {

    private String name;

    private GradeClassNo gradeClassNo;

    public String getGradeClassInCharge() {
        return gradeClassNo.toString();
    }
}

[리팩토링] 악취 9 : 기능 편애

Kangworld — Mon, 2 Jan 2023 15:14:20 +0900

✍️ 악취 9 : 기능 편애

어떤 메서드가 자신이 속한 클래스보다 다른 클래스를 더 많이 참조한다면 이를 '기능 편애'라고 한다. 기능 편애 현상이 나타나는 가장 큰 이유는 올바르지 못한 데이터 구조에서 기인한다. 한 클래스가 너무 많은 기능을 담당하거나, 필드와 메서드가 서로 다른 클래스에 분리된 경우가 그 대표적인 예시이다.

여기 기능 편애를 해결하기 위한 리팩토링 기법이 있다.

1. "함수 옮기기" 올바른 책임을 위해

함수 옮기기

전기 사용량과 가스 사용량을 표현하는 두 클래스가 있고

@AllArgsConstructor
@Getter
public class ElectricityUsage {

    private double amount;

    private double pricePerUnit;
}

@AllArgsConstructor
@Getter
public class GasUsage {

    private double amount;

    private double pricePerUnit;
}

총 사용료를 계산하는 Bill 클래스가 있다. 현재 구조에서 아래 Bill 클래스가 기능 편애 악취를 가지고 있다. 정확히 calculateBill 메서드가 사용료 계산이라는 기능 편애 욕심을 내고 있다. 여기엔 문제가 있는데 가령 가스 사용량에 따른 계산 방법이 변경되었다면 아래와 같은 가스 사용료 계산 코드를 모두 수정해야 하는 불상사가 발생한다.

public class Bill {

    private ElectricityUsage electricityUsage;

    private GasUsage gasUsage;

    public double calculateBill() {
        double electricityBill = electricityUsage.getAmount() * electricityUsage.getPricePerUnit();
        double gasBill = gasUsage.getAmount() * gasUsage.getPricePerUnit();

        return electricityBill + gasBill;
    }

}

따라서 Bill에서 사용량과 가격을 참조해서 공과금을 계산하는 것보단, 각각의 클래스에서 사용료를 계산하는 것이 더 올바른 책임이라고 생각한다. 이러한 구조는 수정에도 유연한데, 만약 가스 사용료 계산 방법이 변경되더라도 getGasBill의 코드만 수정하면 된다.

// after!

@AllArgsConstructor
@Getter
public class ElectricityUsage {

    private double amount;

    private double pricePerUnit;

    public double getElectricityBill() {
        return amount * pricePerUnit;
    }

}


@AllArgsConstructor
@Getter
public class GasUsage {

    private double amount;

    private double pricePerUnit;

    public double getGasBill() {
        return amount * pricePerUnit;
    }
}

public class Bill {

    private ElectricityUsage electricityUsage;

    private GasUsage gasUsage;

    public double calculateBill() {
        return electricityUsage.getElectricityBill() + gasUsage.getGasBill();
    }
}

[리팩토링] 악취 8 : 산탄총 수술

Kangworld — Thu, 22 Dec 2022 00:00:26 +0900

✍️ 악취 8 : 산탄총 수술

코드에 변경이 생겼을 때 관련 있는 여러 모듈 혹은 클래스 혹은 메서드를 수정해야 한다면 코드의 응집도는 낮고 결합도는 높은 상황일 가능성이 높다. 따라서 이런 현상이 발견된다면 관련 있는 데이터를 한 곳으로 옮겨서 응집도를 높이고 책임을 명확히 분리해서 결합도를 낮출 필요가 있다.

여기 낮은 응집도와 높은 결합도의 산탄총 악취를 해결하기 위한 세 가지 리팩토링 기법이 있다.

1. "함수 옮기기, 필드 옮기기" 필요한 변경 내역을 하나의 클래스로 모으기

2. "단계 쪼개기" 공통으로 사용되는 메서드의 결과물을 하나로 묶기

3. "함수 인라인, 클래스 인라인" 흩어진 로직을 한 곳으로

필드 옮기기

좋은 데이터 구조를 가지고 있다면, 해당 데이터를 기반한 행위를 메서드로 작성하는 것이 수월해진다. 이런 의미에서 관련 있는 필드를 한 곳에서 관리하도록 설계하는 것이 중요하다. 설령 현재 구조가 그렇지 않더라도 필드 옮기기를 통해 응집도를 높일 수 있다.

필드를 옮기는 단서

1. "어떤 데이터를 항상 어떤 객체와 함께 전달하는 경우" 데이터를 객체의 필드로 옮기기

2. "어떤 객체를 변경할 때 다른 객체에 있는 필드를 변경하는 경우" 변경의 주체로 필드를 옮기기

3. "여러 객체에 동일한 필드를 수정하는 경우" 필드를 한쪽으로 옮기기

고객의 이름과 할인율, 계약을 담는 클래스가 있다. 아래 구조에선 할인율과 계약이 별개의 필드로 존재하지만, 추후에 계약 클래스에 할인율이 포함돼야 한다고 판단이 되면 할인율 필드를 계약 객체로 옮길 수 있다.

public class Customer {

    private String name;

    private double discountRate;

    private CustomerContract contract;

    public Customer(String name, double discountRate) {
        this.name = name;
        this.discountRate = discountRate;
        this.contract = new CustomerContract(dateToday());
    }

    public double getDiscountRate() {
        return discountRate;
    }

    public void becomePreferred() {
        this.discountRate += 0.03;
    }

    public double applyDiscount(double amount) {
        BigDecimal value = BigDecimal.valueOf(amount);
        return value.subtract(value.multiply(BigDecimal.valueOf(this.discountRate))).doubleValue();
    }

    private LocalDate dateToday() {
        return LocalDate.now();
    }
}

public class CustomerContract {

    private LocalDate startDate;

    public CustomerContract(LocalDate startDate) {
        this.startDate = startDate;
    }
}

단순히 필드를 옮기는 것이 아니라, 필드와 관련된 메서드 가령 becomePreferred의 책임을 누가 지게 될 것인지 고민이 필요한 부분이다. 본인의 경우 CustomerContract가 그 책임을 지게 했고 판단에 따라 Customer의 책임으로 볼 수 도 있다.

public class Customer {

    private String name;

    private CustomerContract contract;

    public Customer(String name, double discountRate) {
        this.name = name;
        this.contract = new CustomerContract(dateToday(), discountRate);
    }

    public double getDiscountRate() {
        return contract.getDiscountRate();
    }

    public void becomePreferred() {
        contract.becomePreferred(0.03);
    }

    public double applyDiscount(double amount) {
        BigDecimal value = BigDecimal.valueOf(amount);
        return value.subtract(value.multiply(BigDecimal.valueOf(getDiscountRate()))).doubleValue();
    }

    private LocalDate dateToday() {
        return LocalDate.now();
    }
}

@Data
public class CustomerContract {

    private LocalDate startDate;

    private double discountRate;

    public CustomerContract(LocalDate startDate, double discountRate) {
        this.startDate = startDate;
        this.discountRate = discountRate;
    }

    public void becomePreferred(double discountRate) {
        this.discountRate += discountRate;
    }
}

함수 인라인

'함수 인라인'이란, 일련의 코드를 메서드로 추출해서 메서드의 이름으로 의도를 표현하는 '함수 추출하기'의 반대되는, 메서드 내부의 코드를 다른 메서드로 옮기는 리팩토링 기법을 말한다.

일반적으로 '함수 추출하기' 기법이 더 유용하게 사용되지만 경우에 따라서 메서드의 이름이 의도를 잘 표현하지 못하거나 메서드의 본문이 그 의도를 충분히 잘 드러낸다면 '함수 인라인' 기법을 사용할 수 있다.

경우에 따라서 단순히 메서드 호출을 감싸는 우회형 메서드도 인라인 기법을 적용할 수 있다.

Student의 지각 횟수를 보고 페널티를 계산하는 StudentService에서 불필요하게 우회하는 메서드를 인라인화 시킬 수 있다.

@AllArgsConstructor
@Getter
public class Student {

    private String name;

    // 지각 횟수
    private int numberOfTardy;
}

public class StudentService {

    public int getTardyPenalty(Student student) {
        return isTardyMoreThanFive(student) ? 20 : 0;
    }

    private boolean isTardyMoreThanFive(Student student) {
        return student.getNumberOfTardy() > 5;
    }
}

// after
public class StudentService {

    public int getTardyPenalty(Student student) {
        return student.getNumberOfTardy() > 5 ? 20 : 0;
    }
}

클래스 인라인

클래스 인라인이란 클래스의 전체 필드와 메서드를 다른 클래스로 옮기는 기법이다. 리팩토링 과정에서 책임을 옮기다 보면 특정 클래스의 데이터 구조가 빈약한, 단순 위임만 된 형태로 변경될 수 있다. 이런 경우 클래스 인라인을 고려해 볼 수 있다.

아래 예제에서 TrackingInformation이 구조가 빈약한 형태의 클래스로, Shipment로 클래스 인라인을 적용해 볼 만하다.

@Data
public class Shipment {

    private TrackingInformation trackingInformation;

    public Shipment(TrackingInformation trackingInformation) {
        this.trackingInformation = trackingInformation;
    }

    public String getTrackingInfo() {
        return this.trackingInformation.display();
    }
}

public class TrackingInformation {

    private String shippingCompany;

    private String trackingNumber;

    public String display() {
        return this.shippingCompany + ": " + this.trackingNumber;
    }
}

Shipment로 TrackingInformation의 모든 필드와 메서드를 옮겼다.

@AllArgsConstructor
public class Shipment {

    private String shippingCompany;

    private String trackingNumber;

    public String getTrackingInfo() {
        return shippingCompany + ": " + trackingNumber;
    }
}

[리팩토링] 악취 7 : 뒤엉킨 변경

Kangworld — Mon, 19 Dec 2022 23:20:46 +0900

✍️ 악취 7 : 뒤엉킨 변경

좋은 코드는 응집도는 높고 결합도는 낮아야 한다.

응집도는 관련 있는 데이터 혹은 기능이 한 곳에 잘 밀집되어 있는가를 말하고,

결합도는 상호간 의존하는 정도를 의미한다.

가령 서로 연관이 없는 A, B 모듈이 수정됐을 때, 양쪽에서 모두 C 모듈의 수정을 요구한다면 응집도가 낮고 결합도는 높다고 할 수 있다. 이처럼 한 모듈이 여러 가지 이유로 수정되어야 한다면 역할이 제대로 나눠지지 않았을 수 있다. 서로 다른 문제는 서로 다른 모듈에서 해결해야 한다.

뒤엉킨 변경을 해결하기 위한 세 가지 리팩토링 기법이 있다.

1. "단계 쪼개기" 서로 다른 문맥의 코드를 분리

2. "함수 옮기기" 적절한 모듈로 함수를 옮기기

3. "클래스 추출하기" 모듈이 클래스 단위라면

단계 쪼개기

서로 다른 일을 하는 코드라면 각기 다른 모듈 혹은 클래스 혹은 메서드로 분리한다. 그래야만 수정사항이 생겼을 때 그것만 신경 쓸 수 있다.

여러 일을 하는 메서드의 경우 처리 과정을 각기 다른 단계로 구분할 수 있다. 가령 1.전처리 작업 2.메인 작업 3.후처리 작업이 그러하다. 만약 메서드내에서 서로 다른 데이터를 다루는 코드가 있다면 단계를 나누는 데 있어서 중요한 단서가 될 수 있다.

여기 상품의 가격을 계산하고 할인가를 계산하고 가격에 따른 운임료를 계산해서 최종 비용을 구하는 메서드가 있다. 아래 메서드를 크게 세 부분으로 나눌 수 있는데, 1. 수량에 따른 가격을 계산하고 수량에 따른 할인을 계산한다. 2. 가격에 따라 운임료를 결정한다. 3. 최종 비용을 계산한다.

public class PriceOrder {

    public double priceOrder(Product product, int quantity, ShippingMethod shippingMethod) {
        // 1. 가격, 할인 계산
        final double basePrice = product.basePrice() * quantity;
        final double discount = Math.max(quantity - product.discountThreshold(), 0)
                * product.basePrice() * product.discountRate();

        // 2. 운임료 계산
        final double shippingPerCase = (basePrice > shippingMethod.discountThreshold()) ?
                shippingMethod.discountedFee() : shippingMethod.feePerCase();
        final double shippingCost = quantity * shippingPerCase;

        // 3. 가격 - 할인 + 운임료 계산
        final double price = basePrice - discount + shippingCost;
        return price;
    }
}

수량에 따른 운임비 계산 코드를 별도의 메서드로 분리하면 메서드 자체의 가독성도 높아지고 기능 수정이 용이해진다.

public class PriceOrder {

    public double priceOrder(Product product, int quantity, ShippingMethod shippingMethod) {
        // 1. 가격과 할인율 계산
        final double basePrice = product.basePrice() * quantity;
        final double discount = Math.max(quantity - product.discountThreshold(), 0)
                * product.basePrice() * product.discountRate();

        // 2. 운임료 계산
        final PriceData priceData = new PriceData(basePrice, quantity);
        final double shippingCost = calcShippingCost(priceData, shippingMethod);

        // 3. 가격 - 할인 + 운임료 계산
        final double price = basePrice - discount + shippingCost;
        return price;
    }

    private double calcShippingCost(PriceData priceData, ShippingMethod shippingMethod) {
        final double shippingPerCase = (priceData.basePrice() > shippingMethod.discountThreshold()) ?
                shippingMethod.discountedFee() : shippingMethod.feePerCase();

        return priceData.quantity() * shippingPerCase;
    }
}

함수 옮기기

모듈화가 잘 된 소프트웨어는 최소한의 정보만으로 프로그램을 변경할 수 있다. 다르게 말하면 모듈화가 잘 된 소프트웨어는 응집도가 높은 소프트웨어일 가능성이 높은데 관련 있는 함수나 필드가 한 곳에 잘 밀집되어 기능을 이해하기 쉽기 때문이다.

다만 관련 있는 메서드나 필드가 항상 고정적인 것은 아니기에, 필요에 따라 옮겨야 할 때가 있다.

한 메서드가 다른 클래스의 필드를 더 많이 참조하거나, 다른 클래스에서도 메서드를 필요로 하는 경우가 그러하다.

Subscriber 클래스는 구독 기간과 등급을 표현하는 필드와 기간과 등급에 따른 월간 구독료를 반환하는 메서드를 갖는다. 여기서 메서드 옮기기의 대상은 getDiscount로 등급에 따라 분기를 처리하고 있기에 그 책임을 Grade 내부로 옮겨볼 수 있다.

public enum Grade {
    VIP, VVIP;
}

@AllArgsConstructor
@Getter
public class Subscriber {

    private int subscriptionPeriod;
    private Grade grade;

    public int getMonthlyFee() {
        int fee = 10000;

        if (subscriptionPeriod >= 6)
            fee -= getDiscount();

        return fee;
    }

    private int getDiscount() {
        if (grade == Grade.VVIP) {
            if (subscriptionPeriod <= 10)
                return 2000;

            return 4000;
        }

        return 1000;
    }
}

할인 금액 계산 코드를 Grade로 옮기긴 했지만 실습의 의미가 크고 Subscriber 클래스에 있어도 문제없다고 생각한다. 다만 getDiscount에서 Subscriber의 필드를 더 많이 참조해야 한다면 원래 위치로 옮기는 것이 좋을듯하다. 무엇보다 getDiscount에 Subscriber를 넘기면 쌍방 참조가 생기므로 그것만은 피하자.

public enum Grade {
    VIP, VVIP;

    public int getDiscount(int subscriptionPeriod) {
        if (this == Grade.VVIP) {
            if (subscriptionPeriod <= 10)
                return 2000;

            return 4000;
        }

        return 1000;
    }
}

@AllArgsConstructor
@Getter
public class Subscriber {

    private int subscriptionPeriod;
    private Grade grade;

    public int getMonthlyFee() {
        int fee = 10000;

        if (subscriptionPeriod >= 6)
            fee -= grade.getDiscount(subscriptionPeriod);

        return fee;
    }
}

클래스 추출하기

클래스가 다루는 책임이 많아질수록 클래스가 점차 커짐에 따라 클래스를 쪼갤 필요가 있다.

데이터나 메서드 중 일부가 매우 밀접하게 관련이 있는 경우, 일부 데이터가 같이 변경되는 경우 클래스를 쪼개는 기준이 될 수 있다. 경우에 따라서 하위 클래스를 만들어 책임을 분산시킬 수 있다.

Person 클래스는 이름과 사무실 지역번호, 사무실 번호를 필드로 갖는다.
여기서 officeAreaCode와 officeNumber가 밀접한 관련이 있는 필드로 간주해서 별도의 클래스로 추출할 수 있다.

@AllArgsConstructor
@Data
public class Person {

    private String name;

    private String officeAreaCode;
    private String officeNumber;

    public String getTelephoneNumber() {
        return this.officeAreaCode + " " + this.officeNumber;
    }
}

전화번호와 관련된 필드와 메서드를 한 곳으로 묶어서 관련된 데이터를 한 클래스에서 관리할 수 있다.

@AllArgsConstructor
@Getter
public class TelephoneNumber {

    private String areaCode;
    private String number;

    @Override
    public String toString() {
        return areaCode + " " + number;
    }
}

@AllArgsConstructor
@Getter
public class Person {

    private String name;
    private TelephoneNumber telephoneNumber;

    public String getTelephoneNumber() {
        return telephoneNumber.toString();
    }
}

[Java] Enum을 활용하는 방법

Kangworld — Tue, 6 Dec 2022 23:56:35 +0900

✍️ 서론

논리적으로 연관된 상수를 정의할 때 사용하는 자료형 enum.

enum은 심볼릭하게 그 자체로도 의미를 가지지만 필요에 따라 필드를 추가하거나 메서드를 추상화해서 enum이 책임질 수 있는 코드를 구현할 수 있다.

simple enum

enum의 가장 단순한 사용법으로 보통 상태 값이나, 분기를 위한 플래그로 사용된다.

public enum Operator {
    PLUS,
    MINUS,
    MULTIPLY,
    DIVIDE;
}

public class Calculator {

    public double calculate(double a, double b, Operator op) {
        if (op == Operator.PLUS) {
            return a + b;

        } else if (op == Operator.MINUS) {
            return a - b;

        } else if (op == Operator.MULTIPLY) {
            return a * b;

        } else if (op == Operator.DIVIDE) {
            return a / b;
        }

        throw new IllegalArgumentException("Illegal Operator : " + op);
    }
}

class CalculatorTest {

    @Test
    public void test_calculate() {
        Calculator calculator = new Calculator();
        double res = calculator.calculate(1.0, 2.0, Operator.PLUS);
        assertEquals(res, 3.0);
    }

}

field

enum은 필드를 가질 수 있다. 필드에 함수형 인터페이스를 선언하고 Java 8에 추가된 람다 표현식을 활용하면 코드가 간결해지고 계산이란 행위를 enum에서 책임질 수 있게 된다.

@AllArgsConstructor
public enum Calculator {
    PLUS((a, b) -> a + b),
    MINUS((a, b) -> a - b),
    MULTIPLY((a, b) -> a * b),
    DIVIDE((a, b) -> a / b);

    private BinaryOperator<Double> binaryOperator;

    public double calculate(double a, double b) {
        return binaryOperator.apply(a, b);
    }
}

class CalculatorTest {

    @Test
    public void test_calculator() {
        Calculator calculator = Calculator.PLUS;
        double res = calculator.calculate(1.0, 2.0);

        assertEquals(res, 3.0);
    }
}

abstract method

enum에 추상 메서드를 추가해서 상수가 가진 의미에 따라 메서드를 구현하도록 유도할 수 있다.

public enum Calculator {

    PLUS {
        @Override
        public double calculate(double a, double b) {
            return a + b;
        }
    },
    MINUS {
        @Override
        public double calculate(double a, double b) {
            return a - b;
        }
    },
    MULTIPLY {
        @Override
        public double calculate(double a, double b) {
            return a * b;
        }
    },
    DIVIDE {
        @Override
        public double calculate(double a, double b) {
            return a / b;
        }
    };

    public abstract double calculate(double a, double b);
}

class CalculatorTest {

    @Test
    public void test_calculator() {
        Calculator calculator = Calculator.PLUS;
        double res = calculator.calculate(1.0, 2.0);

        assertEquals(res, 3.0);
    }
}

혹은 추상 메서드가 아닌 일반 메서드를 정의하고, 특정 상수에서 재정의 할 수 있다.

public enum Grade {

    GOLD,
    VIP,
    VVIP {
        @Override
        public double discountRate() {
            return 0.2;
        }
    };

    public double discountRate() {
        return 0.1;
    }
}

class GradeTest {

    @Test
    public void test_grade() {
        assertEquals(Grade.GOLD.discountRate(), 0.1);
        assertEquals(Grade.VIP.discountRate(), 0.1);
        assertEquals(Grade.VVIP.discountRate(), 0.2);
    }
}

[리팩토링] 악취 6 : 가변 데이터

Kangworld — Sun, 27 Nov 2022 21:32:29 +0900

✍️ 악취 6 : 가변 데이터

자바는 변수의 값을 변경하거나, 레퍼런스 변수로 인스턴스의 값을 변경할 수 있다. 이처럼 데이터의 변경이 자유로운 장점도 있지만, 데이터 변경으로 문제가 생기는 경우가 발생한다. 가령 일부 메서드에선 데이터의 변경이 올바른듯하지만 다른 메서드에선 데이터의 변경이 곧 예상치 못한 에러로 이어지는 경우가 있다.

가변 데이터가 유발하는 잠재적 리스크를 최소화하는 여 섯 가지 리팩토링이 있다.

1. "변수 쪼개기" 여러 데이터를 하나의 변수로 관리하지 않기

2. "질의 메서드와 변경 메서드 분리하기" 사이트 이펙트가 있는 메서드와 없는 메서드를 분리

3. "세터 제거하기" 필요한 경우에만 세터를 만들기

4. "파생 변수를 질의 메서드로" 계산해서 알아낼 수 있는 값이라면 변수가 아닌 질의 메서드 사용

5. " 참조를 값으로 바꾸기" 데이터를 일부만 변경하기보단 새로운 불변 객체 생성

변수 쪼개기

어떤 변수가 여러 번 재할당 되어도 적절한 경우가 있다. 가령 반복문에서 순회에 사용되는 인덱스 변수 혹은 누적값에 사용되는 변수가 그러하다.

// 이런 경우 OK!
public static void main(String[] args) {

    int sum = 0;
    for (int i = 0; i < 10; i++) {
        sum += i;
    }
}

예외 케이스를 제외하고, 변수에 반복적으로 재할당하고 서로 다른 곳에 참조한다면 해당 변수는 여러 용도로 사용되는 변수일 확률이 높다. 변수를 여러 용도로 사용하는 것보단 하나의 변수는 하나의 책임을 지도록 만드는 것이 좋다.

초기 지불 비용인 totalPrice에 계속해서 변화를 주는 것보단

public class Order {

    public double discount(double totalPrice, int quantity) {
        // 만원 이상 구매시 10% 할인
        if (totalPrice >= 10000)
            totalPrice = totalPrice * 0.9;

        // 10개 이상 구매시에도 10% 할인
        if (quantity >= 10)
            totalPrice = totalPrice * 0.9;

        return totalPrice;
    }
}

반환용 변수를 만들고 초기 지불 비용인 totalPrice의 값은 메서드 내에서 유지하는 것이 좋다.

public double discount(double totalPrice, int quantity) {
    double result = totalPrice;

    // 만원 이상 구매시 10% 할인
    if (totalPrice >= 10000)
        result *= 0.9;

    // 10개 이상 구매시에도 10% 할인
    if (quantity >= 10)
        result *= 0.9;

    return result;
}

질의 메서드와 변경 메서드 분리

질의 메서드와 변경 메서드 분리, 쉽게 말하면 getter와 setter를 명백히 분리하는 리팩토링 기법이다.

어떤 값을 반환하는 getter 메서드는 사이트 이펙트가 없어야 한다. 가령 단순 조회를 위해 메서드를 호출했는데 메서드 내부에서 특정 변수의 값이 변경된다면 사용하는 입장에서 메서드 호출로 인한 변수의 변경을 예측하기 어렵다.

여기 예외 목록을 제외한 임의의 정수를 뽑는 nextInt 메서드가 있다. 로직은 단순하다. excludes를 제외한 범위 내의 임의의 난수를 뽑고 excludes에 set하고 값을 반환한다. 한 메서드에 get과 set이 모두 포함된 케이스이다.

public class RandomService {

    public int nextInt(int bound, Set<Integer> excludes) {
        List<Integer> candidates = IntStream.range(0, bound)
                .boxed()
                .filter(i -> !excludes.contains(i))
                .collect(Collectors.toList());

        Random rand = new Random();
        int randIdx = rand.nextInt(candidates.size());
        int randValue = candidates.get(randIdx);

        excludes.add(randValue);

        return randValue;
    }
}

class RandomServiceTest {

    @Test
    public void nextInt() {
        RandomService randomService = new RandomService();
        Set<Integer> excludes = new HashSet<>();

        randomService.nextInt(10, excludes);
        randomService.nextInt(10, excludes);
    }

}

nextInt 메서드는 순수 getter로 만들고 excludes에 add하는 setter 코드는 외부 혹은 별도의 메서드로 정의하는 것이 변수가 변경되는 흐름을 파악하기 쉽다.

public class RandomService {

    public int nextInt(int bound, Set<Integer> excludes) {
        List<Integer> candidates = IntStream.range(0, bound)
                .boxed()
                .filter(i -> !excludes.contains(i))
                .collect(Collectors.toList());

        Random rand = new Random();
        int randIdx = rand.nextInt(candidates.size());

        return candidates.get(randIdx);
    }
}

class RandomServiceTest {

    @Test
    public void nextInt() {
        RandomService randomService = new RandomService();
        Set<Integer> excludes = new HashSet<>();

        int randValue = randomService.nextInt(10, excludes);
        excludes.add(randValue);
    }

}

세터 제거하기

어떤 객체가 생성된 이후 값이 변경되지 않아야 한다면 불필요한 setter를 제거해서 불변 객체(Immutable Object)로 만들 필요가 있다. 객체지향에서 불변 객체라 함은, 초깃값을 설정할 생성자와 이후에 값을 얻어올 getter 메서드만 있을 때 불변 객체라 한다.

@AllArgsConstructor
@Getter
public class Person {

    // 주민 등록 번호
    private int pid;

    // 생년월일
    private DateTime birthDate;
}

public class App {

    public static void main(String[] args) {
        Person person = new Person(1, new DateTime(2022, 1, 1, 0, 0, 0));

        // only get, no set
        person.getPid();
        person.getBirthDate();
    }
}

️ 파생 변수를 질의 메서드로 바꾸기

가령 계산을 통해서 알아낼 수 있는 파생 변수는 메서드로 대체할 수 있다. 메서드도 충분히 그 이름을 통해서 의미를 잘 표현할 수 있고 변수가 아니기에 어디선가 잘못된 값으로 설정될 가능성을 제거할 수 있다.

discountedPrice는 setDiscount 메서드가 호출되기 전까진 계산되지 않는 파생 변수이다.

public class Product {

    private int price;
    private int discount;

    // 파생 변수
    private int discountedPrice;

    public Product(int price) {
        this.price = price;
    }

    public int getDiscountedPrice() {
        return discountedPrice;
    }

    public void setDiscount(int discount) {
        this.discount = discount;
        this.discountedPrice = Math.max(this.price - this.discount, 0);
    }
    
}

파생 변수는 소스가 되는 변수에 종속적인 경향이 있기에 아래 테스트 코드처럼 setDiscount전에 getDiscountedPrice를 호출하면 버그가 발생한다.

class ProductTest {

    @Test
    public void test_O() {
        Product product = new Product(10000);

        product.setDiscount(1000);

        assertEquals(9000, product.getDiscountedPrice());
    }

    @Test
    public void test_X() {
        Product product = new Product(10000);

        // error not equals !!
        assertEquals(10000, product.getDiscountedPrice());
    }

}

이처럼 다른 변수에 종속적인 파생 변수를 질의 메서드로 변경해서 가변 데이터를 제거할 수 있다.

public class Product {

    private int price;
    private int discount;

    public Product(int price) {
        this.price = price;
    }

    public int getDiscountedPrice() {
        return Math.max(this.price - this.discount, 0);
    }

    public void setDiscount(int discount) {
        this.discount = discount;
    }

}

✨ 참조를 값으로 바꾸기

객체의 변경을 다른 곳으로 전파시키고 싶다면 레퍼런스로 정의하고, 반대로 전파하지 않겠다면 값 객체로 사용할 수 있다.

여기 시간에 따른 주식 정보를 담는 클래스가 있고, 주식 구매자가 클래스가 있다.

@AllArgsConstructor
@Data
@ToString
public class Stock {

    private DateTime time;
    private int id;
    private String name;
    private int price;
}

public class Buyer {

    private List<Stock> purchaseList = new ArrayList<>();

    public void buy(Stock stock) {
        purchaseList.add(stock);
    }

    public void print() {
        purchaseList.forEach(System.out::println);
    }
}

주식 가격이 시간에 따라 변화한다고 했을 때, 가변 객체로 정의하면 구매자가 구매한 주식 레퍼런스가 참조하는 값도 함께 변경될 것이다.

public static void main(String[] args) throws InterruptedException {
    DateTime now = new DateTime(2000, 1, 1, 0, 0, 0);
    Stock samsung = new Stock(now, 1, "samsung", 100);

    Buyer buyer = new Buyer();
    buyer.buy(samsung);

    Thread.sleep(1);

    samsung.setTime(now.plusSeconds(1));
    samsung.setPrice(200);

    buyer.buy(samsung);

    buyer.print();
    // Stock(time=2000-01-01T00:00:01.000+09:00, id=1, name=samsung, price=200)
    // Stock(time=2000-01-01T00:00:01.000+09:00, id=1, name=samsung, price=200)

}

반면 구매자가 소유한 주식 객체가 구매한 시점의 값을 유지하길 바란다면 불변 객체로 제공해야 한다.

@EqualsAndHashCode(of = {"id", "time"})
@AllArgsConstructor
@Getter
@ToString
public class Stock {

    private DateTime time;
    private int id;
    private String name;
    private int price;
}

public static void main(String[] args) throws InterruptedException {
    DateTime now = new DateTime(2000, 1, 1, 0, 0, 0);
    Stock samsung = new Stock(now, 1, "samsung", 100);

    Buyer buyer = new Buyer();
    buyer.buy(samsung);

    Thread.sleep(1);

    samsung = new Stock(now.plusSeconds(1), samsung.getId(), samsung.getName(), 200);
    buyer.buy(samsung);

    buyer.print();
    // Stock(time=2000-01-01T00:00:00.000+09:00, id=1, name=samsung, price=100)
    // Stock(time=2000-01-01T00:00:01.000+09:00, id=1, name=samsung, price=200)
}

[리팩토링] 악취 5 : 전역 변수

Kangworld — Sun, 13 Nov 2022 20:28:48 +0900

✍️ 악취 5 : 전역 변수(전역 데이터)

전역 변수, 가령 자바의 public static 변수는 어플리케이션 전반에 걸쳐서 접근하고 수정할 수 있기에 어느 위치에서 값이 참조되고 수정되는지 파악하기 어렵다. 이건 비단 전역 변수만의 문제가 아니라 클래스 필드도 그러하다. 클래스 필드가 외부에 public하게 노출되어 있다면 필드의 상태 변경을 파악하기 어려워진다.

전역 데이터를 위해 리팩토링을 활용할 수 있다.

1. 변수 캡슐화하기

변수 캡슐화하기

전역 변수와 클래스의 필드가 외부에 public하게 노출되어 참조 위치가 많아지면 상태 값을 추적하기 어렵다. 가령 단순 읽기 위해 변수를 참조했는지 값을 변경하기 위해 참조했는지 파악하기 어렵다. 게다가 변수에 값을 직접 할당하면 값에 대한 검증이 불가능하다.

변수의 조회와 변경을 별도의 메서드를 통해서만 가능하게 한다면 의도를 명확하게 분리할 수 있고 앞서 말한 값에 대한 검증 과정도 메서드 내에서 처리할 수 있다.

// before
public class AirConditioning {

    public static int targetTemperature = 25;

    // 제습 모드
    public static boolean dehumidificationMode = true;

    // 화씨로 표기
    public static boolean readInFahrenheit = false;

}


public class App {

    public static void main(String[] args) {
        System.out.println(AirConditioning.targetTemperature);

        AirConditioning.targetTemperature = -10000;
        AirConditioning.dehumidificationMode = true;
        AirConditioning.readInFahrenheit = false;
    }
}

전역 변수를 private으로 변경하고 각각의 getter/setter로만 접근하도록 변경했다. 변수 사용 시 의도를 명확하게 분리할 수 있고 메서드 내부에 로직을 추가해서 코드의 응집력을 높이는 효과도 있다.

// after
public class AirConditioning {

    private static int targetTemperature = 25;

    // 제습 모드
    private static boolean dehumidificationMode = true;

    // 화씨로 표기
    private static boolean readInFahrenheit = false;

    public static Integer getTargetTemperature() {
        if (readInFahrenheit)
            return (int) (targetTemperature * 1.8 + 32);

        return targetTemperature;
    }

    public static void setTargetTemperature(Integer targetTemperature) {
        if (targetTemperature > 40 || targetTemperature < 10)
            throw new IllegalArgumentException();

        AirConditioning.targetTemperature = targetTemperature;
    }

    ```
}

[리팩토링] 악취 4. 긴 매개변수 목록

Kangworld — Sun, 6 Nov 2022 22:55:13 +0900

✍️ 악취 4 : 긴 매개변수 목록

메서드의 매개변수가 많을수록 함수의 역할을 이해하기 어렵다. 고려해 볼 사항으로 과연 그 메서드가 한 가지 일을 하고 있는 게 맞는지, 불필요한 매개변수는 없는지, 논리적으로 그룹핑할 매개변수 목록은 없는지 검토해야 한다.

긴 매개 변수 목록을 위해 네 가지 리팩토링을 활용할 수 있다.

1. "매개 변수를 질의 함수로 바꾸기" 만약 어떤 매개변수를 다른 매개변수를 통해 알아낼 수 있다면

2. "플래그 제거하기" 매개 변수가 플래그로 사용된다면

3. "객체를 통째로 넘기기" 기존 자료구조에서 세부적인 데이터를 가져와서 플랫하게 넘기는 대신

4. "그룹핑해서 매개변수 객체 만들기" 일부 매개변수들이 반복적으로 넘겨진다면

매개 변수를 질의 함수로 바꾸기

메서드의 매개변수는 메서드를 이해하는데 굉장히 중요한 역할을 한다. 그렇기에 메서드의 매개변수가 많으면 많을수록 어떤 일을 하는지 추측하기 어려워진다. 만약 한 매개변수를 통해 다른 매개변수를 알아낼 수 있다면 "중복 매개변수"라고 한다.

메서드를 호출하는 측면에서도 고려해 보면, 결국 인자를 넘겨주는 것은 함수를 호출하는 쪽의 책임이다. 메서드 호출에 있어서 너무 많은 책임을 외부에 넘기는 것보단 정말 필요한 매개 변수만 받아서 메서드 내부에서 책임지도록 설계해야 한다.

// Before
public class Order {

    private int quantity;
    private double itemPrice;

    public Order(int quantity, double itemPrice) {
        this.quantity = quantity;
        this.itemPrice = itemPrice;
    }

    /**
     * 비용 계산 후 수량에 따른 할인 레벨을 결정하고, 할인된 가격 반환 
     * @return
     */
    public double finalPrice() {
        double basePrice = this.quantity * this.itemPrice;
        int discountLevel = this.quantity > 100 ? 2 : 1;

        return discountedPrice(basePrice, discountLevel);
    }

    /**
     * 할인 레벨에 따른 할인가격 계산
     */
    private double discountedPrice(double basePrice, int discountLevel) {
        return discountLevel == 2 ? basePrice * 0.90 : basePrice * 0.95;
    }
}

// After
public class Order {

    private int quantity;
    private double itemPrice;

    public Order(int quantity, double itemPrice) {
        this.quantity = quantity;
        this.itemPrice = itemPrice;
    }

    public double finalPrice() {
        double basePrice = this.quantity * this.itemPrice;
        return discountedPrice(basePrice);
    }

    // discountLevel 계산을 discountedPrice의 책임으로 변경함
    private double discountedPrice(double basePrice) {
        return discountLevel() == 2 ? basePrice * 0.90 : basePrice * 0.95;
    }

    private int discountLevel() {
        return this.quantity > 100 ? 2 : 1;
    }
}

플래그 인수 제거하기

일반적으로 플래그로 넘겨지는 매개변수는 메서드 내부 로직을 분기하기 위해 사용한다. 이처럼 코드에 종종 등장하지만 가장 큰 단점은 메서드의 호출부에서 그 용도를 파악하기 어렵다는 것이다.

가령 아래 메서드는 어떤 일을 하는지 짐작이 가지만

playGame(players);

플래그 인자가 추가된 순간 내부 구현을 찾아보기 전까진 차이점이 무엇인지 알 수 없다.

playGame(players, true);
playGame(players, false);

'조건문 분해하기'를 활용하면 플래그 인수를 제거할 수 있다.

@AllArgsConstructor
@Getter
public class Order {

    private DateTime placedOn;
    private String deliveryAddress;
}

// Before
public class Shipment {

    public DateTime getDeliveryDate(Order order, boolean isRush) {
        if (isRush) {
            int deliveryTime = switch (order.getDeliveryAddress()) {
                case "SEOUL" -> 1;
                case "INCHEON" -> 2;
                default -> 3;
            };

            return order.getPlacedOn().plusDays(deliveryTime);

        } else {
            int deliveryTime = switch (order.getDeliveryAddress()) {
                case "SEOUL" -> 2;
                case "INCHEON" -> 3;
                default -> 3;
            };

            return order.getPlacedOn().plusDays(deliveryTime);
        }
    }
}

@Test
void deliveryDate() {
    DateTime placedOn = new DateTime(2021, 12, 15, 0, 0);
    Order order = new Order(placedOn, "SEOUL");

    Shipment shipment = new Shipment();
    assertEquals(placedOn.plusDays(2), shipment.getDeliveryDate(order, false));
    assertEquals(placedOn.plusDays(1), shipment.getDeliveryDate(order, true));
}

switch문 로직을 메서드로 빼면 다음과 같은 형태가 되고

public class Shipment {

    public DateTime getDeliveryDate(Order order, boolean isRush) {
        if (isRush) {
            return getRushDeliveryDate(order);

        } else {
            return getRegularDeliveryDate(order);
        }
    }

    private DateTime getRushDeliveryDate(Order order) {
        int deliveryTime = switch (order.getDeliveryAddress()) {
            case "SEOUL" -> 1;
            case "INCHEON" -> 2;
            default -> 3;
        };

        return order.getPlacedOn().plusDays(deliveryTime);
    }

    private DateTime getRegularDeliveryDate(Order order) {
        int deliveryTime = switch (order.getDeliveryAddress()) {
            case "SEOUL" -> 2;
            case "INCHEON" -> 3;
            default -> 3;
        };

        return order.getPlacedOn().plusDays(deliveryTime);
    }
}

외부에선 조건에따라 추출한 메서드를 호출하면 더 이상 플래그를 사용하지 않아도 된다.

public class Shipment {

    public DateTime getRushDeliveryDate(Order order) {
        int deliveryTime = switch (order.getDeliveryAddress()) {
            case "SEOUL" -> 1;
            case "INCHEON" -> 2;
            default -> 3;
        };

        return order.getPlacedOn().plusDays(deliveryTime);
    }

    public DateTime getRegularDeliveryDate(Order order) {
        int deliveryTime = switch (order.getDeliveryAddress()) {
            case "SEOUL" -> 2;
            case "INCHEON" -> 3;
            default -> 3;
        };

        return order.getPlacedOn().plusDays(deliveryTime);
    }
}

@Test
void deliveryDate() {
    DateTime placedOn = new DateTime(2021, 12, 15, 0, 0);
    Order order = new Order(placedOn, "SEOUL");

    Shipment shipment = new Shipment();
    assertEquals(placedOn.plusDays(2), shipment.getRegularDeliveryDate(order));
    assertEquals(placedOn.plusDays(1), shipment.getRushDeliveryDate(order));
}

여러 함수를 클래스로 묶기

비슷한 매개변수를 여러 메서드에서 사용 중이고 해당 메서드들을 논리적으로 그룹핑 할 수 있다면 메서드를 모아 하나의 클래스로 만들 수 있다. 하나의 클래스로 만들고 공통 매개변수를 필드로 옮긴다면 매개변수의 수를 줄일 수 있다.

가령 Student 객체를 검증하고 저장하는 로직이 있다고 가정했을 때 validate 메서드들을 하나의 클래스로 빼낼 수 있다.

// Before
public class StudentService {

    private StudentDao studentDao;

    public void saveStudent(Student student) {
        validateName(student.getName(), student.getGender());
        validateScores(student.getKor(), student.getEng(), student.getMath());

        studentDao.insert(student);
    }

    private void validateName(String name, char gender) {
        if (name.isEmpty() || name.length() > 10)
            throw new IllegalArgumentException("Invalid name length : " + name.length());

        String prefix = "STD_" + gender;
        if (!name.startsWith(prefix))
            throw new IllegalArgumentException("Student name must start with " + prefix);
    }

    private void validateScores(int kor, int eng, int math) {
        boolean isValid = Arrays.asList(kor, eng, math).stream().noneMatch(v -> v < 0 || v > 100);
        if (!isValid)
            throw new IllegalArgumentException("Invalid Score");
    }
}

// After
public class StudentService {

    private StudentDao studentDao;

    public void saveStudents(Student student) {
        StudentValidator validator = new StudentValidator(student);
        validator.validateName();
        validator.validateScores();

        studentDao.insert(student);
    }
}

@AllArgsConstructor
public class StudentValidator {

    private Student student;

    public void validateName() {
        String name = student.getName();
        if (name.isEmpty() || name.length() > 10)
            throw new IllegalArgumentException("Invalid name length : " + name.length());

        String prefix = "STD_" + student.getGender();
        if (!name.startsWith(prefix))
            throw new IllegalArgumentException("Student name must start with " + prefix);
    }

    public void validateScores() {
        boolean isValid = Arrays.asList(student.getKor(), student.getEng(), student.getMath()).
                stream().noneMatch(v -> v < 0 || v > 100);
        if (!isValid)
            throw new IllegalArgumentException("Invalid Score");
    }
}

[리팩토링] 악취 3. 긴 함수

Kangworld — Sun, 30 Oct 2022 02:45:33 +0900

✍️ 악취 : 긴 함수

메서드가 너무 길다면 가독성이 떨어지고 짧은 메서드는 읽는 이로 하여금 많은 문맥 전환을 요구한다. 대부분의 상황에서 너무 긴 메서드는 의도를 파악하기 어렵기 때문에 짧은 메서드에 비해 리팩토링 우선순위가 높다.

긴 메서드를 위해 세 가지 리팩토링을 활용할 수 있다.

1. 함수 추출하기 (임시 변수를 질의 함수로, 매개변수 객체 만들기, 객체 통째로 넘기기, 함수를 명령으로 바꾸기)

2. 조건문 분해햐기

3. 반복문 쪼개기

함수 추출하기

1. 임시 변수를 질의 함수로

변수를 활용하면 반복되는 동일한 계산을 피할 수 있고 변수의 이름으로 의미를 표현할 수도 있다. 하지만 메서드를 추출할 때 변수는 걸림돌이 될 수 있다. 이때 변수도 마찬가지로 별도의 메서드로 추출한다면 기존에 추출한 메서드의 매개변수를 줄일 수 있다.

String으로 빌드 하는 코드를 별도의 메서드로 추출하고 싶다면

public class StudentService {

    /**
     * 학생 성적 요약 출력
     */
    public void printSummary(String name, int kor, int eng, int math) {
        int total = (kor + eng + math);
        double avg = total / 3.0;

        String summary = new StringBuilder()
                .append(name).append("_")
                .append(kor).append("_")
                .append(eng).append("_")
                .append(math).append("_")
                .append(avg).toString();
    }
}

아래와 같이 평균 계산도 별도의 메서드로 빼낸다면 추출한 메서드의 매개변수를 줄일 수 있다.

public class StudentService {

    public void printSummary(String name, int kor, int eng, int math) {
        String summary = getSummary(name, kor, eng, math);
        System.out.println(summary);
    }

    private String getSummary(String name, int kor, int eng, int math) {
        return new StringBuilder()
                .append(name).append("_")
                .append(kor).append("_")
                .append(eng).append("_")
                .append(math).append("_")
                .append(calculateAvg(kor, eng, math)).toString();
    }

    private double calculateAvg(int kor, int eng, int math) {
        int total = (kor + eng + math);

        return total / 3.0;
    }
}

2. 매개 변수 객체 만들기

유사한 매개변수들이 여러 메서드에 걸쳐서 나타난다면 매개 변수들을 묶은 자료구조를 만들 수 있다.

그렇게 만든 자료구조는 데이터 간의 관계를 보다 명시적으로 나타낼 수 있고, 함수에 전달할 매개변수를 줄일 수 있고 도메인을 이해하는데 중요한 역할을 하는 클래스로 발전할 수 있다.

플랫한 name, kor, eng, math를 하나의 클래스로 묶어서 관리한다.

public class StudentService {

    public void printSummary(Student student) {
        String summary = getSummary(student);
        System.out.println(summary);
    }

    private String getSummary(Student student) {
        return new StringBuilder()
                .append(student.getName()).append("_")
                .append(student.getKorean()).append("_")
                .append(student.getEnglish()).append("_")
                .append(student.getMath()).append("_")
                .append(calculateAvg(student)).toString();
    }

    private double calculateAvg(Student student) {
        int total = (student.getKorean() + student.getEnglish() + student.getMath());

        return total / 3.0;
    }
}

3. 객체 통째로 넘기기

한 클래스에서 구할 수 있는 여러 값을 매개 변수로 전달하는 경우 해당 매개 변수를 하나의 클래스로 교체할 수 있다. 단 플랫한 매개변수를 클래스로 변경했을 때 발생하는 의존성을 고려해야 한다. 그리고 객체를 통째로 넘겨야 한다는 건 어쩌면 메서드의 위치가 적절하지 않아서 생기는 문제일 수 있다.

사실 학생의 평균 성적을 구하기 클래스 외부 메서드에 학생 객체를 통째로 넘기고, 해당 메서드에서 평균을 계산하는 것은 객체지향스럽지 않다고 생각한다.

@Getter
public class Student {

    private String name;

    private int korean;
    private int english;
    private int math;

    public double getAvg() {
        return (korean + english + math) / 3.0;
    }
}

public class StudentService {

    public void printSummary(Student student) {
        String summary = getSummary(student);
        System.out.println(summary);
    }

    private String getSummary(Student student) {
        return new StringBuilder()
                .append(student.getName()).append("_")
                .append(student.getKorean()).append("_")
                .append(student.getEnglish()).append("_")
                .append(student.getMath()).append("_")
                .append(student.getAvg()).toString();
    }
}

4. 함수를 명령으로 바꾸기

함수를 독립적인 커맨드로 만들어 사용할 수 있다.

커맨드 패턴을 적용하면 다음과 같은 장점을 취할 수 있는데, 커맨드 클래스를 통해 복잡한 기능을 구현하는데 필요한 여러 메서드나 필드를 추가할 수 있고 클래스를 사용하므로 상속을 활용해서 확장을 할 수 있다.

파일 쓰기 코드를 별도의 커맨드로 분리할 수 있다.

public class StudentService {

    public void printAndSaveSummary(List<Student> students) {
        // print
        List<String> summaries = students.stream().map(this::getSummary).collect(Collectors.toList());
        summaries.forEach(System.out::println);

        // save
        String fileName = "/summaries.txt";
        try (FileWriter fileWriter = new FileWriter(fileName)) {
            PrintWriter printWriter = new PrintWriter(fileWriter);
            summaries.forEach(printWriter::print);

        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    private String getSummary(Student student) {
        return new StringBuilder()
                .append(student.getName()).append("_")
                .append(student.getKorean()).append("_")
                .append(student.getEnglish()).append("_")
                .append(student.getMath()).append("_")
                .append(student.getAvg()).toString();
    }
}

파일 쓰기 코드를 별도의 SummaryWriter 클래스로 분리했다.

클래스로 분리해서 얻어 갈 수 있는 이점으로 파일 쓰기 코드를 더 복잡하게 구성할 수 있고 향후에 엑셀 파일에 쓰기, 콘솔에 쓰기 등 여러 쓰기 기능이 추가된다면 인터페이스를 정의해서 각기 다른 구현체를 만들 수도 있다.

public class StudentService {

    public void printAndSaveSummary(List<Student> students) {
        // print
        List<String> summaries = students.stream().map(this::getSummary).collect(Collectors.toList());
        summaries.forEach(System.out::println);

        // write 커맨드로 변경
        new SummaryWriter().write(summaries);
    }
    
    ```
}

public class SummaryWriter {

    public void write(List<String> summaries) {
        String fileName = "/summaries.txt";
        try (FileWriter fileWriter = new FileWriter(fileName)) {
            PrintWriter printWriter = new PrintWriter(fileWriter);
            summaries.forEach(printWriter::print);

        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

조건문 분해하기

여러 조건에 따라 달라지는 코드를 작성하다 보면 종종 긴 메서드가 만들어지는 것을 목격할 수 있다.

가령 if문에 명시될 조건 자체가 길어지거나, if와 else에서 해야 할 코드가 길어지는 경우가 그러하다.

조건문에 명시될 조건 혹은 if-else에 포함될 코드를 메서드로 분해하면 보다 좋은 코드를 작성할 수 있다.

// Before
public Student findStudent(String name, List<Student> students) {
    Student student = null;
    if (students.stream().anyMatch(s -> s.getName().equals(name))) {
        student = students.stream().
                filter(s -> s.getName().equals(name))
                .findFirst().get();
        
    } else {
        student = new Student(name);
    }

    return student;
}

// After
public Student findStudent(String name, List<Student> students) {
    Optional<Student> optionalStudent = findExistingStudent(name, students);
    if (!optionalStudent.isPresent())
        return new Student(name);

    return optionalStudent.get();
}

private Optional<Student> findExistingStudent(String name, List<Student> students) {
    return students.stream()
            .filter(s -> s.getName().equals(name))
            .findFirst();
}

반복문 쪼개기

하나의 반복문에서 여러 다른 작업을 하는 코드를 쉽게 찾아볼 수 있다. 만약 해당 반복문을 수정해야 한다면 여러 작업을 모두 고려해서 수정해야 한다. 반복문을 쪼개면 보다 쉽게 이해할 수 있고 쪼개진 반복문을 메서드로 추출하기도 용이하다.

// Before
public void printMinMaxScores(List<Student> students) {
    for (Student student : students) {
        int max = Stream.of(student.getEnglish(), student.getKorean(), student.getMath()).
                max(Comparator.naturalOrder()).get();
        System.out.println("max :" + max);

        int min = Stream.of(student.getEnglish(), student.getKorean(), student.getMath())
                .min(Comparator.naturalOrder()).get();
        System.out.println("min :" + min);
    }
}

// After
public void printMinMaxScores(List<Student> students) {
    for (Student student : students) {
        int max = Stream.of(student.getEnglish(), student.getKorean(), student.getMath()).
                max(Comparator.naturalOrder()).get();
        System.out.println("max : " + max);
    }

    for (Student student : students) {
        int min = Stream.of(student.getEnglish(), student.getKorean(), student.getMath()).
                min(Comparator.naturalOrder()).get();
        System.out.println("min : " + min);
    }
}

️ 조건문을 다형성으로 바꾸기

여러 타입에 따라 다른 로직을 처리해야 하는 경우 다형성을 적용해서 조건문을 보다 명확하게 분리할 수 있다.

가령 반복되는 switch문을 각기 다른 클래스로 만들어 제거할 수 있다. 공통으로 사용되는 로직은 상위 클래스에 두고 달라지는 하위 클래스에 둠으로써 달라지는 부분만 강조할 수 있다.

옵션을 받아서 평균, 국어, 영어, 수학 순으로 학생을 출력하는 메서드를 다형성을 활용해 리팩토링해보자.

public enum PrintOrder {
    AVG, KOR, ENG, MATH;
}

public class PrintService {

    public void printStudents(List<Student> students, PrintOrder order) {
        switch (order) {
            case AVG:
                students.stream().
                        sorted(Comparator.comparing(Student::getAvg).reversed())
                        .collect(Collectors.toList()).forEach(System.out::println);
                break;

            case KOR:
                students.stream()
                        .sorted(Comparator.comparing(Student::getKorean).reversed())
                        .collect(Collectors.toList()).forEach(System.out::println);
                break;

            case ENG:
                students.stream()
                        .sorted(Comparator.comparing(Student::getEnglish).reversed())
                        .collect(Collectors.toList()).forEach(System.out::println);
                break;

            case MATH:
                students.stream()
                        .sorted(Comparator.comparing(Student::getMath).reversed())
                        .collect(Collectors.toList()).forEach(System.out::println);
                break;
        }
    }
}

기존의 PrintService를 인터페이스로 변경하고 각 case문에 포함된 로직을 별도의 구현체로 정의한다.

public interface PrintService {

    void printStudents(List<Student> students);
}

public class AvgOrderPrintService implements PrintService {

    @Override
    public void printStudents(List<Student> students) {
        students.stream().
                sorted(Comparator.comparing(Student::getAvg).reversed())
                .collect(Collectors.toList()).forEach(System.out::println);
    }
}

public class KorOrderPrintService implements PrintService {

    @Override
    public void printStudents(List<Student> students) {
        students.stream()
                .sorted(Comparator.comparing(Student::getKorean).reversed())
                .collect(Collectors.toList()).forEach(System.out::println);
    }
}

```

외부에선 별도의 옵션을 넘길 필요 없이 구현체만 변경해서 원하는 형태로 출력할 수 있다.

public static void main(String[] args) {
    PrintService printService = new AvgOrderPrintService();
    printService.printStudents(Collections.emptyList());

    printService = new KorOrderPrintService();
    printService.printStudents(Collections.emptyList());
}

[리팩토링] 악취 2. 중복 코드

Kangworld — Sat, 29 Oct 2022 16:53:11 +0900

✍️ 악취 : 중복 코드

일반적으로 완전히 동일하거나 비슷한 코드를 중복 코드라고 한다. 중복 코드는 몇 가지 치명적인 문제를 가지고 있는데 코드를 읽는 사람 입장에서 비슷한 코드인지 유사한 코드인지 주의 깊게 읽어야 하며, 코드가 변경되면 동일한 모든 코드가 변경되어야 한다.

중복 코드를 위해 세 가지 리팩토링을 활용할 수 있다.

1. 함수 추출하기

2. 코드 정리하기

3. 메서드 올리기

악취 가득한 코드

@AllArgsConstructor
@Getter
public class Customer {

    private int id;

    @Setter
    private String name;
    @Setter
    private String address;

}

@Getter
public class CustomerRepository {

    private List<Customer> customers = new ArrayList<>();

    private void insert(Customer insertObj) {
        Customer exist = customers.stream()
                .filter(c -> c.getId() == insertObj.getId())
                .findAny()
                .orElse(null);

        if (exist != null)
            return;

        customers.add(insertObj);
    }

    private void update(Customer updateObj) {
        Customer exist = customers.stream()
                .filter(c -> c.getId() == updateObj.getId())
                .findAny()
                .orElse(null);

        if (exist == null)
            return;

        exist.setName(updateObj.getName());
        exist.setAddress(updateObj.getAddress());
    }


    public static void main(String[] args) {
        Customer customer = new Customer(1, "Kang", "seoul");
        CustomerRepository repository = new CustomerRepository();

        repository.insert(customer);
    }
}

함수 추출하기

메서드의 이름은 "의도"를 표현한 것이고 메서드의 구현부는 말 그대로 "구현"을 표현한 것이다.

무슨 일을 하는 코드인지 알아내려고 노력해야 한다면 해당 코드를 메서드로 분리해서 이름으로 의도를 표현하면 구현부를 보다 쉽게 파악할 수 있다. 한 줄짜리 메서드도 의도를 잘 표현할 수 있다면 충분히 좋은 메서드라고 생각한다.

insert, update 메서드는 파라미터로 들어온 Customer의 존재 여부를 체크하는 공통된 코드를 가지고 있기에 함수로 추출이 가능해 보인다.

@Getter
public class CustomerRepository {

    private List<Customer> customers = new ArrayList<>();

    private void insert(Customer insertObj) {
        Optional<Customer> optionalCustomer = findCustomer(insertObj.getId());
        if (optionalCustomer.isPresent())
            return;

        customers.add(insertObj);
    }

    private void update(Customer updateObj) {
        Optional<Customer> optionalCustomer = findCustomer(updateObj.getId());
        if (!optionalCustomer.isPresent())
            return;

        Customer customer = optionalCustomer.get();
        customer.setName(updateObj.getName());
        customer.setAddress(updateObj.getAddress());
    }

    private Optional<Customer> findCustomer(int customerId){
        return customers.stream().filter(c -> c.getId() == customerId).findAny();
    }

    public static void main(String[] args) {
        Customer customer = new Customer(1, "Kang", "seoul");
        CustomerRepository repository = new CustomerRepository();

        repository.insert(customer);
    }
}

코드 정리하기

관련 있는 코드는 묶어서 작성해야 더 쉽게 이해할 수 있다. 가령 메서드에서 사용할 변수를 상단에 미리 정의하기보단 해당 변수를 사용할 코드 바로 위에 선언하자.

public static void main(String[] args) {
    CustomerRepository repository = new CustomerRepository();

    // 선언과 사용을 함께
    Customer customer = new Customer(1, "Kang", "seoul");
    repository.insert(customer);
}

메서드 올리기

중복 코드는 당장은 잘 동작하더라도 미래에 버그를 만들 가능성이 높다. 예를 들어 한 쪽에선 코드를 고치고 다른 한쪽에선 반영하지 않은 경우가 그러하다.

만약 여러 하위 클래스에 동일한 코드가 있다면 메서드 올리기를, 비슷하지만 일부 값만 다르다면 함수 매개변수화를, 하위 클래스에 있는 코드가 상위 클래스가 아닌 하위 클래스에 의존한다면 필드 올리기를, 여러 메서드가 비슷한 절차를 밟고 있다면 템플릿 메서드 패턴을 적용할 수 있다.

다음은 매우 심플한 메서드 올리기와 필드 올리기 예제이다.

VipCustomer, VVipCustomer 모두 discounRate를 별도의 멤버로 갖고 있으며 get 메서드도 동일하다.

@AllArgsConstructor
public class Customer {

    private int id;
    private String name;
}

public class VipCustomer extends Customer {

    private double discountRate;

    public VipCustomer(int id, String name) {
        super(id, name);
        this.discountRate = discountRate;
    }

    public double getDiscountRate() {
        return discountRate;
    }
}

public class VVipCustomer extends Customer {

    private double discountRate;

    public VVipCustomer(int id, String name, double discountRate) {
        super(id, name);
        this.discountRate = discountRate;
    }

    public double getDiscountRate() {
        return discountRate;
    }
}

모두 상위 클래스로 옮겨갈 수 있다.

@AllArgsConstructor
public class Customer {

    private int id;
    private String name;
    private double discountRate;

    public double getDiscountRate() {
        return discountRate;
    }
}

public class VipCustomer extends Customer {

    public VipCustomer(int id, String name, double discountRate) {
        super(id, name, discountRate);
    }
}

public class VVipCustomer extends Customer {

    public VVipCustomer(int id, String name, double discountRate) {
        super(id, name, discountRate);
    }
}

[리팩토링] 악취 1. 이해하기 힘든 이름

Kangworld — Wed, 26 Oct 2022 22:01:46 +0900

✍️ 악취 : 이해하기 힘든 이름

깔끔한 코드에서 가장 중요한 것은 좋은 이름이다.
좋은 이름을 위해 크게 세 가지 리팩토링을 활용할 수 있다.

1. 함수 선언 변경

2. 변수 이름 변경

3. 필드 이름 변경

악취 가득한 코드

@AllArgsConstructor
@Getter
public class Person {

    private String name;
    private int age;
}

@Getter
public class CustomerRepository {

    private static int sequenceId = 1;

    private List<String> names = new ArrayList<>();
    private List<Integer> ages = new ArrayList<>();
    private List<Integer> ids = new ArrayList<>();

    private void customer(Person person) {
        names.add(person.getName());
        ages.add(person.getAge());
        ids.add(sequenceId++);
    }

    public static void main(String[] args) {
        CustomerRepository repository = new CustomerRepository();

        Person person = new Person("Kang", 20);
        repository.customer(person);

        repository.getNames().forEach(System.out::println);
        repository.getAges().forEach(System.out::println);
        repository.getIds().forEach(System.out::println);
    }
}

함수 선언 변경

좋은 이름을 가진 함수는 이름만 보고도 구현을 예상할 수 있다.

좋은 이름을 찾는 방법은 함수에 주석을 달고 주석을 함수 이름으로 만들어본다.

함수의 매개 변수는 함수의 문맥을 결정한다. 때로는 정말 필요한 매개변수를 플랫하게 넘겨줄 수 있고, 매개 변수를 포함하는 오브젝트를 넘길 수 있다. 상황에 따라 결정해야 하며 정해진 답은 없다.

public class CustomerRepository {

    private static int sequenceId = 1;

    private List<String> names = new ArrayList<>();
    private List<Integer> ages = new ArrayList<>();
    private List<Integer> ids = new ArrayList<>();

    // customer -> saveCustomer
    private void saveCustomer(Person person) {
        names.add(person.getName());
        ages.add(person.getAge());
        ids.add(sequenceId++);
    }
    
    ```

변수 이름 변경

변수의 스코프가 넓을수록 이름이 중요하다. 가령 람다식 혹은 루프에서 사용하는 변수는 심플하게 짓는 반면 전역변수는 명확한 의미를 갖도록 작성한다.

// name -> customerName
private void saveCustomer(Person customer) {
    names.add(customer.getName());
    ages.add(customer.getAge());
    ids.add(sequenceId++);
}

필드 이름 바꾸기

클래스의 필드는 어플리케이션 전반에 걸쳐 참조될 수 있으므로 명확한 의미를 갖도록 작성해야 한다. 경우에 따라 관련 있는 필드들은 클래스로 묶어서 관리할 수 있다.

@Getter
public class CustomerRepository {

    private static int sequenceId = 1;

    // names, ages, ids -> customers
    private List<Customer> customers = new ArrayList<>();

    private void saveCustomer(Person customer) {
        customers.add(new Customer(sequenceId++, customer.getName(), customer.getAge()));
    }


    public static void main(String[] args) {
        CustomerRepository repository = new CustomerRepository();

        Person person = new Person("Kang", 20);
        repository.saveCustomer(person);

        repository.getCustomers().forEach(System.out::println);
    }

    @AllArgsConstructor
    @Getter
    @ToString
    private static class Customer {
        private int id;
        private String name;
        private int age;
    }
}

[Java] JWT (JSON Web Token) 개념 및 예제 코드

Kangworld — Tue, 4 Oct 2022 01:58:54 +0900

✍️ JWT (JSON Web Token) 개념

JWT(JSON Web Token)란 선택적 서명 혹은 선택적 암호화를 사용해 데이터를 만드는 인터넷 표준으로, 헤더, 페이로드, 서명으로 구성된다. 페이로드는 클레임(claim)을 담은 JSON 형태이며 서명은 무결성과 인증을 위해 사용된다.

쉽게 말하면 JSON 포맷을 이용해서 사용자 정보를 저장하는 Web Token으로, 클라이언트 서버 구조에서 주로 인증과 데이터 전달에 사용된다.

여기서 선택적 서명과 선택적 암호화라는 말이 나오는데 JWT에 서명을 추가하면 무결성이 보장되는 JWS가 되고, 암호화를 추가하면 무결성과 기밀성이 보장되는 JWE가 된다. 비유하자면 JWT를 확장한 클래스가 JWS 혹은 JWE라고 할 수 있다. 하지만 JWT를 이야기할 때 별다른 조건과 설명이 없다면 JWT는 JWS를 의미한다.

JWT 구조

JWT는 헤더(Header), 페이로드(Payload), 서명(Signature) 세 파트로 구성되며 각 부분이 Base64로 인코딩되어 표현된다. 각각의 파트는 . 구분자를 통해 식별된다.

1. 헤더(Header)

헤더는 typ과 alg 두 가지 정보를 담고 있다.

typ은 토큰의 타입으로 JWT에 해당한다.
alg은 해싱 알고리즘을 나타낸다. 해싱 알고리즘으로 보통 SHA, RSA 알고리즘을 사용하며 송신자는 서명을 만들 때, 수신자는 토큰을 검증할 때 헤더에 표기한 해싱 알고리즘을 사용한다.

{ 
   "alg": "HS512",
   "typ": JWT
 }

2. 페이로드(Payload)

JWT 토큰에서 사용될 정보가 포함된다. 즉, 서버와 클라이언트가 토큰을 주고받을 때 시스템에서 실제로 사용될 정보를 담고 있다. 여기에 포함되는 정보의 단위를 Claim이라고 부르며 Key-Value 타입으로 표현된다. 토큰에 여러 개의 Claim이 포함될 수 있으며 Claim은 크게 세 분류로 나누어져 있다.

1. Registered Claim, 등록된 클레임

2. Public Claim, 공개 클레임

3. Private Claim, 비공개 클레임

Registered Claim, 등록된 클레임

등록된 클레임은 토큰 자체를 표현하기 위해 미리 정의된 클레임으로 모두 선택적으로 작성이 가능하며 사용할 것을 권장한다.

iss: 토큰 발급자(issuer)
sub: 토큰 제목(subject)
aud: 토큰 대상자(audience)
exp: 토큰 만료 시간(expiration)
nbf: 토큰 활성 날짜(not before) 
iat: 토큰 발급 시간(issued at)
jti: JWT 토큰 식별자(JWT ID) 중복 방지를 위해 사용하며 일회용 토큰(Access Token) 등에 사용

Public Claim, 공개 클레임

공개 클레임은 사용자 정의 클레임으로, 공개용 정보 전달을 위해 사용된다. 충돌 방지를 위해 URI 포맷을 사용한다.

{ 
    "https://kangworld.tistory.com/": true
}

Private Claim, 비공개 클레임

비공개 클레임은 사용자 정의 클레임으로, 서버와 클라이언트 간 정보 전달에 사용되는 클레임이다.

{ 
    "userTeamId" : 1,
    "userName" : "kang"
}

3. 서명(Signature)

서명(Signature)은 토큰의 무결성을 검증할 때 사용된다. 서명 값을 계산하는 방법으로 1. 헤더(Header)와 페이로드(Playload)를 각각 Base64로 인코딩하고, 2. 인코딩 결과들과 비밀키를 헤더에 명시한 해시 알고리즘으로 해싱 한다. 3. 마지막으로 이 값을 다시 Base64로 인코딩한다. 과정은 아래 그림을 참고.

서명이 무결성 검증에 사용되는 시나리오는 간단하다. 엘리스가 밥에게 토큰을 보낸다고 가정해 보자.
엘리스가 보낸 토큰의 헤더가 A, 페이로드는 B 일 때 서명 값은 Hash(A + B + 비밀키)가 된다.
밥은 엘리스로부터 받은 토큰이 변조되었는지 판별하기 위해 엘리스가 서명을 만든 과정을 동일하게 진행한다. 엘리스로부터 받은 헤더 값 A, 페이로드 값 B 그리고 비밀키를 이용해서 Hash(A + B + 비밀키) 값을 계산한다. 토큰이 변조되지 않았다면 밥이 계산한 해시값은 엘리스가 보낸 것과 동일할 것이고, 변조되었다면 전혀 다른 해시 값을 가진다.

여기서 자연스럽게 한 가지 사실을 알 수 있는데 JWT는 무결성과 인증을 보장할 뿐, 기밀성은 보장하지 않는다. 세부적인 내용은 HMAC을 찾아보면 이해가 쉬울 것이다.

JWT 예제 코드

JWT 코드 Git 저장소

MVC 패턴에서 JWT 토큰을 발급하는 간단한 시나리오를 코드로 재현했다.

토큰 인증에 관한 코드는 인터셉터와 엮어 별도의 포스팅을 작성할 예정이다.

JWT dependency

Gradle
implementation group: 'io.jsonwebtoken', name: 'jjwt-api', version: '0.11.2'
runtimeOnly group: 'io.jsonwebtoken', name: 'jjwt-impl', version: '0.11.2'
runtimeOnly group: 'io.jsonwebtoken', name: 'jjwt-jackson', version: '0.11.2'

Auth 인증 요청과 응답에 사용할 Model 클래스

/**
 * 인증 요청에 사용할 클래스
 */
@Getter
@AllArgsConstructor
public class AuthRequest {

    private String id;
    private String password;
}

/**
 * 토큰을 감싸는 클래스
 */
@Getter
@AllArgsConstructor
public class AuthResponse {

    private String token;
}

AuthTokenService.class

public interface AuthTokenService {

    /**
     * Token 생성
     */
    String generateToken(AuthRequest authRequest);

    /**
     * HttpServletRequest 헤더에서 Token 추출
     */
    String extractToken(HttpServletRequest httpServletRequest);

    /**
     * Token 유효성 확인
     */
    void validateToken(String token);

    /**
     * Token에서 만료일 추출
     */
    public DateTime getExpireDate(String token);
}

토큰의 헤더를 설정하고, Claim으로 Issuer(토큰 발급자)와 Expiration(만기일)을 지정한다.

마지막으로 비밀키를 포함해서 서명을 만들고 토큰을 발급한다.

AuthTokenServiceImpl.class

@Service
public class AuthTokenServiceImpl implements AuthTokenService {

    private static final String HEADER_TOKEN_KEY = "TOKEN";

    private Key key;

    public AuthTokenServiceImpl() {
        String keySource = "jwtKeyString";
        byte[] keyBytes = Decoders.BASE64.decode(keySource);

        key = Keys.hmacShaKeyFor(keyBytes);
    }

    /**
     * 토큰 발급
     */
    @Override
    public String generateToken(AuthRequest authRequest) {
        Date expireDate = DateTime.now().plusMinutes(30).toDate();

        return Jwts.builder()
                .setHeaderParam("typ", "JWT")
                .setIssuer("admin")
                .setExpiration(expireDate)
                .signWith(key, SignatureAlgorithm.HS512).compact();
    }

    ```
}

[Java] 쓰레드 로컬 (ThreadLocal)

Kangworld — Fri, 26 Aug 2022 00:32:06 +0900

✍️ Stack, Heap, Thread

결론부터 말하면 ThreadLocal이란 Thread마다 독립적인 변수를 갖도록 지원하는 클래스이다. 쉽게 말하면 Thread마다 독립적으로 읽고 쓰는 변수를 제공하는 클래스이다.

ThreadLocal을 이해하기 전에 JVM 메모리 정책을 가볍게 짚고 넘어갈 필요가 있다.

Java 8 이후 기준, 메서드 파라미터와 지역 변수는 Stack에 할당되고 그 외의 것들은 Heap에 할당된다. 엄밀히 말하면 틀린 설명이지만 메서드에 정의된 것들은 Stack, 그 외의 것들은 Heap 영역이라고 생각하자.

Thread(이하 쓰레드)란 한 프로세스 내에서 실행되는 흐름의 단위이다. 한 프로세스당 기본적으로 하나의 쓰레드를 갖는데 이를 메인 쓰레드라고 부른다. 만약 별도의 쓰레드를 생성한 적이 없다면 당신이 작성한 코드는 메인 쓰레드가 처리한다.

Stack과 Heap을 이야기하다가 웬 쓰레드를 말하나 싶겠지만, 이 셋은 깊은 연관이 있다.

메인 쓰레드가 있다는 것은 메인 쓰레드가 아닌 쓰레드가 있을 수 있다는 뜻이고, 다른 말로 한 프로세스 내에 여러 쓰레드가 존재할 수 있다는 뜻으로 해석된다. 그리고 여기서 한 가지 중요한 사실은 쓰레드는 서로 Heap 영역은 공유하지만 Stack 영역은 공유하지 않는 것이다.

여담으로, 쓰레드가 공유하는 Heap 영역에 할당된 자원을 공유 자원 그리고 오직 한 쓰레드만 공유자원에 접근하도록 설계해야 하는 코드 영역을 임계 영역이라고 한다. 둘 이상의 프로세스가 동시에 임계 영역에 진입하는 것을 방지하기 위해 사용되는 기술이 바로 상호 배제 기술이다.

ThreadLocal

본론으로 돌아와서 ThreadLocal이 왜 필요할까.

Stack에 할당된 변수들은 휘발성이 강하다. 메서드가 종료되면 Stack에 저장된 변수들은 사라진다. 반면, 쓰레드 입장에선 메서드에서 계산한 데이터를 잘 보관했다가 재사용하고 싶을 때가 있다. 가령 다른 메서드에서 데이터를 참조해서 사용하거나, 데이터가 Context의 역할을 할 때 그러하다. 그렇다고 해서 메서드가 종료된 이후에도 그 값을 유지하려고 Heap 영역에 저장했다간 다른 쓰레드에서도 해당 값을 세팅하고 참조하는 문제가 발생한다.

가령 메서드에서 계산한 값을 계속 유지하기 위해 반환값으로 넘기고 다시 파라미터로 받는 아래의 코드는 한계점이 있다.

@Data
public class MyRunnable implements Runnable {

    @Override
    public void run() {
        int value = 1;
        value = addOne(value);
        value = multiply(value);

        System.out.println("Result = " + value);
    }

    private int addOne(int value) {
        return value + 1;
    }

    private int multiply(int value) {
        return value * value;
    }
}

public class App {
    public static void main(String[] args) throws InterruptedException {
        MyRunnable myRunnable = new MyRunnable();
        Thread thread = new Thread(myRunnable);

        thread.start();
    }
}

Result = 4

그렇다고 해서 MyRunnable에 멤버 변수를 선언하고 여기에 값을 담는 순간 여러 쓰레드에서 변수 접근이 가능하다.

@Data
public class MyRunnable implements Runnable {

    private int value;

    public MyRunnable() {
        value = 1; // default
    }

    @Override
    public void run() {
        System.out.println(Thread.currentThread().getName()
                + " Start value : "
                + threadLocal.get());

        addOne();
        multiply();

        System.out.println(Thread.currentThread().getName()
                + " Start value : "
                + threadLocal.get());
    }

    private void addOne() {
        value += 1;
    }

    private void multiply() {
        value *= value;
    }
}

public class App {
    public static void main(String[] args) throws InterruptedException {
        MyRunnable myRunnable = new MyRunnable();
        Thread threadA = new Thread(myRunnable, "Thread A");
        threadA.start();
        threadA.join();

        Thread threadB = new Thread(myRunnable, "Thread B");
        threadB.start();
        threadB.join();
    }
}

Thread B가 myRunnble 코드를 실행할 땐 Thread A가 저장했던 4로 시작한다.

Thread A Start value : 1
Thread A End value : 4
Thread B Start value : 4
Thread B End value : 25

지금 예시로 들었던 두 코드의 문제점을 모두 해결한 것이 ThreadLocal이다. 쉽게 요약하면 ThreadLocal은 쓰레드마다 독립적인 변수를 갖도록 지원한다.

public class MyThreadLocalRunnable implements Runnable {

    private static ThreadLocal<Integer> threadLocal = ThreadLocal.withInitial(() -> 1);

    @Override
    public void run() {
        System.out.println(Thread.currentThread().getName()
                + " Start value : " 
                + threadLocal.get());

        addOne();
        multiply();

        System.out.println(Thread.currentThread().getName() 
                + " End value : " 
                + threadLocal.get());
    }

    private void addOne() {
        int value = threadLocal.get();
        threadLocal.set(value + 1);
    }

    private void multiply() {
        int value = threadLocal.get();
        threadLocal.set(value * value);
    }
}

public class App {
    
    public static void main(String[] args) throws InterruptedException {
        MyThreadLocalRunnable myThreadLocalRunnable = new MyThreadLocalRunnable();
        Thread threadA = new Thread(myThreadLocalRunnable, "Thread A");
        threadA.start();
        threadA.join();

        Thread threadB = new Thread(myThreadLocalRunnable, "Thread B");
        threadB.start();
        threadB.join();
    }
}

이제는 쓰레드마다 독립된 계산 결과가 나온다.

Thread A Start value : 1
Thread A End value : 4
Thread B Start value : 1
Thread B End value : 4

보통 Spring 서버 구현에서 쓰레드마다 User 정보를 Context로 저장할 때 ThreadLocal을 사용한다.

❓ ThreadLocal은 항상 좋을까

그렇다면 ThreadLocal의 단점 내지는 주의할 점은 무엇일까

가령 예제 코드에서 Thread A가 작업을 마무리해서 ThreadLocal에 4를 저장했고, 다시 Thread A로 같은 작업을 시작한다면 이전에 저장했던 4를 시작으로 계산을 진행할 것이다. 이처럼 쓰레드가 한 단위의 작업을 마무리했다면 반드시 ThreadLocal.remove 메서드를 호출해야 한다.

public class MyThreadLocalRunnable implements Runnable {

    private static ThreadLocal<Integer> threadLocal = ThreadLocal.withInitial(() -> 1);

    @Override
    public void run() {
        System.out.println(Thread.currentThread().getName()
                + " Start value : "
                + threadLocal.get());

        addOne();
        multiply();

        System.out.println(Thread.currentThread().getName()
                + " End value : "
                + threadLocal.get());
        
        threadLocal.remove();
    }

[Java] 어노테이션(Annotation), @

Kangworld — Tue, 23 Aug 2022 23:42:09 +0900

어노테이션 개념과 샘플 코드

✍️ Annotation

자바 어노테이션은 잘만 사용하면 매우 유용한 자바의 문법이다. 기본적인 종류는 한정되지만 원하는 대로 커스텀 어노테이션을 만들 수 있어서 적재적소에 활용 가능하다.

먼저 어노테이션은 1. 문서화 2. 컴파일러 체크 3. 메타데이터 용도로 사용된다. 문법적으로 @기호가 붙은 심볼을 사용하며 패키지, 클래스, 메서드, 프로퍼티, 변수에 명시할 수 있다. 어노테이션이 붙은 코드를 컴파일 시에 수집해서 API 문서화에 사용되기도 하지만 JavaDoc이라는 좋은 문서화 도구가 있기에 문서화는 가장 비중이 낮은 어노테이션 사용법이다. 이외에도 컴파일 타임에 에러나 경고를 발생시켜 개발자에게 위험 요소를 알리는 목적으로도 사용된다. (= @Override)

가장 큰 비중을 갖는 것은 메타데이터로서의 용도이다. 메타데이터란 데이터를 위한 데이터, 데이터를 설명하는 데이터를 의미한다. 메타데이터로서 부가적인 표현뿐만 아니라 리플렉션을 접목하면 특정 클래스의 객체를 생성하고 주입하는 것이 가능하다. (= @Autowired)

Built-in Annotation

자바 SDK에서 기본적으로 제공하는 빌트인 어노테이션들이 존재한다.

@Override

현재 메서드가 슈퍼 클래스 혹은 인터페이스의 메서드를 오버라이드 했음을 컴파일러에게 명시한다. 만약 형식에 맞지 않게 메서드를 구현했다면 컴파일러가 인지하고 에어를 발생한다.

@Deprecated

마커 어노테이션으로 메서드를 사용하지 않도록 유도한다. 만약 사용한다면 컴파일 경고를 일으킨다.

@FunctionalInterface

해당 인터페이스가 함수형 인터페이스임을 명시한다. 만약 추상 메서드가 없거나 두 개이상 있다면 컴파일 에러가 발생한다.

⚾ Meta Annotation

메타 어노테이션이란 다른 어노테이션에서 사용되는 어노테이션을 말하며 후에 서술할 커스텀 어노테이션을 생성할 때 주로 사용된다. 가령 @Service 어노테이션은 @Component 어노테이션을 내포하고 있는데, 여기서 @Component가 메타 어노테이션에 해당한다.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface Service {

   @AliasFor(annotation = Component.class)
   String value() default "";
}

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Indexed
public @interface Component {

   String value() default "";
}

이외에도 대표적인 메타 어노테이션으로

@Retention

어노테이션이 적용되고 유지되는 범위를 명시하기 위해 사용한다.

@Retention(RetentionPolicy.RUNTIME) // 컴파일 이후에도 JVM에 의해서 참조가 가능하다.
@Retention(RetentionPolicy.CLASS)   // 컴파일러가 클래스를 참조할 때까지 유효하다.
@Retention(RetentionPolicy.SOURCE)  // 어노테이션 정보는 컴파일 이후 없어진다.

@Target

어노테이션을 적용할 위치를 결정한다.

@Target({ ElementType.PACKAGE, 			// 패키지 선언
		ElementType.TYPE, 				// 타입 선언
		ElementType.CONSTRUCTOR, 		// 생성자 선언
		ElementType.FIELD, 				// 멤버 변수 선언
		ElementType.METHOD, 			// 메소드 선언
		ElementType.ANNOTATION_TYPE, 	// 어노테이션 타입 선언
		ElementType.LOCAL_VARIABLE, 	// 지역 변수 선언
		ElementType.PARAMETER, 			// 매개 변수 선언
		ElementType.TYPE_PARAMETER,		// 매개 변수 타입 선언
		ElementType.TYPE_USE 			// 타입 사용
})

@Inherited

자식 클래스가 어노테이션을 상속받을 수 있다.

@Repeatable

반복적으로 어노테이션을 선언할 수 있다.

✨ Custom Annotation

자바에서 커스텀 어노테이션을 선언하는 것은 간단하다.

public @interface SimpleAnnotation {

}

여기에 메타 어노테이션을 붙여 적용 대상, 유지 정책 등을 결정하면 여러 상황에서 어노테이션을 메타데이터로써 활용이 가능하다.

가령, 멤버 변수에 명시 가능하고 @Target(ElementType.FIELD)

컴파일 이후에도 JVM에 의해 참조가 가능한 어노테이션 @Retention(RetentionPolicy.RUNTIME)

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface SimpleAnnotation {

	/* enum 타입을 선언 */
	public enum Status {
		STOP, MOVE
	}

	/* enum 사용 */
	Status quality() default Status.STOP;

	/* String 사용 */
	String value();

	/* 배열 사용 */
	int[] values();
}

참고로 어노테이션도 마치 클래스처럼 일종의 멤버 변수인 Element를 갖는 것이 가능하다.

공식 문서에 따르면 아래와 같은 타입만 허용한다.

A primitive type
String
Class or an invocation of Class
An enum type
An annotation type
An array type whose component type is one of the preceding types

후에 예시로 등장하겠지만 어노테이션 자체는 메타데이터를 담는 표식에 불과하지만 리플렉션을 통한 어노테이션의 적용 여부, 엘리먼트 값 처리 등을 할 수 있기에 매우 유용 사용된다.

️ Annotation & Reflection Sample Code

샘플 코드 깃 주소

@StringInjector 어노테이션

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target(ElementType.FIELD)
@Retention(RetentionPolicy.RUNTIME)
public @interface StringInjector {

    String value() default "Default name";
}

@StringInjector를 적용한 MyObject 클래스

@Data
public class MyObject {

    @StringInjector("Bart")
    private String name;

    @StringInjector
    private String defaultName;
}

Annotation & Reflection 처리 로직

import java.lang.reflect.Field;

public class MyContextContainer {
    public <T> T get(Class<T> clazz) throws IllegalAccessException, InstantiationException {
        T instance = clazz.newInstance();
        instance = invokeAnnonations(instance);
        return instance;
    }

    private <T> T invokeAnnonations(T instance) throws IllegalAccessException {
        // 클래스 필드를 가져오고
        Field[] fields = instance.getClass().getDeclaredFields();
        for (Field field : fields) {
            // 필드에 붙은 어노테이션을 가져오고
            StringInjector annotation = field.getAnnotation(StringInjector.class);

            if (annotation != null && field.getType() == String.class) {
                // 어노테이션의 엘리먼트 값으로 필드 값을 설정
                field.setAccessible(true);
                field.set(instance, annotation.value());
            }
        }
        return instance;
    }
}

테스트 코드

class MyContextContainerTest {

    @Test
    public void test_ANNOTATION_REFLECTION() throws Exception {
        MyContextContainer myContextContainer = new MyContextContainer();
        MyObject myObject = myContextContainer.get(MyObject.class);

        assertThat(myObject.getName()).isEqualTo("Bart");
        assertThat(myObject.getDefaultName()).isEqualTo("Default name");
    }
}

[2022.08.16 일상] 돌숭이, 일기 쓰기

Kangworld — Tue, 16 Aug 2022 00:48:02 +0900

돌숭이

슬랙 상태 이모지를 뭐로 할까.. 고민하다가

이말년 서유기의 주인공 돌숭이로 결정했다.

근데 뭐랄까... 돌숭이가 아니라...

흑백 세상의 아보카도 같아서 심심했는데

친절한 회사 디자이너분이 채색해 주셨다.

갸꿀

진짜 너무 귀엽다...

일기 쓰기

이전까지는 블로그에 하나의 글을 쓰기까지 매우 오랜 시간이 걸렸다.

어떻게 하면 읽기 편하게 쓸지

글의 구성은 어떻게 할지

정말 필요한 글인지

고민하다 미룬 글들이 오히려 더 많다.

그러다 보니 써야 할 글은 쌓여있고

글쓰기 = 무거운 일이 되어버려 손이 잘 안 갔다...

그래서 요즘 생각을 바꾼 게

글이 짧고, 큰 의미가 없고, 사소하더라도

하루에 겪었던 일상과 감정을 기록하면 좋을 것 같다.

매일은 아니더라도~

그나저나 오늘 건강검진인데 잠은 안 오고

가는 길에 침착맨 만났으면 좋겠다.

[Java] Chapter 1-5. Java의 Class 실습

Kangworld — Tue, 25 Jan 2022 23:30:25 +0900

✍️ Class 실습

Book 클래스(설계도)

public class Book {
	public String title; //String : 문자열을 저장하는 자료형
	public int price;
	public String publisher;
	public String author;
	public int page;
}

Book book;

변수 book은 클래스의 객체이다. 서술한 것처럼 객체도 하나의 변수로 한 개의 데이터만 저장할 수 있다.

book 자체는 한 개의 데이터만 저장할 수 있음에도 불구하고 book은 title, price, publisher, author, page에 대한 데이터를 모두 포함해야 한다. 이게 어떻게 가능할까?

실제로 title, price, publisher, author, page에 대한 정보는 메모리상 어딘가에 저장되어 있고 book은 그 메모리 주소 담고 있는 일종의 레퍼런스이다.

new 키워드

title, price, publisher, author, page에 대한 정보는 메모리상 어딘가에 있고 book은 그곳을 가리킨다.

이제 조금 더 의문을 가져보자.

Book book;

다음과 같이 변수 book을 선언만 해도 title, price, publisher, author, page을 위한 메모리 공간이 할당될까? 그렇지 않다.

클래스의 객체를 선언만 하면 실제 속성과 메서드가 할당될 메모리 공간을 가리킬 준비만 된 상태이고 실제 book을 이루는 데이터들의 메모리 공간이 할당되진 않는다.

코드를 작성해 보면 book의 price에 10을 할당하려 하면 에러가 발생한다.

public static void main(String[] args) {
	Book book;
	book.price = 10; // error!
}

여기서 모든 문제를 해결할 개념이 바로 new 키워드로, 객체에 실제 메모리를 할당할 때 new를 사용한다.

public static void main(String[] args) {
	Book book;
	book = new Book();
	
	book.price = 10; // OK!!
}

new 키워드로 실제 메모리 공간을 할당하면 그 순간부터 book을 Book 클래스의 '인스턴스'라고 부를 수 있다.

코드상의 변화를 알아보면, new 키워드로 book이 가리킬 메모리 공간을 할당하면 book에 .을 붙여 속성값을 가져오거나 새로운 값을 할당할 수 있는 멋진 일이 발생한다.

public static void main(String[] args) {
	Book book;
	book = new Book();
	
	book.title = "demian";
	book.price = 2000;
	book.publisher = "hello";
	book.author = "word";
	book.page = 123;
	
	System.out.println(book.title);
	System.out.println(book.price);
	System.out.println(book.publisher);
	System.out.println(book.author);
	System.out.println(book.page);
}

// 출력
demian
2000
hello
word
123

실습, Person 클래스 만들기

Person 클래스를 만들고 new 키워드를 사용해서 실제 객체에 메모리를 할당하고 원하는 값을 넣고 출력한다.

조건 1) Person 클래스의 속성은 이름(name), 나이(age), 키(height), 몸무게(weight)로 정의한다.

조건 2) 키와 몸무게 같은 실수형 데이터는 기본 자료형인 dobule로 선언한다.

public static void main(String[] args) {
	Person person = new Person();
	
	person.name = "침착맨";
	person.age = 20;
	person.height = 179.9;
	person.weight = 70.4;
	
	System.out.println(person.name);
	System.out.println(person.age);
	System.out.println(person.height);
	System.out.println(person.weight);
}

// 출력
침착맨
20
179.9
70.4

[Java] Chapter 1-4. Java의 Class, 사용자 정의 자료형

Kangworld — Mon, 24 Jan 2022 23:21:43 +0900

✍️ 기본 자료형 VS 사용자 정의 자료형

여기 문제가 하나 있다.

"정수 한 개를 저장하기 위한 변수 a를 선언하세요."

int a;

"정수형 변수 a를 선언했으면 a가 가진 메모리 공간에 10을 할당하세요."

a = 10;

또 문제가 주어졌다.

"책 한 권을 저장하기 위한 변수를 선언하세요."

Book book; // ???

Book이라는 자료형이 담고 있을 정보는 무수히 많다.

책의 제목, 가격, 출판사, 저자, 페이지 수 등 한 개의 기본 자료형으로는 책을 표현할 수 없다.

프로그래밍으로 책을 표현하기 위해선 책이 가지는 여러 정보를 담고 있을 한 묶음의 기억 공간이 필요하며 책이 가지는 속성(제목, 가격, 출판사...)이 무엇인가 고민하고 정의하는 것을 '설계'한다고 한다.

여기서 어떤 사물을 설계하기 위한 도구가 바로 class이다.

class라는 개념을 이용해 Book을 설계해 보자.

Book이라는 이름을 가진 Class 파일을 하나 추가하자.

책을 설계해 보자, 책에 필요한 상태 정보는 제목, 가격, 출판사, 저자, 페이지 수로 정의할 수 있다.

앞으로 책과 같은 현실 세계의 사물을 '객체'라고 부를 것이고 책이 가지는 상태 정보를 '속성'이라 부를것이다. 나아가 객체에는 행위가 포함되는데 이를 '메서드'라고 부를 것이다.

Book을 class의 형태로 설계하면 아래와 같고 이제부터 Book을 사용자 정의 자료형이라고 부를 수 있다.

참고로 String은 문자열을 저장하는 자료형이다.

public class Book {
	public String title; //String : 문자열을 저장하는 자료형
	public int price;
	public String publisher;
	public String author;
	public int page;
}

설계가 끝났으니 Book의 변수를 만들어보자.

그전에 정수형 변수를 살펴보고 넘어가자. 정수형 변수 a는 선언 시 정수를 위한 메모리 공간이 할당된다. 그렇기에 변수 a에 10을 바로 넣을 수 있는 것이다.

int a;
a = 10;

반면 Book은 여러 변수들의 집합으로 이루어진 자료형이다. 본디 하나의 변수엔 하나의 값만 저장할 수 있는데 어떻게 변수 book에 title이며 price며 여러 값들을 저장할 수 있을까?

Book book; //title, price, publisher... 여러 값들을 어떻게 book 하나에 넣지?

후에 다루겠지만 메모리 공간 어딘가에 변수 book이 가지는 속성(제목, 가격, 출판사)을 저장하고 있고, 변수 book은 그 메모리 공간을 참조하는 구조이기에 book은 자신이 가진 속성과 메서드에 접근할 수 있다.

예를 들어 100번지에 속성값들이 저장되어 있으면 변수 book은 100번지를 가리키는 형태이다.

몇 가지 더 설명하면, 다음과 같이 Book book; 변수 book을 선언하면 book을 '객체'라고 부르며 book에 실제 메모리 공간을 할당하면 book은 Book 클래스의 '인스턴스'라고 한다.

정리

세상에 존재하는 모든 사물은 객체로 만들 수 있으므로 class를 잘 설계하는 것이 객체지향 프로그래밍의 시작점이다.

다음 포스팅에선 객체를 생성하는 방법을 다룰 예정입니다.

[Java] Chapter 1-3. 프로그래밍의 3대 요소(변수, 자료형, 할당)

Kangworld — Mon, 24 Jan 2022 00:04:44 +0900

✍️ 프로그래밍의 3대 요소

프로그래밍의 3대 요소를 이해하면 Java뿐만 아니라 어떤 언어를 배워도 쉽게 이해할 수 있다.

프로그래밍의 3대 요소 : 변수, 자료형(Data type), 할당(=)

머릿속으로 493+1982를 구해보자. 피연산자 493과 1982를 머릿속으로 기억하고 계산해서 덧셈의 결과인 2475를 머릿속 어딘가에 잘 저장할 것이다.

프로그램도 마찬가지다. 493과 1982를 어딘가에 저장하고 더하고 결괏값을 저장해둘 것이다.

여기서 말하는 어딘가가 바로 메인 메모리를 의미하고 더 구체적으로 493, 1982, 2475가 저장되는 공간을 변수라고 한다.

변수는 다른 말로 기억 공간이라고 해석할 수 있으며 변수를 만들기 위해선 두 가지 요소를 고려해야 한다. 첫 번째로 '크기'를 고려해야 하고 두 번째로 정수인지 실수인지 문자인지 등 '어떤 종류의 데이터를 저장할 것인가'도 고려해야 한다. 프로그래밍 언어는 변수의 크기와 데이터의 종류를 함께 고려해서 이미 정의된 키워드를 개발자에게 제공하는데 이것이 바로 자료형이다. Java에서 4byte 정수형 변수의 자료형은 int, 8byte 실수형 변수의 자료형은 double이 대표적인 자료형이다.

자바 프로그래밍을 예시로 4byte 정수형 변수를 만들되 그 이름을 a라고 하고 싶다면 다음과 같이 작성할 수 있다.

그리고 이것을 조금 더 전문적인 용어로 'a라는 변수를 선언했다.'라고 말한다.

int a;

마지막으로 선언한 변수에 값을 넣어주는 것을 할당이라고 한다.

int a, b, c;
a = 493;
b = 1982;
c = a + b;

정리하면, 데이터들을 메모리에 들고 있기 위해 필요한 것은 변수, 변수의 크기와 종류를 결정짓는 것은 자료형, 변수에 데이터를 집어넣는 할당만 이해하면 프로그래밍을 시작할 수 있다.

int a, b, c;
a = 493;
b = 1982;
c = a + b;

System.out.println("덧셈의 결과 " + c);
// 덧셈의 결과 2475

Java의 자료형

컴파일러에서 기본적으로 제공해 주는 자료형을 기본 자료형이라 부른다.

정수형 : short, int, long

실수형 : float, double

문자형 : char

논리형 : boolean

int i = 10; // 정수형 4byte
System.out.println(i);

float f = 12.34f; // 실수형 4byte
System.out.println(f);

char c = 'A'; // 문자형 2byte
System.out.println(c);

boolean b = true;
System.out.println(b);

결과
10
12.34
A
true

간단한 프로그램은 기본 자료형만으로도 충분히 작성할 수 있지만 복잡한 프로그램은 기본 자료형만으론 해결할 수 없다. 사람, 책, 자동차 등 여러 정보를 포함하는 사물에 대한 기본 자료형은 제공하지 않기에 개발자가 직접 만들어서 사용해야 하는데 이를 사용자 정의 자료형이라 부르며 Java에선 클래스를 도입해서 이러한 문제를 해결하고 있다. 나아가 클래스를 활용해 프로그래밍하는 것을 객체지향 프로그래밍이라 한다.

Person person;
//기본적으로 이런 자료형은 없다.
//Person이 가진 성질을 이해하고 내가 설계해야함
//Person은 이름, 생년월일, 주민등록 번호, 성별이 포함될 수 있다.

변수의 선언과 할당, 심볼테이블

변수를 선언하면 변수를 위한 공간이 메인 메모리에 할당되며 공간의 위치를 '주소'라는 개념으로 구분한다.

int a;

예를 들어 변수 a를 위한 공간이 메인 메모리의 주소 1000번지라고 가정하면 값 999는 1000번지에 저장된 셈이다.

a = 999;

심볼테이블에 대해서 알아보자, 변수를 선언하면 변수의 이름과 주소를 담고 있는 심볼테이블(변수 목록표)에 변수가 추가된다.

변수 a를 선언한 시점에서 심볼테이블의 상태 [ a , 1000 ]

int a; // a의 주소는 1000

아래와 같이 코드를 작성하면 심볼테이블에서 a를 찾고 a의 주소인 1000을 참조해 메인 메모리에 888을 할당하게 된다.

a = 888;

만약 변수 b에 666을 할당하려 한다면 심볼테이블에서 b를 찾을 것이고, 테이블상에서 b라는 변수는 없기에 에러가 발생할 것이다.

b = 666; // error!

정리하면 심볼테이블은 선언된 변수들을 관리하기 위해서 만들어진 테이블이다.

[Java] Chapter 1-2. 자바의 구동방식(JVM)

Kangworld — Sun, 23 Jan 2022 19:44:42 +0900

✍️ 자바의 구동방식

자바 소스 코드(.java 파일)를 자바 컴파일러(javac)로 컴파일하면 결과물로 .class 확장자를 가진 파일이 생성된다.

.class 파일은 바로 실행할 수 없는 JVM만이 이해할 수 있는 bytecode로 구성된 파일로 자바 소스 코드를 실행하기 위해선 JVM을 반드시 거쳐서 실행해야 한다.

JVM을 사용하는 이유

자바 소스 코드를 실행하는 과정은 어느 정도 알겠는데 굳이 JVM을 사용하는 이유는 뭘까?

이를 이해하기 위해선 Java 이전의 프로그래밍언어인 C를 살펴볼 필요가 있다.

C/C++ 등 자바 이전의 프로그래밍 언어로 작성된 프로그램은 컴파일 시 재배치 가능한 오브젝트 파일이 생성되는데 이는 컴퓨터가 이해할 수 있는 기계어로 구성되어 있다.

문제는 오브젝트 파일을 만들어내는 컴파일러와 어셈블러는 현재 탑재된 CPU와 OS 구조를 참조해서 오브젝트 파일을 생성하기 때문에 다른 CPU와 OS가 탑재된 시스템에선 해당 오브젝트 파일을 해석할 수 없다. 예를 들어, Intel CPU와 Windows가 탑재된 컴퓨터에서 컴파일된 오브젝트 파일은 Intel CPU와 Linux가 탑재된 컴퓨터에서 해석할 수 없다.

이러한 C 계열 언어의 특징을 '플랫폼에 종속적이다.'라고 한다.

컴파일러와 어셈블러는 탑재된 CPU 구조를 참조한다?

프로그램(실행 가능한 파일)이란 0과 1로 구성된 명령어들의 집합으로 사람에 빗어 표현하면 '공부해, 청소해, 밥 먹어" 등의 컴퓨터가 수행할 동작들을 기계어로 작성해놨다고 생각하면 된다.

앞서 말한 프로그램을 실행하면 명령어들이 메인 메모리상에 적재되고 프로그램은 실행상태에 놓이게 된다. 이렇게 메모리에 적재되어 실행 중인 프로그램을 프로세스라고 부른다.

이제 CPU는 메인 메모리상에 적재된 명령어를 읽어오고 이에 따른 연산을 수행함으로써 프로그램이 동작하게 되는데 연산을 수행하는 주체인 CPU의 제조사마다 명령어가 다르다는 문제점을 가지고 있다. 마치 '밭 갈아!'라는 명령어를 한국인이라면 잘 이해하지만 외국인은 이해하지 못하는 것처럼 말이다.

이처럼 컴파일러는 특정 CPU를 타깃으로 한 어셈블리 프로그램을 만들고 어셈블러는 컴파일러의 결과물을 재배치 가능한 오브젝트 파일로 변환한다.

이러한 이유로 컴파일러와 어셈블러는 CPU 구조를 참조할 수밖에 없는 종속인 형태를 띠게 된다.

다시 JVM

다시 자바로 돌아와서 이야기하면, 자바 컴파일러는 탑재된 CPU가 Intel CPU든 AMD CPU든 결과물로 동일한 .class 파일을 생성하면 되고 .class 파일을 현재 환경에 맞게 해석하는 작업은 오롯이 JVM이 수행한다.

정리하면 자바 컴파일러는 OS와 CPU에 구애받지 않고 .class 파일을 만드는 것에 집중하고 그것을 환경에 맞게 해석하는 것은 JVM이 담당한다.

이러한 구조의 장점으로 환경이 변하더라도 코드를 다시 컴파일하거나 수정할 필요 없이 .class 파일과 현재 환경에 맞는 JVM만 있으면 어디서든 실행 가능한 파일을 만들 수 있다. 이러한 자바의 특징을 '플랫폼에 독립적이다.'라고 한다.

다만 자바도 완벽하게 플랫폼에 독립적이진 않다. C언어의 컴파일러가 CPU에 종속적인 것처럼 자바의 JVM도 CPU와 OS에 종속적일 수밖에 없다. 결국 자바도 현재 실행 환경에 맞는 JVM을 따로 설치해야한다는 불편한 진실이 숨어있다.

커맨드 라인으로 자바 실행하기

1.간단하게 hello world!를 출력하는 코드를 작성하고

public class JavaTest {
	public static void main(String[] args) {
		System.out.println("hello world!");
	}
}

2. CMD창을 열어 소스코드가 있는 src 폴더로 이동

C:\Users\USERNAME>

cd C:\Users\USERNAME\Java\workspace\JavaHello\src

C:\Users\USERNAME\Java\workspace\JavaHello\src>

3. 자바 컴파일러 javac로 소스코드를 컴파일하기

C:\Users\USERNAME\Java\workspace\JavaHello\src>javac.exe JavaTest.java

4. 컴파일의 결과물로 .class 파일이 생생 된다.

5. .class 파일을 확장자명 없이 java.exe 명령어에 넘겨주면 자바 소스코드가 실행된다.

java.exe는 내부적으로 jvm을 구동하는 명령어라고 생각하면 된다.

C:\Users\USERNAME\Java\workspace\JavaHello\src>java.exe JavaTest
hello world!

[Java] Chapter 1. Java 개발 환경 구축

Kangworld — Tue, 18 Jan 2022 00:43:48 +0900

✍️ Java 개발 환경 구축하기

자바 프로그램을 실행하기 위해선 자바 실행환경 JRE(Java Runtime Environment)만 있으면 되지만 자바 개발을 위해선 반드시 JDK가 필요하다. JRE는 JVM(Java Virtual Machine), Java 클래스 라이브러리 등이 포함되어 자바 프로그램이 실행될 환경을 제공한다.

일반적으로 개발 측면에서 자바를 설치한다는 것은 JDK를 설치한다는 의미이다. JDK는 Java Development Kit의 줄임말로, JDK는 JRE를 포함한 자바 컴파일러(javac)와 jdb, javadoc와 같은 도구가 포함되어 자바 프로그램을 개발할 환경을 제공한다.

Java로 소프트웨어를 만들기 위해선 개발 환경이 구축돼야 한다. 개발 환경은 다른 말로 플랫폼이라 하며 플랫폼에 따라 구축 방법이 다르다. 대표적인 개발 환경으로 JavaSE, JavaEE, JavaME, Java Android가 있다.

JavaSE는 Java Standard Edition의 약자로 자바 프로그램을 만들기 위한 모든 개발 환경은 JavaSE로 시작하며 여기에 추가적인 API를 붙여서 기능을 확장할 때 우리는 이것을 JavaEE, JavaME라고 부른다.

JavaEE는 웹 프로그래밍에 필요한 API가 포함되어 있고 JavaME는 임베디드 프로그램에 필요한 API가 포함되어 있다.

JDK를 설치하면 JavaSE 개발 환경이 구축되고 JavaSE의 바운더리 내에 있는 Java 프로그램을 만들 수 있다. 참고로 웹 프로그래밍을 위해선 JavaEE 개발 환경을 구축해야 한다.

본 포스팅에선 JDK를 다운받아 JavaSE 개발 환경을 구축하려 한다.

JDK와 Eclipse 다운받기

Windows64 기준으로

JDK 다운로드

Eclipse 다운로드, Java 코딩에 사용할 IDE로 Eclipse를 사용한다. 그냥 Visual Studio 같은 녀석으로 코딩하고 컴파일도 하고 실행도 하고 디버깅도 할 수 있는 툴이다.

1. JDK를 설치해 준다. 놀랍게도 금방 끝난다.

2. Windows + r 키를 눌러 실행창을 열어주고 sysdm.cpl을 입력

3. 고급 -> 환경 변수

4. Path 클릭 -> 편집 클릭

5. C:\Program Files\Java\jdk-17.0.1\bin를 환경 변수에 추가하기.

17.0.1는 버전에 따라 다를 수 있으니 본인의 jdk 버전에 맞게 입력하시면 됩니다.

6. 이클립스를 다운로드하고 압축을 풀고 실행한다.

7. File -> New -> Project 클릭

8. Java Proejct 선택

9. JavaHello 프로젝트 생성

10. src 오른쪽 클릭 -> New -> Class 클릭

11. 성의 없지만 클래스 명은 JavaTest로 만들어주고 main 메서드를 클래스 내부에 포함하도록 만든다.

12. main 메서드 내에 System.out.println("hello world!");를 입력하고 실행하면 콘솔 창에 hello world!가 출력된다.

System.out.println()를 빠르게 작성하는 팁은 syso를 입력하고 Ctrl + Space를 누르면 자동완성된다.

[C#] Task.FromResult 이해하기

Kangworld — Fri, 24 Dec 2021 01:33:31 +0900

✍️ Task.FromResult

await 키워드를 만나면 세 가지 경우의 수가 발생한다.

첫 번째, awaitable이 실행 과정에서 예외를 발생하면 exception을 던진다.

awaitable
간단하게 Task 또는 Task<T>를 반환하는 함수(+메서드)라고 생각하면 된다.

+awaitable은 void도 반환하지만 Task를 반환하는 awaitable과는 결이 다르다고 한다.

자세한 내용은 링크를 참조하길 바랍니다.

두 번째, awaitable이 이미 완료된 Task라면 async 메서드를, 마치 일반 메서드처럼, 동기 방식으로 계속 실행한다.

세 번째, awaitable이 끝나지 않았다면 작업이 끝난 후 await 이후의 나머지 코드를 실행하도록 대기 작업으로 등록하고 async 메서드의 호출자에게 Task를 반환한다.

본 포스팅은 Task.FromResult를 다루며 이는 두 번째 상황과 관련이 있다.

Task 클래스 내부의 CompletedTask 프로퍼티는 작업이 완료된 더미 Task를 반환한다.

나아가 완료된 더미 Task에 어떠한 값을 실어서 보내고 싶다면 특정 메서드를 사용하면 되는데 이게 바로 본 포스티에서 다룰 Task.FromResult 메서드이다.

상식선에서 생각해 봤을 때 완료된 Task는 비동기식으로 실행할 필요가 없다. 왜냐? 이미 끝났으니 말이다.

그렇다면 Task 클래스는 어떤 이유로 완료된 더미 Task를 제공하는 걸까?

여기에 대한 답은 바로 캐싱과 관련이 있다.

Task.FromResult와 캐싱

예를 들어 비동기적으로 서버로부터 유저의 닉네임을 받아오는 GET 메서드가 있다.

개발자 K 씨는 A라는 유저의 닉네임이 필요해 GET 메서드를 호출했다.

K 씨는 이것저것 코드를 작성하다가 다시 유저 A의 닉네임이 필요해졌다.

반복적으로 유저 A의 닉네임이 필요한 상황... 개발자 K 씨는 이 상황을 어떻게 풀어갈까?

첫 번째, 다시 GET 메서드를 호출해서 닉네임을 얻어오면 매우 쉽다. 그런데 서버로부터 어떤 값을 얻어오는 작업엔 적지 않은 시간이 걸리므로 이를 반복적으로 수행하는 건 문제가 있어보인다.

두 번째, 일종의 캐싱으로 딕셔너리를 선언해서 유저의 닉네임이 딕셔너리에 없다면 1회에 한정해 값을 서버로부터 받아와 딕셔너리에 저장한다. 이후에 유저의 닉네임이 필요하면 딕셔너리에서 값을 빼오면 된다.

다르게 말하면, GET 메서드 내부에서 키에 해당하는 Value가 있다면 Task.FromResult 메서드를 이용해 값을 즉시 반환하면 되고 없다면 비동기적으로 서버로부터 값을 얻어오면 된다. (데이터의 동기화에 관한 문제는 남아있지만 괜찮은 해결법 같다.)

예제 코드

MS Docs에 좋은 예제가 있어서 가져왔다.

코드의 흐름은 위에서 설명한 것과 매우 유사하다.

예제 코드 링크

using System;

namespace AsyncEX
{
    using System;
    using System.Collections.Concurrent;
    using System.Diagnostics;
    using System.Linq;
    using System.Net;
    using System.Threading.Tasks;

    class CachedDownloads
    {
        // 다운로드된 결과물 저장하는 캐시
        static ConcurrentDictionary<string, string> cachedDownloads =
           new ConcurrentDictionary<string, string>();

        // 요청을 비동기적 혹은 동기적으로 수행하는 메서드
        public static Task<string> DownloadStringAsync(string address)
        {
            // 캐시에 존재하는지 확인
            string content;
            if (cachedDownloads.TryGetValue(address, out content))
            {
                return Task.FromResult<string>(content);
            }

            // 캐시에 없다면 다운하고 캐시에 저장
            return Task.Run(async () =>
            {
                content = await new WebClient().DownloadStringTaskAsync(address);
                cachedDownloads.TryAdd(address, content);
                return content;
            });
        }

        static void Main(string[] args)
        {
            // 다운받을 URL 주소
            string[] urls = new string[]
            {
         "http://www.naver.com",
         "http://www.google.com"
            };

            Stopwatch stopwatch = new Stopwatch();

           
            stopwatch.Start();
            var downloads = from url in urls
                            select DownloadStringAsync(url);
            
            // 캐시를 활용하지 못하는 케이스
            Task.WhenAll(downloads).ContinueWith(results =>
            {
                stopwatch.Stop();
                Console.WriteLine("Retrieved {0} characters. Elapsed time was {1} ms.",
                   results.Result.Sum(result => result.Length),
                   stopwatch.ElapsedMilliseconds);
            })
            .Wait();

            // 캐시를 활용하는 케이스
            stopwatch.Restart();
            downloads = from url in urls
                        select DownloadStringAsync(url);
            Task.WhenAll(downloads).ContinueWith(results =>
            {
                stopwatch.Stop();

                Console.WriteLine("Retrieved {0} characters. Elapsed time was {1} ms.",
                   results.Result.Sum(result => result.Length),
                   stopwatch.ElapsedMilliseconds);
            })
            .Wait();
        }
    }

}

팁은 아래와 같이 Task.Run과 람다식을 이용하면 동기 메서드 내에서 비동기 메서드를 호출할 수 있다는 것이다!

return Task.Run(async () =>
{
      content = await new WebClient().DownloadStringTaskAsync(address);
      cachedDownloads.TryAdd(address, content);
      return content;
});

[C#] C#은 모든 자료형이 객체일까?

Kangworld — Wed, 15 Dec 2021 05:25:28 +0900

❓ C#은 모든 자료형이 객체일까?

한 가지 의문으로부터 본 포스팅은 시작한다.

오늘 문득 생각에 잠겨 C#은 진짜 모든 자료형을 객체로 취급할까?라는 의문을 품고 직접 검증에 나섰다.

결론부터 말하면 모든 자료형을 객체로 취급한다는 말은 엄연히 틀리며 해석하기에 두 가지 답을 제시할 수 있다.

✍️ int는 객체인가?

C#에서 모든 자료형은 객체인가를 알기 전에 int는 객체인가 대한 정답을 내리면 정답에 한걸음 다가갈 수 있지 않을까?

기본적으로 C#에선 class와 String(string)은 Reference-type이며 struct와 enum은 Value-type이다.
여기서 한 가지 중요한 사실은 int와 같은 원시 타입은 구조체로 구현했단 점이다.

https://keumjae.tistory.com/177

int는 구조체로 구현했다. 굉장히 많은 의미를 담고 있는 문장이다. 왜냐하면 많은 사람들이 C#의 구조체는 상속받을 수 없으며 상속할 수도 없는 자료형으로 알고 있기 때문이다. 그럼에도 불구하고 int는 System.ValueType이란 추상 클래스를 상속받고 있다.
코드를 작성해 보면 int는 최상위 클래스 object가 제공하는 ToString 메서드를 사용 가능한 점을 고려했을 때 int(구조체)가 System.ValueType을 상속받는 것은 자명해 보인다.

다만 여전히 의구심이 든다. 정말 구조체가 상속을 받을 수 있는 거야?
여기에 저명한 C# 개발자 Eric Lippert가 stackoverflow에 답변을 남겼다.

간략하게 정리하자면 구조체가 클래스를 상속받는 것은 가능하며 모든 구조체는 System.Object로부터 파생된 System.ValueType 클래스를 암시적으로 상속받고 있다. 따라서 사용자 정의 구조체를 비롯한 모든 구조체는 임의의 클래스로부터 상속받는것은 명백히 불가능하다.

추가 자료

C# language spec, 4.1.1:

4.1.1 The System.ValueType type

All value types implicitly inherit from the class System.ValueType, which, in turn, inherits from class object. It is not possible for any type to derive from a value type, and value types are thus implicitly sealed (§10.1.1.2).

Then, later (4.1.3) struct is explicitly defined to be a value type:

4.1.3 Struct types

A struct type is a value type that can declare constants, fields, methods, properties, indexers, operators, instance constructors, static constructors, and nested types.

그렇다면 모든것들이 객체일까?

다시 원래 궁금증으로 돌아오면, 그렇다면 C#에서 모든 것은 객체일까?
여기에 대한 두 가지 해석이 존재한다.
해석이 갈리는 이유는 C#에서 객체라는 단어가 다소 모호한데, .NET framework에서 정의한 System.Object의 별칭이 객체(object)이며 또한 동적으로 생성된 클래스의 인스턴스도 객체라고 부르기 때문이다.

첫 째로 상속적인 측면에서 모든 것을 객체라고 묻는다면 "거의 모든 것들"은 객체이다.
모든 Value-type과 클래스, 배열, 델리게이트는 System.Object를 상속받음으로써 객체이나 인터페이스 타입과 포인터는 System.Object을 상속받지 않아 객체라고 말할 순 없다.
이처럼 거의 모든 타입이 System.Object를 상속받아 객체라고말 할 수 있지만 여전히 레퍼런스 타입과 벨류타입이 다뤄지는 혹은 동작하는 방식이 매우 다르기에 이는 두번째 해석으로 이어진다.

두 번째로 Reference-type과 Value-type의 관점으로 본다면 명백히 모든 것은 객체가 아니다.
Value-type이 System.Object를 상속받으나 그것들이 Reference-type(객체)과 전혀 다르게 취급된다.
예를 들면 Value-type은 데이터를 자체적으로 할당된 메모리에 저장하는 반면 Reference-type은 실제 데이터가 할당된 주소 공간을 가리킨다. 그뿐만 아니라 다른 변수에 값을 대입하는 과정도 이 둘은 너무나 다른 결과를 야기한다.
즉, Value-type과 Reference-type은 전혀 다르게 다뤄지며 Value-type을 명시적으로 박싱(Boxing)해야만 Reference-type으로 변환된다.

int num = 23; // 23이 num에 할당됨 
Object obj = num; // 박싱(Boxing)

https://www.partech.nl/nl/publicaties/2021/07/what-is-boxing-and-unboxing-in-c-sharp#

결론

C#은 모든 자료형을 객체로 취급하지 않는다.

거의 모든 자료형은 System.Object를 상속받는다는 표현이 적합하다.

[Unity] 절차적 애니메이션(Procedural animation) #2

Kangworld — Mon, 13 Dec 2021 01:13:58 +0900

절차적 애니메이션 #1

[Unity] 절차적 애니메이션(Procedural animation) #1

✍️ 절차적 애니메이션이란? 대부분의 게임에서 캐릭터 애니메이션은 정적이다. 캐릭터가 움직일 때 필요한 동작은 아티스트들이 사전에 만들어놓은 애니메이션을 재생하는 것으로 다른 움직

kangworld.tistory.com

✍️ Two Bone IK Constraint

다양한 동작들을 유도할 수 있는 서로 다른 제약조건(Constraints)이 있다.

파트 1에서 알아본 Multi-Aim Constraint는 본이 특정 오브젝트를 바라보도록 유도하는 제약조건이었다.

본 포스팅에선 Two Bone IK Constraint를 알아보며 절차적 애니메이션 포스팅을 마무리하려 한다.

Two Bone IK Constraint를 사용하기 전에 IK라는 단어가 굉장히 낯설어 이에 대해 정리하는 것으로 시작하겠다.

Inverse Kinematics(IK, 역 기구학)

Forward Kinematics과 Inverse Kinematics는 로봇공학에서 주로 등장하는 용어로

Forward Kinematics란 관절 각도(θ)를 조절해서 로봇의 손이 목표점에 도달하게 하는 것으로 쉽게 말하면 관절의 각도를 손끝의 위치로 변환하는 수학적 계산법을 의미한다.

반면 Inverse Kinematics란 목표점이 주어지면 손이 목표에 도달하기 위한 관절 1과 관절 2의 각도가 산출되는 것으로 쉽게 말하면 손끝의 위치를 관절의 각도로 변환하는 수학적 계산법을 의미한다.

예를 들어 Inverse Kinematics는 목표점 A가 주어지면 관절의 각도

θ 1과 θ 2

를 잘 계산해서 목표점으로 팔을 움직인다.

️ 다시 Two Bone IK Constraint

Inverse Kinematics의 정의를 고려해 Two Bone IK Constraint가 무엇인지 예상해 보면, Two Bone IK Constraint는 목표점이 주어졌을 때 두 개의 뼈대가 유기적으로 움직이도록 하는 제약조건이다.

백 번의 설명보단 한 번의 코딩이 더 설득력 있듯 직접 만들어보자.

Hierarchy 창에서 던전 스켈레톤을 클릭하고 Animation Rigging - Rig Setup을 클릭하면 Rig 2 오브젝트가 생성된다.

개발자 감수성을 자극하는 불편한 오브젝트 이름이다. Rig 1 -> HeadRig, Rig 2 -> ArmRig으로 변경해 주자.

ArmRig의 자식으로 Empty 오브젝트를 하나 만들어서 Two Bone IK Constraint 컴포넌트를 추가하자.

Two Bone IK Constraint 컴포넌트에 세 개의 본 Root, Mid, Tip을 넘겨줘야 한다.

Two Bone IK Constraint임에도 세 개의 본을 넘겨주는 이유는 아마도 세 개의 관절을 얻기 위함인 것 같다.(Two Bones = Three Joints)

본 포스팅에선 Root에 UpperArm(상완), Mid에 ForeArm(전완), Tip에 Hand(손)을 넘겨줘서 팔을 유기적으로 움직여 볼 예정이다.

이제 Source Objects를 넘겨줘야 할 차례로 ArmMover 산하에 Empty Object(Target)를 하나 만들어서 Source Object에 넘겨주자.

먼저, Target을 처음 생성하면 바닥에 박혀있는 것을 확인할 수 있는데 Target의 위치를 L Hand에 배치해 보자.

Target을 클릭하고 Ctrl을 누른 상태에서 Bip001 L Hand를 클릭하고 상단의 Animation Rigging - Align Transform을 클릭하면 Target이 L Hand에 위치한다.

이제 실행해 보면 애니메이션을 재생하고 있음에도 불구하고 손은 제자리에 있다. 나아가 Target을 움직일 때마다 팔이 따라온다.

한 가지 팁은 게임을 실행하고 Target을 원하는 위치로 움직이고 Target - Transform - Copy World Placement 후 게임을 종료하고 Target - Transform - Paste World Placement를 하면 이전에 지정한 위치로 Target이 이동해 있다.

이는 여러 가지로 응용이 가능한데, 예를 들면 무기를 잡는 위치를 지정할 때 유용하다.

추가로 하나의 Rig에 Constraint가 여러 개인 경우 Hierarchy 순서대로 적용된다.

본 포스팅을 예로 들면, HeadAim이 먼저 적용되고 다음으로 ChestAim이 적용된다.

마무리

Unity에선 여러 Constraint를 사용한 예제를 제공하니 필요한 게 있다면 찾아서 공부할 수 있다!

참고 Make your Characters Interactive! - Animation Rigging in Unity