데코레이터(Decorator) 패턴은 객체의 기능을 동적으로 확장할 수 있도록 하는 디자인 패턴입니다.

커피를 주문해볼까. . .

여러분은 스타벅스 알바생입니다. 음료를 만드는 데 꽤나 힘이 드니 3가지 음료만 만듭니다. 에스프레소 베이스 메뉴, 말차 베이스 메뉴가 있고, 적절한 토핑과 함께하면 아래와 같이 맛있는 메뉴가 탄생합니다!

베이스 2종(에스프레소, 말차)과 3가지 토핑(우유, 글레이즈드 폼, 카라멜 시럽)을 적절히 조합해 커피를 판매해보려고 합니다. 이 때, 3가지 종류의 토핑은 기본 베이스를 확장해주는 데코레이터입니다.

요구사항 정리

• 베이스: 에스프레소(4000원), 말차(5000원)
• 토핑: 우유(500원), 글레이즈드 폼(300원), 카라멜 시럽(400원)

1. 라떼: 에스프레소 + 우유 (4500원)
2. 카라멜 라떼: 에스프레소 + 우유 + 카라멜 시럽 (4900원)
3. 말차 글레이즈드 라떼: 말차 + 우유 + 글레이즈드 폼 + 카라멜 시럽 (6200원)

에스프레소와 말차 베이스만 있다면 다~ 만들 수 있어

먼저 커피 인터페이스를 만들어줍니다.

• 커피 인터페이스

public interface Coffee {
    int getPrice();
}

이제 커피 인터페이스를 구현해 베이스 2종을 만들어주겠습니다. 에스프레소 베이스는 4000원, 말차 베이스는 5000원입니다.

• 에스프레소 베이스

public class Espresso implements Coffee{
    @Override
    public int getPrice() {
        return 4000;
    }
}

• 말차 베이스

public class Matcha implements Coffee{
    @Override
    public int getPrice() {
        return 5000;
    }
}

베이스 두 개 완성!

토핑 3개면 나도 바리스타

이번에는 3가지 토핑(우유, 글레이즈드 폼, 카라멜 시럽)을 만들어보겠습니다.

토핑은 토핑만으로 커피가 될 수 없고, 반드시 베이스와 결합되어야 합니다. 그렇기 때문에 내부에 베이스 커피가 포함되어야 하고, 필드로 Coffee를 갖고 있어야 합니다. 또한 기본 생성자가 아닌 Coffee를 파라미터로 받는 생성자를 통해서만 Milk 객체를 만들 수 있습니다.

그리고, 베이스 음료에 우유를 넣게 되면, 가격은 기존 음료에서 500원이 추가됩니다.

• 우유 데코레이터

public class Milk implements Coffee {

    private Coffee coffee;

    public Milk(Coffee coffee) {
        this.coffee = coffee;
    }

    @Override
    public int getPrice() {
        return coffee.getPrice() + 500;
    }
}

동일한 방식으로, 글레이즈드 폼과 카라멜 시럽도 만들어보겠습니다.

• 글레이즈드 폼 데코레이터

public class GlazedFoam implements Coffee {

    private Coffee coffee;

    public GlazedFoam(Coffee coffee) {
        this.coffee = coffee;
    }

    @Override
    public int getPrice() {
        return coffee.getPrice() + 300;
    }
}

• 카라멜 시럽 데코레이터

public class CaramelSyrup implements Coffee{

    private Coffee coffee;

    public CaramelSyrup(Coffee coffee) {
        this.coffee = coffee;    
    }

    @Override
    public int getPrice() {
        return coffee.getPrice() + 400;
    }
}

커피 공장을 두두두두

자! 이제 모든 준비가 끝났습니다. 베이스 2종(에스프레소, 말차)과 3가지 토핑(우유, 글레이즈드 폼, 카라멜 시럽)을 적절히 조합해 커피를 만들어보겠습니다.

1. 라떼: 에스프레소 + 우유 (4500원)
2. 카라멜 라떼: 에스프레소 + 우유 + 카라멜 시럽 (4900원)
3. 말차 글레이즈드 라떼: 말차 + 우유 + 글레이즈드 폼 + 카라멜 시럽 (6200원)

커피 공장에서 라떼를 만들어보겠습니다. 라떼는 에스프레소 베이스에, 우유를 넣으면 됩니다! 에스프레소 베이스가 4000원, 우유가 500원이기 때문에 라떼의 가격은 4500원입니다.

• 라떼

public class CoffeeFactory {

    public static Coffee latte() {
        return new Milk(new Espresso());
    }
}

에스프레소 베이스를 우유 데코레이터로 래핑시켜주었더니 라떼가 만들어졌습니다!

테스트 코드를 통해 4500원이 맞는지 확인해봅니다.

class CoffeeFactoryTest {

    @Test
    void makeLatte() {
        Coffee latte = CoffeeFactory.latte();
        assertThat(latte.getPrice()).isEqualTo(4500);
    }
}

마찬가지로 카라멜 라떼, 말차 글레이즈드 라떼도 만들어보겠습니다.

카라멜 라떼는 에스프레소 베이스(4000원)에 우유(500원), 카라멜 시럽(400원)을 추가하면 되며, 가격은 4900원입니다.

말차 글레이즈드 라떼는 말차 베이스에 우유(500원), 글레이즈드 폼(300원), 카라멜 시럽(400원)을 추가하면 되며, 가격은 6200원입니다.

public class CoffeeFactory {

    // 라떼 생략

    public static Coffee caramelLatte() {
        return new CaramelSyrup(new Milk(new Espresso()));
    }

    public static Coffee matchaGlazedLatte() {
        return new GlazedFoam(new CaramelSyrup(new Milk(new Matcha())));
    }
}

코드를 보면, 말차 글레이즈드라떼를 만들기 위해 여러 데코레이터가 재귀적으로 말차 베이스를 래핑하고 있습니다.

이처럼 데코레이터 패턴은 객체의 기능을 확장하거나 변경해야 할 때, *객체를 *재귀적으로 결합하여 서브 클래스가 폭발적으로 많아지는 문제를 해결할 수 있는 구조적(Structural) 디자인 패턴입니다.

지금은 세 가지 메뉴 조합만 있지만, 바닐라 시럽, 초코 드리즐, 자바칩, 모카 소스, 휘핑크림, . . . 등 데코레이터가 늘어난다면 만들 수 있는 메뉴도 기하급수적으로 늘어나게 됩니다.

자바칩 초코 프라푸치노는 에스프레소 베이스에 모카 소스, 휘핑크림, 초코 드리즐을 추가하면 만들 수 있습니다. 이 외에 바닐라 라떼, 초코 바닐라 라떼, 자바칩 프라푸치노,초코 라떼 등 수많은 커피 메뉴를 탄생시킬 수 있습니다!

커피 공장에서 카라멜 라떼를 만들어 4900원인지 확인하고, 말차 글레이즈드라떼를 만들어 6200원이 맞는지 테스트 코드를 통해 확인해보겠습니다.

class CoffeeFactoryTest {


    // 라떼 테스트 코드 생략

    @Test
    void makeCaramelLatte() {
        Coffee caramelLatte = CoffeeFactory.caramelLatte();
        assertThat(caramelLatte.getPrice()).isEqualTo(4900);
    }

    @Test
    void makeMatchaGlazedLatte() {
        Coffee matchaGlazedLatte = CoffeeFactory.matchaGlazedLatte();
        assertThat(matchaGlazedLatte.getPrice()).isEqualTo(6200);
    }
}

모든 테스트가 성공했습니다!

그럼 지금까지 구현한 내용을 클래스 다이어그램으로 그려보겠습니다.

베이스 2종과 토핑 3종 모두 커피 인터페이스를 구현하고 있으며, 토핑 3종(Milk, GlazedFoam, CaramelSyrup)은 베이스 2종(Espresso, Matcha)에 결합될 수 있는 데코레이터로서 내부 필드로 커피 타입을 갖고 있습니다.

그런데 저희가 흔히 보는 데코레이터 패턴의 클래스 다이어그램은 저렇게 생기지 않았던 것 같은데요. 이제 데코레이터 추상 클래스를 추가해서 우유, 글레이즈드폼, 카라멜 시럽이 상속받도록 변경해 토핑 3종이 데코레이터라는 것을 조금 더 명확하게 드러내보겠습니다.

추상 클래스를 잘 써보자!

추상 클래스는 추상 메서드와 변수를 가질 수 있습니다. 위에 구현한 내용을 아래 그림처럼 바꿔보겠습니다.

CoffeeDecorator는 추상 클래스로, Coffee 인터페이스를 구현합니다. 이때 Coffee 인터페이스의 getPrice() 메서드의 구현은 Milk, GlazedFoam, CaramelSyrup 클래스에서 하게 됩니다.

커피 토핑은 반드시 베이스가 있어야 하기 때문에, 필드에 Coffee를 선언하고, Coffee 타입을 받는 생성자를 만들어줍니다.

• 커피 데코레이터 추상 클래스

public abstract class CoffeeDecorator implements Coffee {
    Coffee coffee;

    public CoffeeDecorator(Coffee coffee) {
        this.coffee = coffee;
    }
}

❓ Coffee 인터페이스를 구현했는데 왜 getPrice() 메서드를 오버라이드하라는 에러가 안뜨지

CoffeeDecorator는 추상 클래스이기 때문에 이 자체로 객체를 만들 수 없습니다. 결국 다른 구체(concrete) 클래스가 CoffeeDecorator를 구현해줘야 합니다. 추상 클래스이기 때문에, 추상 메서드를 가질 수 있습니다. CoffeeDecorator가 인터페이스에 있는 메서드를 구현해도 되지만, 그 아래의 구체 클래스에서 구현해도 됩니다.

이제 CoffeeDecorator 추상 클래스를 상속 받는 Milk, GlazedFoam, CaramelSyrup을 만들어보겠습니다.

• 우유

CoffeeDecorator 추상클래스를 상속받는 Milk 클래스를 만들고, Coffee 인터페이스에 있던 getPrice() 메서드를 구현해줍니다.

이때 Milk는 상위 클래스인CoffeeDecorator로부터 coffee 인스턴스 필드를 상속 받아 아래와 같이 사용할 수 있습니다.

public class Milk extends CoffeeDecorator {

    public Milk(Coffee coffee) {
        super(coffee);
    }

    @Override
    public int getPrice() {
        return coffee.getPrice() + 500;
    }
}

앗. . 그런데 에러가 났습니다.

패키지 구조를 살펴보겠습니다.

CoffeeDecorator와 Milk는 다른 패키지에 있습니다. CoffeeDecorator의 coffee는 default 접근 제어자로 설정 되어 있기 때문에 다른 패키지에서는 접근할 수 없습니다. 따라서 protected 접근제어자로 바꿔줍니다.

protected 접근 제어자를 사용하면, 패키지 위치가 다른 자식 클래스에서 해당 필드에 접근이 가능합니다.

• 커피 데코레이터 추상 클래스 수정

public abstract class CoffeeDecorator implements Coffee {
    protected Coffee coffee;

    // 생성자 생략
}

에러가 해결됐습니다!

이제 글레이즈드폼과 카라멜 시럽도 마저 만들어주겠습니다.

• 글레이즈드폼

public class GlazedFoam extends CoffeeDecorator {

    public GlazedFoam(Coffee coffee) {
        super(coffee);
    }

    @Override
    public int getPrice() {
        return coffee.getPrice() + 300;
    }
}

• 카라멜 시럽

public class CaramelSyrup extends CoffeeDecorator {

    public CaramelSyrup(Coffee coffee) {
        super(coffee);
    }

    @Override
    public int getPrice() {
        return coffee.getPrice() + 400;
    }
}

커피 공장, 에스프레소, 말차, 테스트 코드는 그대로입니다.

테스트 코드를 돌려 라떼, 카라멜 라떼, 말차 글레이즈드 라떼가 잘 만들어지는지 확인해보겠습니다.

커피를 열심히 만들면서 데코레이터 패턴에 대해 알아봤습니다. 말차 글레이즈드 라떼는 참 맛있습니다.

다음 번에는 데코레이터 패턴과 구조는 동일하지만 용도가 다른 프록시 패턴을 알아보겠습니다람쥐

추상화는 객체 지향 프로그래밍의 핵심적인 특징입니다. 추상화를 통해 간단한 인터페이스를 제공하고, 복잡한 구현은 뒤로 감춰줍니다.

Java에서는 인터페이스와 추상 클래스를 통해 추상화를 달성합니다.

이 둘은 어떤 차이점이 있을까요?

🛫 인터페이스

인터페이스에 선언 가능한 것들을 살펴보도록 하겠습니다.

1️⃣ 추상 메서드

public interface Animal {

    // 추상 메서드
    void makeSound();
    void move();
}

추상 메서드는 구현부({ })가 없는 메서드입니다. 오직 메서드 이름과 파라미터만 가지며, abstract 키워드를 붙여 정의합니다.

인터페이스에 구현부가 없는 메서드를 정의하면, 컴파일러가 abstract 키워드를 자동으로 붙여줍니다.

이때 추상 메서드의 접근 제어자는 오직 public으로만 선언할 수 있습니다.

private, protected 등으로 선언 시 위와 같이 컴파일 에러가 발생합니다.

2️⃣ 상수

public interface Animal {

    // 상수
    int MAX_AGE = 100;

}

인터페이스에서 변수를 선언할 때는 항상 public, static, final로만 선언할 수 있습니다. 즉, 인터페이스에서 선언된 모든 변수는 상수로 취급되며, 변경할 수 없습니다.

🤔 왜 인터페이스의 변수는 모두 static final일까?

자바의 인터페이스는 인스턴스화(=객체화)할 수 없습니다. 그렇기에 객체가 생성될 때 만들어지는 인스턴스 변수도 가질 수 없습니다.

Animal animal = new Animal(); // 컴파일 에러

따라서, 인터페이스에서는 정적 컨텍스트에서 공유될 수 있는 상수만 정의할 수 있습니다.

int animalMaxAge = Animal.MAX_AGE;

인터페이스에서 정의한 변수는 인터페이스 이름과 함께 사용할 수 있습니다.

🙋‍♂️ 참고) private static final은 사용 불가

3️⃣ 구현 메서드 - default 메서드

Java8 이전에는 인터페이스가 구현 메서드를 가지지 않았습니다. Java8 이후, 인터페이스에 static과 default 메서드가 추가되며 구현 메서드를 제공하고 있습니다.

Java8은 왜 default 메서드를 추가했을까?

앞서 제시한 Animal 인터페이스를 구현한 Cow, Lion 클래스를 만들었습니다. 인터페이스에 선언한 makeSound(), move() 메서드를 각 구현체에서 구현한 모습입니다.

public class Cow implements Animal{
    @Override
    public void makeSound() {
        System.out.println("음메에에에");
    }

    @Override
    public void move() {
        System.out.println("아주 느리게 한 칸..");
    }
}

public class Lion implements Animal{
    @Override
    public void makeSound() {
        System.out.println("어흥");
    }

    @Override
    public void move() {
        System.out.println("아주 빠르게 열 칸!!!!");
    }
}

그런데 이런 클래스가 100개가 있다고 가정해보겠습니다. (양, 고양이, 돼지, 말, 얼룩말, ...)

개발 도중에 요구사항이 바뀌어 몇몇 동물들은 이제 소리를 내고, 움직이는 것 외에도 잠을 잘 수 있게 되었습니다!! Animal 인터페이스에 sleep() 추상 메서드를 추가했습니다.

public interface Animal {

    // 기존 추상 메서드
    void makeSound();
    void move();

    // 새롭게 추가된 추상 메서드
    void sleep();
}    

그럼 이제 100개의 동물 클래스에서 이런 에러를 만나게 됩니다. 새로 추가된 sleep() 메서드를 구현하라는 내용입니다.

그런데 대부분의 동물들은 동일한 패턴으로 잠에 듭니다. 따라서 동물별로 sleep() 메서드를 다르게 구현할 필요가 없습니다. 또 하나의 메서드를 추가했을 뿐인데, 100개의 클래스를 일일이 수정하는 것도 번거롭습니다.

이러한 상황을 해결하고자, Java8은 default 메서드를 소개합니다.

기존 인터페이스에 새로운 default 메서드를 추가하더라도, 구현체를 변경할 필요가 없습니다. 즉, 구현체에서 default 메서드를 별도로 구현하지 않더라도, 인터페이스에 정의된 default 메서드를 곧바로 사용할 수 있습니다.

💡 Java8은 인터페이스에 왜 default 메서드를 도입했을까? 인터페이스에 새로운 default 메서드를 추가하더라도, 기존의 구현체들에서 이 새로운 메서드를 구현하도록 강제하지 않아도 된다.

✏️ default 메서드 사용하기

default 메서드는 인터페이스에서 바로 구현하며, 하위 클래스에서 별도로 구현하지 않고 바로 사용할 수 있습니다. 또한 default 메서드는 하위 클래스에서 선택적으로 재정의할 수 있습니다.

Animal 인터페이스에 sleep() 메서드를 추가했습니다. 이때 default 키워드를 붙여 default 메서드임을 명시해줍니다.

public interface Animal {

    // 추상 메서드
    void makeSound();
    void move();

    // default 메서드
    default void sleep() {
        System.out.println("Zzz... 동물이 잠을 잡니다.");
    }
}

소(Cow)와 사자(Lion)는 sleep() 메서드에 대한 별다른 구현을 하지 않더라도 sleep()을 호출할 수 있습니다.

Animal cow = new Cow();
Animal lion = new Lion();

cow.sleep();
lion.sleep();

이처럼 default 메서드는 하위 클래스에서 별도로 구현하지 않고도 사용할 수 있습니다. 기존의 구현체들을 변경하지 않고 인터페이스에 새로운 기능을 추가할 수 있다는 점이 큰 장점인데요!

✍️ default 메서드는 하위 클래스에서 재정의할 수 있다.

위의 예시처럼 인터페이스에 정의한 default 메서드를 그대로 사용할 수도 있지만, 하위 클래스에서 재정의하여 사용할 수도 있습니다.

예를 들어, 거꾸로 매달려서 잠을 자는 박쥐를 생각해보겠습니다.

일반적인 동물들과는 다른 방식으로 잠을 자는 박쥐는 구현체에서 default 메서드(sleep())를 재정의하려고 합니다.

public class Bat implements Animal{
    @Override
    public void makeSound() {
        System.out.println("대롱대롱");
    }

    @Override
    public void move() {
        System.out.println("하늘에서 날기");
    }

    // default 메서드 재정의 - 선택적
    @Override
    public void sleep() {
        System.out.println("Zzz... 박쥐는 매달려서 잠을 잡니다.");
    }
}

소, 사자, 박쥐가 잠을 자는 코드를 실행해보겠습니다.

Animal cow = new Cow();
Animal lion = new Lion();
Animal bat = new Bat();

cow.sleep();
lion.sleep();
bat.sleep();

Cow와 Lion은 별도로 default 메서드를 재정의하지 않았기 때문에, 인터페이스에 정의한 내용이 출력됩니다. Bat은 구현체에서 default 메서드를 재정의했기 때문에, 구현체에서 오버라이딩한 내용이 출력됩니다.

참고) 다중 인터페이스 상속 시 발생할 수 있는 Default 메서드 충돌 문제

자바는 인터페이스의 다중 상속을 허용합니다. 소는 동물이면서, 일을 할 수 있습니다. Workable 인터페이스를 정의하고, 소가 Animal과 Workable을 모두 구현하도록 했습니다. 이때 일을 할 때도 잠시 잠을 자며 휴식할 수 있기 때문에 sleep() default 메서드를 정의했습니다.

public interface Workable {
    void work();

    default void sleep() {
        System.out.println("Zzz... 일하다가 잠시 잠에 듭니다.");
    }
}

public class Cow implements Animal, Workable{
    @Override
    public void makeSound() {
        System.out.println("음메에에에");
    }

    @Override
    public void move() {
        System.out.println("아주 느리게 한 칸..");
    }

    @Override
    public void work() {
        System.out.println("소는 우유를 만듭니다.");
    }
}

위 코드에서는 아래와 같은 에러 메시지를 발견할 수 있습니다.

Cow는 Animal과 Workable 인터페이스의 sleep() 메서드를 둘 다 상속 받기 때문에, 충돌이 발생한 것입니다. 따라서 하위 클래스에서 default 메서드(sleep())를 재정의하여 어느 것을 호출해야 할지 명시적으로 정해줘야 합니다.

@Override
public void sleep() {
    Animal.super.sleep();
    /* 별개로 구현해도 됨 */
}

4️⃣ 구현 메서드 - static 메서드

Java8부터 인터페이스에서 default 메서드와 함께 static 메서드도 정의할 수 있게 되었습니다. static 메서드는 특정 인스턴스에 종속되지 않기에, 메서드 이름 앞에 인터페이스 이름을 붙여 호출합니다.

public interface Animal {

    /* 생략 */

    // static 메서드
    static String getCode() {
        return "ANIMAL";
    }
}

System.out.println(Animal.getCode()); // ANIMAL 출력

이와 더불어, static 메서드는 다른 static 메서드 또는 default 메서드에서도 호출될 수 있습니다. 또한, public 및 private 접근 제어자로 선언할 수 있습니다.

public interface Animal {

    /* 생략 */

    default void eat(String food) {
        // default 메서드 내에서 static 메서드 호출
        if (isEdible(food)) {
            System.out.println("동물이 " + food + "을(를) 먹습니다.");
        } else {
            System.out.println("이 음식은 먹을 수 없습니다!");
        }
    }

    private static boolean isEdible(String food) {
        // 음식이 먹을 수 있는지 검증하는 로직
        return !food.equals("돌") && !food.equals("흙");
    }
}

5️⃣ 구현 메서드 - private 메서드

Java9 이후 인터페이스에 private 구현 메서드를 정의할 수 있습니다. Java8에서 추가된 default 메서드와 static 메서드의 코드를 캡슐화하기 위해 등장했습니다.

⭐️ 인터페이스 요약 ⭐️ (1) 인터페이스를 인스턴스화할 수 없다. (구현체가 필요) (2) 인터페이스에서 정의하는 변수는 모두 public, static, final한 상수이다. (3) 추상/구현 메서드에서 final 키워드를 사용할 수 없다. (4) 추상/구현 메서드의 접근 제어자가 protected가 될 수 없다. (5) 추상 메서드의 접근 제어자는 오직 public이다. (6) Java8부터 default, static 구현 메서드가 제공된다. default 메서드의 접근 제어자는 public이며, static 메서드는 public/private 둘 다 사용 가능하다. (7) Java9부터 private 구현 메서드가 제공된다.

🌟 인터페이스 VS 추상 클래스

Java8부터 인터페이스도 구현 메서드를 제공하게 되면서 인터페이스와 추상 클래스의 경계가 조금 흐릿해졌습니다.

그럼에도 불구하고 여전히 유의미한 차이가 존재하며, 그 중 객체 지향적 관점에서 추상 클래스가 필요한 이유를 설명해보려고 합니다.

🐰 추상 클래스는 public이 아닌 추상 메서드를 가질 수 있다.

인터페이스에 추상 메서드를 선언 시 오직 public 접근 제어자만 사용할 수 있습니다.

반면, 추상 클래스의 경우 public과 더불어 protected 추상 메서드를 가질 수 있습니다.

이것이 왜 유효한 차이인지 헐리우드 원칙과 템플릿 메서드 패턴을 소개하며 설명을 이어가보도록 하겠습니다.

🎥 헐리우드 원칙

📞 "Don't Call Us, We'll Call You"

헐리우드 원칙의 핵심은 "자꾸 연락하지마 내가 연락할게"입니다. 여기서 연락을 하는 주체는 고수준 컴포넌트이며, 연락을 받는 대상은 저수준 컴포넌트입니다.

☝️ Low-Level Components Are Passive

저수준 컴포넌트는 고수준 컴포넌트를 호출하지 않습니다. 저수준 컴포넌트는 수동적인 존재로, 고수준 컴포넌트의 호출이 있을 때까지 기다립니다.

✌️ High-Level Components Control the Flow

고수준 컴포넌트는 애플리케이션 실행 흐름에 대한 제어권을 갖고 있습니다. 저수준 컴포넌트가 언제, 어떻게 행동해야 할지를 결정합니다. 즉 고수준 컴포넌트가 저수준 컴포넌트르 호출하여, 특정 변화 또는 이벤트가 있을 때 저수준 컴포넌트가 적절하게 반응할 수 있도록 시스템의 흐름을 제어합니다.

헐리우드 원칙은 관찰자 패턴(Observer Pattern), 템플릿 메서드 패턴(Template Method Pattern), 이벤트 기반 아키텍처(Event Driven Architecture) 등에서 사용됩니다.

🔧 헐리우드 원칙을 준수하여 추상 클래스 설계하기

아래와 같은 요구사항을 떠올리며 Animal 추상 클래스를 정의해보겠습니다.

(1) 동물들은 밥을 먹습니다. (2) 밥을 먹으려면 사냥을 해야 합니다. (3) 사냥 방법은 동물마다 다릅니다. (4) 그 외의 밥 먹는 순서는 동물마다 동일합니다.

Animal 추상 클래스 안에 eat() 메서드를 선언하고, 구현부를 정의했습니다. 이때 eat() 메서드 내부에서 추상 메서드인 hunt()를 호출하고 있습니다.

public abstract class Animal {

    public final void eat() {
        System.out.println("사냥을 해야 밥을 먹을 수 있어요.");
        hunt();
        System.out.println("잡아온 밥을 먹어요.");
    }

    protected abstract void hunt();
}

이제 Animal 클래스를 상속 받은 고양이(Cat)와 사자(Lion) 클래스를 만들어보겠습니다. 각 클래스에서 hunt() 메서드를 구현합니다.

public class Cat extends Animal {
    @Override
    protected void hunt() {
        System.out.println("냐옹~ 쥐를 잡았어요.");
    }
}

public class Lion extends Animal {
    @Override
    protected void hunt() {
        System.out.println("어흥! 토끼를 잡았어요.");
    }
}

이제 두 가지 동물 객체를 만들고, eat() 메서드를 실행해보도록 하겠습니다.

Animal cat = new Cat();
Animal lion = new Lion();

cat.eat();
lion.eat();

고양이와 사자가 각각 다른 방법으로 사냥을 해서 밥을 먹습니다. 주목할 점은, 외부에서 hunt()를 따로 호출하지 않았지만, 자식 클래스에서 재정의한 hunt() 메서드도 함께 호출되었다는 점입니다.

⺁ 추상 클래스는 고수준 컴포넌트, 구체 클래스는 저수준 컴포넌트

Animal은 추상 클래스, Cat과 Lion은 Animal을 상속받은 구체 클래스입니다. 이때 추상 클래스인 Animal은 상위(고수준) 컴포넌트라 불리며, 구체 클래스인 Cat과 Lion은 하위(저수준) 컴포넌트라 불립니다.

추상 클래스 → 상위(고수준) 컴포넌트 구체 클래스 → 하위(저수준) 컴포넌트

eat() 메서드가 동작할 때, 각 구현체에서 정의한 hunt() 메서드가 호출됩니다.

구체 클래스에서 구현한 hunt() 메서드는 추상 클래스의 eat() 메서드가 호출할 때까지 수동적으로 기다립니다.

즉, 추상 클래스(고수준)가 구체 클래스(저수준)를 호출하여 프로그램의 흐름을 제어하고, 반대로 구체 클래스는 추상 클래스에 있는 메서드를 호출하지 않습니다. 또한 구체 클래스의 hunt() 메서드는 본인이 언제 호출되는지를 모르며, 수동적인 태도로 호출되기를 기다립니다.

📐 템플릿 메서드 패턴

템플릿 메서드(Template Method) 패턴은 헐리우드 원칙을 준수하는 디자인 패턴입니다.

여러 클래스에서 공통으로 사용하는 메서드를 템플릿화하여 상위 클래스에서 정의하고, 하위 클래스마다 세부 동작 사항을 다르게 구현합니다.

즉, 변하지 않는 기능(템플릿)은 상위 클래스에 만들어두고 자주 변경되며 확장할 기능은 하위 클래스에서 만들도록 하여, 세부 실행 내용을 다양화할 수 있습니다.

💡 Tip 디자인 패턴에서의 템플릿은 변하지 않는 것을 의미한다.

public abstract class Animal {

    public final void eat() {
        System.out.println("사냥을 해야 밥을 먹을 수 있어요."); // 1
        hunt(); // 2
        System.out.println("잡아온 밥을 먹어요."); // 3
    }
    protected abstract void hunt();
}

Animal 추상 클래스의 eat() 메서드에서 1과 3의 내용은 모든 구현체에서 변하지 않는 내용입니다. 반면 2의 경우 하위 클래스에서 오버라이딩하여 구현체마다 변경될 수 있는 부분입니다.

이렇게 상위 클래스에서는 뼈대를 만들어두고, 템플릿 메서드에 포함된 메서드들의 구체적인 구현은 하위 클래스가 담당하게 하는 것을 템플릿 메서드 패턴이라고 합니다.

🏝️ 템플릿 메서드 패턴과 추상 클래스

public abstract class Animal {

    public final void eat() {
        System.out.println("사냥을 해야 밥을 먹을 수 있어요.");
        hunt();
        System.out.println("잡아온 밥을 먹어요.");
    }

    protected abstract void hunt();
}

Animal 추상 클래스를 다시 살펴보면 두 가지 특징이 있습니다.

1️⃣ 템플릿 메서드(eat())의 final 키워드

템플릿 메서드 eat()은 final로 선언되어 있어 자식 클래스에서 오버라이드할 수 없습니다.

→ 🌟 추상 클래스 속 템플릿 메서드는 final로 선언되어 오버라이드되지 않아야 합니다.

2️⃣ 추상 메서드(hunt())의 protected 접근 제어자

추상 메서드 hunt()의 접근제어자를 protected로 선언함으로써 캡슐화를 보장하고, 템플릿 메서드 패턴의 의도를 지킬 수 있습니다.

아래 세 가지의 목적을 달성하기 위해 protected 추상 메서드가 필요합니다 ❗️

💊 캡슐화

hunt()는 eat()의 내부적인 동작이므로 외부에서 hunt()를 직접 호출할 일이 없습니다. 만약 public으로 선언 시 불필요하게 구현 세부사항이 노출됩니다.

🎥 헐리우드 원칙 준수

고수준인 추상 클래스 속 eat() 메서드가 저수준인 구체 클래스 속 hunt()가 언제 호출될지를 결정합니다.

만약 public으로 선언 시 바깥에서 hunt()를 직접 호출할 수 있게 됩니다. 그럼 "먼저 연락하지 마세요. 저희가 연락 드리겠습니다"는 의미를 갖는 헐리우드 원칙을 깨뜨리게 됩니다.

✍️ 명시적으로 템플릿 메서드 패턴의 의도를 드러냄

hunt() 추상 메서드를 protected 접근 제어자로 선언함으로써, hunt()는 외부에서 호출 가능한 public API가 아니라, 하위 클래스에서 구현만 하면 된다는 점을 명시합니다.

Animal 추상 클래스의 이 두 가지 특징은 인터페이스에서는 볼 수 없는 특징입니다!

*인터페이스는 메서드 앞에 final 키워드를 붙일 수 없으며, protected 접근 제어자도 사용할 수 없습니다. *

🆚 템플릿 메서드 패턴과 인터페이스, 추상 클래스

Java8 이후 인터페이스도 구현 메서드를 제공할 수 있게 되면서, 위와 비슷하게 코드를 작성할 수 있게 되었습니다. default 메서드 속에서 추상 메서드를 호출하고, 추상 메서드는 각 구현체에서 정의합니다.

public interface Animal {
    default void eat() {
        System.out.println("사냥을 해야 밥을 먹을 수 있어요.");
        hunt();
        System.out.println("잡아온 밥을 먹어요.");
    }

    abstract void hunt();
}

그러나, default 메서드의 경우 하위 클래스에서 재정의가 가능합니다. (🚨→ 캡슐화 위반) 또한, hunt() 추상 메서드의 접근 제어자는 public만 사용할 수 있기 때문에 외부에서의 호출을 막을 수 없습니다. (🚨→ 헐리우드 원칙 위반)

이러한 이유로, 보통 템플릿 메서드 패턴은 추상 클래스를 이용해 구현합니다. 인터페이스로 구현할 수 있는 대표적인 디자인 패턴으로는 전략 패턴이 있습니다.

참고) 헐리우드 원칙과 템플릿 메서드 패턴, 그리고 Spring 프레임워크

헐리우드 원칙의 핵심은 "자꾸 연락하지마 내가 연락할게"입니다. 이는 프레임워크에서 자주 사용되는 개념입니다.

스프링 프레임워크와 개발자가 작성하는 애플리케이션을 생각해보면, 개발자는 프레임워크의 동작에 대해 아무것도 알지 못하고 참견하지도 못합니다. 코드를 작성하기만 하면, 스프링 프레임워크는 개발자가 작성한 코드를 호출합니다.

웹에서 /velog로 HTTP 요청이 들어오는 경우를 생각해보겠습니다. 개발자는 컨트롤러에 @GetMapping(/velog) 어노테이션이 붙은 메서드를 작성합니다. 다만, 개발자는 이 메서드가 언제 어디서 호출되는지 알지 않습니다. 그 결정은 고수준 컴포넌트인 스프링이 알아서 해주고 있습니다.

모든 웹 요청의 진입점 역할을 하는 DispatcherServlet 클래스를 살펴보겠습니다. DispatcherServlet은 FrameworkServlet 추상 클래스를 상속 받고 있습니다. processRequest()라는 메서드는 HTTP 요청을 처리하는 역할을 수행하며, 템플릿 메서드 패턴으로 구현되어 있습니다.

public abstract class FrameworkServlet extends HttpServletBean implements ApplicationContextAware {

    protected final void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try {
            this.doService(request, response);
        } /* 생략 */
    }    

    protected abstract void doService(HttpServletRequest request, HttpServletResponse response) throws Exception;
    /* 생략 */    
}

FrameworkServlet의 processRequest()라는 메서드는 템플릿 메서드입니다. 변하지 않는다는 의미를 final 키워드를 통해 확인할 수 있습니다. processRequest()는 웹에서 요청이 들어왔을 때 처리해야 하는 작업들의 뼈대를 정의하고 있으며, 추상 메서드인 doService()를 내부에서 호출하여 세부적인 내용은 구현체가 만들도록 합니다.

doService()는 하위 클래스인 DispatcherServlet에서 아래와 같이 정의하고 있습니다.

public class DispatcherServlet extends FrameworkServlet {
    protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception {
    /* 생략 */
    }
}

🌟 요약 🌟 (1) 추상 클래스는 public이 아닌 추상 메서드를 가질 수 있다. (인터페이스는 only public) (2) 헐리우드 원칙을 준수한 설계를 하기 위해 protected 추상 메서드가 필요하다. (3) 헐리우드 원칙: "자꾸 연락하지마 내가 연락할게" (4) 템플릿 메서드 패턴은 헐리우드 원칙을 준수하는 대표적인 디자인 패턴이며, 프레임워크에서 주로 사용된다. (5) 인터페이스는 protected 접근 제어자 및 final 키워드를 사용할 수 없다. 템플릿 메서드 패턴을 구현 시 이 두 가지가 필요하다.

🎐 그 밖의 차이점 총정리

기억해볼 만한 내용은, 인터페이스에는 오직 상수만 정의할 수 있지만 추상 클래스에는 모든 종류의 변수를 선언할 수 있다는 것입니다.

또한, 다중 상속이 필요한 경우 인터페이스를 고려해야 합니다.

🐋 마치며

인터페이스와 추상 클래스를 정리하며, 그 둘의 차이점을 알아봤습니다. 인터페이스와 추상 클래스는 객체 지향 프로그래밍에서 추상화를 달성하기 위해 Java에서 제공하는 주요 메커니즘입니다. 이 두 가지를 적절히 활용하면 코드의 유연성과 재사용성을 높일 수 있습니다. 템플릿 메서드 패턴에서 protected 추상 메서드가 필요하다는 점을 통해 인터페이스와 추상 클래스의 차이점을 설명해보았습니다. 긴 글 읽어주셔서 감사합니다!

참고자료

Why are Interface Variables Static and Final - StackOverflow Static Final Variables - Baeldung Jvm Static Storage - Baeldung Static and Default Methods in Interfaces - Baeldung Hollywood principal - Medium Template Method - Refactoring.Guru Abstract Methods and Classes - Oracle Template Method Pattern - dzone

안녕하세요! 오늘은 자바 문자열을 주제로 포스팅해보려고 합니다. 먼저 아래 문제들을 살펴보도록 하겠습니다. ✈️🌝

문제 1

String str1 = "abc";
String str2 = "abc";

// 출력 결과는? 
System.out.println(str1==str2);
System.out.println(str1.equals(str2));
System.out.println(str1.hashCode()==str2.hashCode());

문제 2

String str3 = new String("abc");
String str4 = new String("abc");

// 출력 결과는?
System.out.println(str3==str4);
System.out.println(str3.equals(str4));
System.out.println(str3.hashCode()==str4.hashCode());

정답은, 차례대로

## 문제 1
true
true
true

## 문제 2
false
true
true

입니다.

🐰 자바에서 문자열을 만드는 방법

자바에서는 문자열을 크게 두 가지 방식으로 만들 수 있습니다.

1️⃣ String Literal

String usingLiteral = "velog";

두 개의 큰따옴표(" ")로 묶인 텍스트를 String Literal이라고 합니다.

2️⃣ new 연산자

String usingNew = new String("velog");

new 연산자를 사용해 새로운 String 객체를 생성하는 방법입니다.

🏊 String Literal 방식과 Java String Pool

먼저, String Literal 방식부터 살펴보겠습니다.

자바의 힙 메모리 영역에는 Java String Pool(또는 String Constant Pool)이라는 공간이 존재합니다. JVM이 문자열을 효율적으로 관리하기 위해 사용하는 장소인데요!

JVM은 String 변수를 선언하고 String Literal 방식으로 값을 할당할 때, 동일한 값을 가진 문자열이 이미 스트링 풀에 존재하는지 탐색합니다.

String str1 = "abc";
String str2 = "abc";

만약 스트링 풀에 "abc"라는 문자열이 이미 존재한다면, 추가적인 메모리 할당 없이 기존 문자열에 대한 참조값을 반환합니다.

반대로 "abc"라는 문자열이 스트링 풀에 없다면, 이를 새로 추가한 뒤 참조값을 반환합니다.

위의 예시에서 str2에 값을 할당할 때에는 스트링 풀에 이미 "abc"가 존재합니다. 따라서 str2는 str1과 스트링 풀 속 동일한 공간을 가리키게 됩니다.

System.out.println(str1==str2); // true
System.out.println(str1.equals(str2)); // true
System.out.println(str1.hashCode()==str2.hashCode()); // true
}

1. str1==str2

== 연산자의 경우 두 개의 인스턴스가 메모리 상에서 같은 공간을 참조하고 있는지를 비교합니다. 위의 그림을 통해 확인했듯이, str1과 str2는 스트링 풀 속 동일한 공간을 가리키고 있습니다. 따라서 true가 출력됩니다.

2. str1.equals(str2)

String은 equals() 메서드를 재정의해 동등 비교가 가능합니다. str1과 str2는 모두 "abc"라는 논리적으로 동일한 문자열을 지칭합니다. 즉, str1과 str2는 동등하다고 판단되기에 true가 출력됩니다.

3. str1.hashCode()==str2.hashCode()

String은 equals()와 함께 hashCode()도 재정의하고 있습니다. 논리적으로 동일한 인스턴스는 같은 해시 코드를 반환합니다. 따라서 true가 출력됩니다.

참고) String Interning

스트링 풀에 이미 문자열이 존재하는지 확인하고, 재사용하는 작업을 String Interning이라고 합니다. 이를 통해 논리적으로 내용이 같은 문자열은 동일한 메모리 공간에서 공유될 수 있도록 합니다.

String Literal 방식을 사용하면, 내부적으로 Interning을 수행합니다. 이밖에 String.intern() 메서드를 직접 사용할 수도 있습니다.

String str1 = new String("abc");
String str2 = str1.intern();
System.out.println(str1.equals(str2)); // true
System.out.println(str1.hashCode()==str2.hashCode()); // true

🆕 new 연산자 방식

new String() 방식은 언제나 새로운 String 객체를 생성합니다.

new 연산자를 사용해 String 객체를 생성 시, 자바 컴파일러는 새로운 객체를 생성해 힙 메모리에 저장합니다. 이렇게 생성되는 객체는 항상 서로 다른 메모리 영역에 위치하게 됩니다.

String str1 = new String("abc");
String str2 = new String("abc");

객체의 주소값을 비교하는 == 연산을 통해 str1과 str2의 메모리 주소가 같은지, 다른지 확인해보도록 하겠습니다!

System.out.println(str3 == str4); // false

false가 출력되었고, 같은 값을 갖더라도 new 연산자로 String 객체를 만들면 다른 메모리 주소를 참조한다는 것을 확인할 수 있습니다.

🙅 String은 불변 객체

Oracle 공식 문서에 따르면,

Strings are constant; their values cannot be changed after they are created.

String 객체는 불변합니다.

String 클래스는 final로 선언되어 있으며, value 및 coder, hash 필드 등으로 구성되어 있습니다.

그 중 value 필드는 byte[] 타입의 배열로, 문자열의 실제 문자 데이터를 저장합니다. 이 필드는 final로 선언되어 있기 때문에, String *객체가 한 번 생성된 이후에는 변경할 수 없습니다. *

객체의 실제 메모리 위치(참조)에 따라 해시코드를 반환하는 System.identityHashCode를 사용해 String의 불변성을 직접 확인해보도록 하겠습니다.

String hello = "hello";
System.out.println(System.identityHashCode(hello)); //2060468723
hello = hello + " velog";
System.out.println(System.identityHashCode(hello)); //1933863327

1. String hello = "hello";

"hello"라는 문자열 리터럴은 스트링 풀에 저장됩니다. hello는 문자열 풀에 있는 "hello" 객체를 참조합니다.

2. " velog"

" velog"도 문자열 리터럴이므로 스트링 풀에 저장됩니다.

3. hello + " velog"

문자열 연결 연산자(+)를 통해 새로운 문자열 객체가 힙 메모리에 생성됩니다. 이때는 new 연산자를 사용한 것과 같이 스트링 풀에 저장되지 않습니다.

따라서 위의 코드는 아래와 같이 세 개의 문자열 객체를 생성합니다. 즉, 기존 문자열이 변경되는 것이 아니라 새로운 객체를 만들어 참조하게 됩니다.

🟰 Equals And HashCode

기본적으로, Object 클래스는 equals() 및 hashCode() 메서드를 정의하고 있습니다. 따라서 자바의 모든 클래스는 이 두 메서드를 사용할 수 있습니다.

Object 클래스가 디폴트로 정의한 equals() 메서드는 객체의 동일성을 비교합니다. 즉, 같은 메모리 공간을 참조하고 있는지를 확인합니다. 이를 물리적 동일성(인스턴스의 메모리 주소가 같음)이라고 합니다.

그런데 서로 다른 주소 값을 가지더라도, 내용물이 같아 같은 인스턴스라고 정의하고 싶은 경우가 있습니다. 이를 논리적 동일성(논리적으로 두 인스턴스가 같음)이라고 하며, 동등성이라고도 합니다.

만약 equals() 메서드를 통해 객체의 동등성을 비교하고 싶다면, 해당 메서드를 오버라이드 해주어야 합니다. (동등성 vs 동일성)

String 클래스는 아래처럼 equals() 메서드를 재정의하여 동등성 비교가 가능합니다.

먼저, 비교하려는 객체가 자기 자신과 동일하다면 true를 반환합니다. 두 번째로, 객체가 String 타입인지 확인해 아니라면 false를 반환합니다. 이후 두 문자열의 실제 문자 내용을 비교하여 내용이 같다면 true를 반환합니다.

String 타입의 객체를 동등 비교해보도록 하겠습니다. new 연산자를 사용해 같은 값을 갖는 두 개의 객체를 만들었습니다.

String str3 = new String("abc");
String str4 = new String("abc");

System.out.println(str3.equals(str4)); // true
System.out.println(str3.hashCode()==str4.hashCode()); // true

str3과 str4는 서로 다른 메모리 공간을 참조하고 있지만, 문자열 내용이 같기 때문에 equals() 비교 결과 동등하다고 판단합니다. 즉, 값으로 비교가 가능해집니다.

자바에서 equals()를 재정의하면, hashCode()도 함께 재정의해주는 것이 관례입니다. 논리적으로 동일한 두 인스턴스는 같은 해시 코드 값을 반환하도록 해야 합니다. 또한 HashMap, HashSet과 같은 Hash 기반의 자료 구조를 사용할 때 hashCode()를 재정의하지 않으면 문제가 발생할 수 있습니다. 따라서 동등성 비교를 위해서는 equals()를 재정의해야 하며, 이때 hashCode()도 함께 재정의하는 것이 권장됩니다.

🏡 StringBuilder와 + 연산자의 차이점은?

StringBuilder 클래스는 내부에 변경 가능한 byte 배열을 가집니다. StringBuilder 클래스는 AbstractStringBuilder 추상클래스를 상속받습니다.

이때 AbstractStringBuilder 추상 클래스는 String 클래스와 달리 byte 배열을 final로 선언하지 않습니다.

따라서 StringBuilder 클래스는 String 클래스와 달리 변경이 가능한 데이터 구조를 가집니다. 문자열을 추가 및 삭제 또는 삽입 시 새로운 객체를 만들지 않고 기존 객체를 활용합니다. 따라서 문자열에 대한 작업을 훨씬 효율적으로 처리합니다.

문자열을 두 가지 방법으로 합쳐보며 테스트를 진행해보도록 하겠습니다.

먼저, StringBuilder를 활용한 예제입니다.

StringBuilder sb = new StringBuilder("hello");
System.out.println(System.identityHashCode(sb));
sb.append(" velog");
System.out.println(System.identityHashCode(sb));

append 연산 전과 후의 StringBuilder 객체는 같은 메모리 공간을 참조하고 있는 것을 확인할 수 있습니다. 즉, 새로운 StringBuilder 객체를 생성하지 않고 내부의 값을 변경했습니다.

실행 결과

이와 반면, + 연산자를 사용해 두 개의 문자열을 합치게 되면 새로운 String 객체가 생성됩니다. 연산 전과 후 참조하고 있는 메모리 주소가 다른 것을 확인할 수 있습니다.

String str = new String("hello");
System.out.println(System.identityHashCode(str));
str += " velog";
System.out.println(System.identityHashCode(str));

문자열에 대한 연산을 할 때마다 새로운 객체를 생성하게 되면 커다란 GC 오버헤드 문제가 발생할 수 있습니다. 이럴 때는 StringBuilder를 사용하는 것을 고려해볼 수 있습니다.

🍊 마치며

자바 공부를 다시 하면서 놓치고 있었던 String과 관련한 개념들을 정리해봤습니다. 자바에서 제공해주는 클래스들을 사용할 때 한 번씩 타고 들어가 살펴보는 습관을 기르려고 합니다 🐰🥕

참고 자료

String - Oracle Java String Pool - Baeldung Interning of String in Java - GeeksForGeeks String Interning - StackOverFlow String is Immutable - GeeksForGeeks Equals and HashCode - Baeldung

프로젝트를 진행하며 아래처럼 생긴 클래스를 자주 만들었던 기억이 있습니다.

@AllArgsConstructor
@NoArgsConstructor
@Builder
public class Member {
    private Long id;
    /* 
    * 생략 
    */

@AllArgsConstructor, @RequiredArgsConstructor, @NoArgsConstructor, @Builder, . . 등등 생성자와 관련된 어노테이션을 별다른 고민 없이 사용했었던 것 같습니다.

또 builder와 생성자 방식을 비교하는 많은 글을 통해 builder가 대세라는 것도 알 수 있었습니다.

이밖에 정적 팩토리 메서드도 객체를 생성하는 유용한 방법입니다.

이번 글에서는 다양한 방법으로 객체를 만들어보려고 합니다!

1️⃣ 생성자

먼저, 생성자를 통해서 회원 객체를 만들어 보겠습니다.

회원은 이름, 이메일, 휴대폰번호, 나이를 필드로 가지고 있습니다. 아래 코드에는 모든 필드를 파라미터로 갖는 생성자가 있습니다.

public class Member {
    private String name;
    private String email;
    private String phoneNumber;
    private int age;


    public Member(String name, String email, String phoneNumber, int age) {
        this.name = name;
        this.email = email;
        this.phoneNumber = phoneNumber;
        this.age = age;
    }
}

new 키워드를 사용해 회원 객체를 만들어보겠습니다.

Member member = new Member("소은", "soeun1234@vmail.com", "010-1212-3434", 100);

회원 객체가 만들어졌습니다 !

Lombok @AllArgsConstructor

lombok의 @AllArgsConstructor 어노테이션을 사용해보도록 하겠습니다.

아래와 같이 lombok 의존성을 추가합니다.

• build.gradle

  compileOnly 'org.projectlombok:lombok:1.18.36'
  annotationProcessor 'org.projectlombok:lombok:1.18.36'

회원 클래스에서 직접 구현한 생성자를 제거하고, @AllArgsConstructor를 붙입니다.

@AllArgsConstructor
public class Member {
    private Long id;
    private String name;
    private String email;
    private String phoneNumber;
    private int age;
}

@AllArgsConstructor 어노테이션은 앞서 직접 구현했던 것과 같이 모든 필드를 파라미터로 갖는 생성자를 만듭니다.

🤔 생성자 방식의 단점

타입 안전성

Member wrongMember = new Member("소은", "010-1212-3434","soeun1234@vmail.com", 100);

실수로 파라미터의 순서를 바꿔 잘못된 회원 객체를 만들었다고 가정해보겠습니다. 이메일과 휴대폰 번호가 잘못 전달되었고, 이는 유효하지 않은 회원 객체입니다.

그러나, 두 가지 모두 String 타입이기 때문에 파라미터의 순서가 잘못되어도 컴파일러는 이를 인식하지 못합니다.

이렇게 잘못 생성된 회원 객체는 런타임에 예기치 못한 오류를 발생시킬 수 있습니다.

너무 많은 파라미터로 인해 가독성 저하

파라미터의 개수가 이보다 많아지게 된다면, 가독성이 떨어질 수 있습니다. 또한 개발자의 실수가 발생할 가능성이 높아집니다.

2️⃣ 빌더 패턴

위의 두 가지 문제점에 대한 해결책으로 빌더 패턴이 흔히 제시됩니다.

Builder Pattern in Java - Baeldung에 따르면 빌더 패턴의 장점은 다음과 같습니다.

• 유연성: 실제 객체의 표현으로부터 생성 프로세스를 분리함으로써, 다양한 구성으로 객체를 생성할 수 있습니다. 여러 개의 생성자 또는 Setter 성격의 메서드를 둘 필요가 없어집니다.

• 가독성: 복잡한 객체의 생성 과정을 한 눈에 이해할 수 있도록 돕습니다.

• 불변성: 불변 객체를 생성해 스레드 안전성을 보장하고, 의도치 않은 수정을 방지합니다.

빌더 패턴을 사용하면 각 필드에 대해 명시적인 메서드를 호출하여 값을 설정할 수 있기 때문에, 앞서 살펴봤던 파라미터의 순서가 뒤바뀌는 실수를 방지할 수 있습니다.

특히 타입이 동일한 필드가 많을 때 장점이 드러난다고 느꼈습니다.

Lombook @Builder

@Builder 어노테이션을 사용하면, Lombok이 빌더 클래스를 제공해줍니다.

@Builder
public class Member {
    private String name;
    private String email;
    private String phoneNumber;
    private int age;
}

회원 클래스 위에 @Builder 어노테이션을 추가했습니다. 이제 아래와 같이 객체를 생성할 수 있습니다.

Member jiyeon = Member.builder()
            .name("지연")
            .email("soeun1234@vmail.com")
            .phoneNumber("010-2323-3434")
            .age(200)
            .build();

이제 이메일과 휴대폰번호를 전달할 때 *파라미터의 순서를 고려하지 않아도 됩니다. *

참고) @NoArgsConstructor와 @Builder를 함께 사용 시

@Builder 어노테이션은 클래스, 생성자, 메서드 위에 붙일 수 있습니다.

lombok 공식문서에 따르면, 클래스 레벨에 @Builder 어노테이션을 붙일 경우 Lombok이 자동으로 모든 필드를 파라미터로 받는 package-private 생성자를 만들어줍니다.

즉, 아래 두가지는 동일하게 동작합니다.

• 클래스 레벨에 @Builder 추가

  @Builder
  public class Member {
    private String name;
    private String email;
    private String phoneNumber;
    private int age;
  }

• 이때 Lombok이 자동으로 추가해주는 생성자는 @AllArgsConstructor(access = AccessLevel.PACKAGE)를 붙이는 것과 동일

@AllArgsConstructor(access = AccessLevel.PACKAGE)
@Builder
public class Member {
    private String name;
    private String email;
    private String phoneNumber;
    private int age;
}

다만, @NoArgsConstructor와 @Builder를 함께 사용하는 경우에는 위와 같이 동작하지 않습니다.

@NoArgsConstructor
@Builder
public class Member {
    private String name;
    private String email;
    private String phoneNumber;
    private int age;
}

@NoArgsConstructor는 파라미터가 없는 기본 생성자를 제공합니다.

public Member() {        
}

Lombok의 @Builder를 클래스 레벨에 붙이게 되면, 전체 파라미터를 받는 생성자가 반드시 필요한데 이 기본 생성자와 충돌이 발생하는 것입니다.

그래서 이럴때는 아래와 같이 @AllArgsConstructor를 추가합니다.

@AllArgsConstructor
@NoArgsConstructor
@Builder
public class Member {
    private String name;
    private String email;
    private String phoneNumber;
    private int age;
}

위에 제시했던 lombok 어노테이션 3종 세트를 가진 클래스가 만들어졌습니다.

참고) @Builder를 클래스 레벨 vs 생성자 위에

위의 문제는 @Builder를 클래스 레벨이 아닌, 생성자 위에 붙여 해결할 수도 있습니다.

id 필드가 추가되었다고 가정해보겠습니다. id는 파라미터로 전달받는 것이 아닌 내부적으로 랜덤하게 생성되는 값입니다.

따라서 @AllArgsConstructor로 전체 파라미터를 받는 생성자를 추가하지 않고, 필요한 파라미터만 포함해 생성자를 만들고 그 위에 @Builder를 붙입니다.

@NoArgsConstructor
public class Member {
    private String id;
    private String name;
    private String email;
    private String phoneNumber;
    private int age;

    @Builder
    public Member(String name, String email, String phoneNumber, int age) {
        this.id = UUID.randomUUID().toString();
        this.name = name;
        this.email = email;
        this.phoneNumber = phoneNumber;
        this.age = age;
    }
}

클래스 레벨에서 @Builder를 사용할 때와는 다르게 필요한 파라미터만 노출된다는 장점이 있습니다.

🤔 @Builder의 단점

빌더 패턴의 장점으로 언급되는 "유연성"에는 아래와 같은 단점이 따릅니다.

원자적 객체 생성

@Builder를 사용하게 될 경우, 완전한 객체생성의 원자성을 보장하기 어렵습니다.

회원 객체는 아래와 같이 유연하게 생성될 수 있습니다.

/* 휴대전화번호와 나이만 갖는 회원 */
Member member1 = Member.builder()
    .phoneNumber("010-1212-3434")
    .age(200)
    .build();

/* 휴대전화번호만 갖는 회원 */
Member member2 = Member.builder()
    .phoneNumber("010-2323-4545")
    .build();  

/* 이름과 나이만 갖는 회원 */    
Member member3 = Member.builder()
    .name("회원3")
    .age(200)
    .build();    

이를 장점으로 보기도 하지만, 필수적으로 포함해야 하는 파라미터를 빠뜨리는 치명적인 실수를 하게 될 가능성이 있습니다.

회원의 이름, 이메일, 전화번호, 나이가 필수 값이라고 가정해보겠습니다. 위와 같이 *유효하지 않은 객체를 생성하더라도 컴파일 타임에 이를 체크하기 어렵습니다. *

반면, 생성자 방식의 경우 꼭 포함해야 하는 파라미터가 빠졌을 때 컴파일 타임에 알아차릴 수 있습니다.

참고) 커스텀 빌더 구현으로 해결!?

롬복이 만들어주는 빌더말고 직접 빌더를 만들어 사용하더라도 런타임 에러를 낼 수 있을뿐 컴파일 타임에 체크하기는 어렵다. 출처

Lombok이 제공하는 @Builder를 사용하지 않고 직접 빌더 패턴을 구현해보겠습니다.

public class Member {
    private String name;
    private String email;
    private String phoneNumber;
    private int age;

    public Member(String name, String email, String phoneNumber, int age) {
        this.name = name;
        this.email = email;
        this.phoneNumber = phoneNumber;
        this.age = age;
    }

    public static class Builder {
        private String name;
        private String email;
        private String phoneNumber;
        private int age;

        public Builder() {

        }

        public Builder(Member member) {
            this.name = member.name;
            this.email = member.email;
            this.phoneNumber = member.phoneNumber;
            this.age = member.age;
        }

        public Builder name(String name) {
            this.name = name;
            return this;
        }

        public Builder email(String email) {
            this.email = email;
            return this;
        }

        public Builder phoneNumber(String phoneNumber) {
            this.phoneNumber = phoneNumber;
            return this;
        }

        public Builder age(int age) {
            this.age = age;
            return this;
        }

        public Member build() {
        /* int 타입 age 필드의 경우 초기화되었는지 확인이 어렵*/
            if (name == null || email == null || phoneNumber == null) {
                throw new IllegalStateException("필수 파라미터가 빠졌습니다.");
            }
            return new Member(name, email, phoneNumber, age);
        }
    }
}

build() 메서드에서 null인 필드를 확인하고, 예외를 발생시키고 있습니다. 다만, 여전히 아래와 같이 컴파일 타임에 유효하지 않은 객체를 만드는 것을 막지 못합니다.

/* 컴파일 에러 발생 X */
Member jiyeon = new Member.Builder()
    .name("지연")
    .build();

실수로 유효하지 않은 객체를 생성했을 때, 이를 컴파일 타임이 아닌 런타임에 알아차릴 수 있습니다. 여전히 원자적 객체 생성에 대한 고민이 해결되지 않았습니다.

📚 타입 안전성을 보장하면서, 원자적인 객체 생성을 할 수 있는 방법은 없을까?

생성자 방식에서 문제가 가장 문제가 되었던 점은 타입 안전성이 보장되지 않는다는 것이었습니다.

타입 안전성을 보장하기 위해 builder pattern을 고려하게 되었지만, 완전한 객체생성의 원자성을 보장하기 어렵다는 단점을 마주하게 되었습니다.

타입을 다 다르게 만들면 되지 않을까?

@Builder 를 사용하는 것이 의미가 있는 경우는 동일한 타입의 필드가 많을 때였습니다.

만약 동일한 타입의 필드가 많지 않다면, 원자적인 객체 생성이 가능한 생성자 방식을 택하는 것이 낫다고 판단했습니다.

그렇다면, 필드의 타입을 모두 다르게 하려면 어떻게 하면 좋을까요?

String 타입을 Name, Email, PhoneNumber로 바꾸면 되지 않을까?

→ VO(Value Object)를 사용해서 타입 안전성을 보장하면 된다 ❗

그리고, 이렇게 타입 안전성이 보장된다면 생성자 방식을 택하는 것이 두 마리 토끼(타입 안전성, 원자적 객체 생성)를 모두 잡는 방법이라고 생각했습니다.

🧚 VO로 타입 안전성을 보장하기

Email VO 구현

Email VO를 만들어보겠습니다.

@Getter
@ToString
// 3. 값으로 동등성이 비교됨
@EqualsAndHashCode
public class Email {

    // 1. 불변성 (final 키워드, setter 성격의 메서드 없음)
    private final String emailValue;

    private static final String EMAIL_REGEX = "^[A-Za-z0-9+_.-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$";
    private static final Pattern EMAIL_PATTERN = Pattern.compile(EMAIL_REGEX);

    public Email(String emailValue) {
        // 2. 자가 유효성 검사 (유효한 값으로만 객체가 생성됨)
        validateEmail(emailValue);
        this.emailValue = emailValue;
    }

    private void validateEmail(String emailValue) {
        if (!EMAIL_PATTERN.matcher(emailValue).matches()) {
            throw new InvalidEmailException(emailValue);
        }
    }
}

VO는 세 가지 특징을 갖고 있습니다.

1. 불변 객체이다.
2. 자가 유효성 검사를 포함한다.
3. 값으로 비교된다.

이 세 가지 특징은 위의 코드에서 확인할 수 있습니다. VO와 관련된 더 자세한 내용은 추후 작성해보도록 하겠습니다.

생성자 + VO 적용 전/후

• Member

  @AllArgsConstructor
  public class Member {
    private Name name;
    private Email email;
    private PhoneNumber phoneNumber;
    private int age;
  }

Before

Member member = new Member("소은", "soeun1234@vmail.com", "010-1212-3434", 100);

이전에는 이름, 이메일, 휴대폰번호의 타입이 모두 String으로 같아 파라미터의 순서를 바꾸어 전달해도 컴파일 타임에 이를 체크할 수 없었습니다.

After

Member member = new Member(new Name("소은"), new Email("soeun1234@vmail.com"), new PhoneNumber("010-1212-3434"), 100);

이제 타입이 모두 다르기 때문에, 생성자 방식을 사용하더라도 타입에 대한 안전성이 보장됩니다. 또한 필드중 하나라도 누락시 컴파일 타임에 에러를 만나게 됩니다.

📕 Builder vs 생성자

builder의 장점은 필드들을 명확히 할당할 수 있고, 객체의 크기가 크더라도 필드들을 헷갈리지 않고 할당할 수 있다는 것입니다.

그러나, 유효하지 않은 객체를 생성할 수 있다는 위험성이 있습니다. 실제로 필드를 새로 추가하면서 객체를 생성하는 모든 코드를 꼼꼼히 수정하지 않아 치명적인 문제가 발생했던 적이 있습니다. builder로 객체를 생성할 때 새로 추가한 필드를 포함하지 않아도 컴파일 타임에 이를 확인할 수 없었기 때문입니다.

모든 선택에는 trade-off가 따르기 때문에 builder의 장점이 이를 상쇄한다고 생각할 수도 있습니다.

☝️ 다만, 앞서 이야기했듯이 빌더를 사용해야 하는 이유가 동일 타입이 많아서였다면, VO를 고려해볼 수 있습니다.

✌️ 또한 큰 객체의 생성은 객체의 분리를 고민해보아야 할 시점일 수 있습니다. 작은 객체를 만들게 되면, 빌더의 장점이 많이 사라지게 됩니다.

하지만 모든 타입을 VO로 구현할 수도 없고, 큰 객체를 만들어야만 하는 상황도 있습니다. 이럴 때는 builder나 아래에 소개될 정적 팩토리 메서드를 고민해볼 수 있습니다.

이쯤되면 어떡하자고..?ㅎㅎ

예전에는 builder가 무조건 정답이라고 알고 있었습니다. 다만 사용해보니 장단점이 있었고, 좋은 해결 방법도 찾을 수 있었습니다. 생성자 방식을 주된 객체 생성 방법으로 택했지만, 상황에 따라 builder를 사용하는 것이 더 적절한 경우도 있었습니다.

따라서 각 방식의 장단점을 알고, 요구사항에 맞게 적절한 판단을 하는 것이 중요하다고 생각합니다❗

3️⃣ 정적 팩토리 메서드

이펙티브 자바라는 책에 따르면, "생성자 대신 정적 팩토리 메서드를 고려하라"고 합니다.

정적 팩토리 메서드는 객체 생성을 캡슐화하는 방법입니다. 객체의 생성에 대한 책임을 static 메서드가 대리합니다.

아래 DatabaseConnection.java는 데이터베이스 연결을 위한 클래스입니다.

생성자를 사용했을 때

public class DatabaseConnection {

    private final String connectionString;
    private Integer poolSize = 8;

    public DatabaseConnection(String connectionString) {
        this.connectionString = connectionString;
    }

    public DatabaseConnection(String connectionString, Integer poolSize) {
        this.connectionString = connectionString;
        this.poolSize = poolSize;
    }

    public void connect() {
        System.out.println("---> connected successfully! \n connection-string: " + connectionString + "\n poolSize: " + poolSize);

    }

}

두 가지 생성자가 있습니다.

하나는, 데이터베이스 연결 문자열만 받고 기본 풀 크기를 사용해 데이터베이스 연결을 수립합니다. 다른 하나는, 연결 문자열과 풀 크기를 모두 지정 가능합니다.

이 두 가지 생성자를 제공함으로써, 기본 환경을 사용하거나 커스터마이징 하고 싶을 때를 구분해 유연하게 데이터베이스 연결을 수립할 수 있습니다.

정적 팩토리 메서드를 사용했을 때

public class DatabaseConnection {

    private final String connectionString;
    private Integer poolSize = 8;

    private static DatabaseConnection databaseConnection = null;

    private DatabaseConnection(String connectionString) {
        this.connectionString = connectionString;
    }

    private DatabaseConnection(String connectionString, Integer poolSize) {
        this.connectionString = connectionString;
        this.poolSize = poolSize;
    }

    public void connect() {
        System.out.println("---> connected successfully! \n connection-string: " + connectionString + "\n poolSize: " + poolSize);
    }

    /**
     * This method provide singleton instance
     * @param connectionString
     * @return
     */
    public static DatabaseConnection getInstance(String connectionString) {
        if (Objects.isNull(databaseConnection)) {
            databaseConnection = new DatabaseConnection(connectionString);
        }
        return databaseConnection;
    }

    public static DatabaseConnection getInstanceWithPoolSize(String connectionString, Integer poolSize) {
        return new DatabaseConnection(connectionString, poolSize);
    }

}

정적 팩토리 메서드의 특징과 함께 위의 코드를 살펴보도록 하겠습니다.

1. 이름을 가진다.

생성자와 달리, 정적 팩토리 메서드는 getInstance(), getInstanceWithPoolSize()와 같이 이름을 가질 수 있습니다.

PoolSize를 직접 지정하고 싶을 때 getInstanceWithPoolSize()를 선택해야 한다는 사실을 알 수 있습니다.

*2. 하나의 인스턴스만 생성하고 재사용할 수 있다. *

즉, 정적 팩토리 메서드를 통해 싱글톤 패턴을 구현할 수 있습니다.

getInstance() 메서드를 보면, DatabaseConnection이 null일 때만 새로운 객체를 생성하고, 그렇지 않을 때는 이미 만들어진 객체를 재사용합니다.

또한 생성자의 접근 제한자를 private으로 설정했기 때문에, 정적 팩토리 메서드를 통해서만 객체를 생성할 수 있습니다. 이를 통해 불필요한 중복 객체를 방지하고, 싱글톤으로 사용할 수 있습니다.

3. 하위 타입을 리턴할 수 있다.

DatabaseConnection을 상속받은 MySqlConnection, PostgresConnection, OracleConnection이 있다고 가정해보겠습니다.

다음과 같이 하위 타입의 객체를 리턴할 수 있습니다.

public static DatabaseConnection getInstance(String connectionString) {
        if (connectionString.startsWith("mysql")) {
            return new MySqlConnection(connectionString);
        } else if (connectionString.startsWith("postgresql")) {
            return new PostgresConnection(connectionString);
        } else if (connectionString.startsWith("oracle")) {
            return new OracleConnection(connectionString);
        }
        throw new IllegalArgumentException("Unsupported database type");
    }

4. 예외를 던질 수 있다.

객체를 생성하는 과정에서 예외가 발생할 수 있다면, 정적 팩토리 메서드를 고려해볼 수 있습니다.

위의 예시에서처럼 connectionString이 잘못되었을 때 예외를 던지는 등의 validation을 추가할 수 있습니다.

⛳️ 마치며

객체를 생성하는 세 가지 방법을 알아봤습니다.

이제 습관처럼 어노테이션을 붙이지 않고, 다양한 객체 생성 방법을 고민해 적절한 선택을 할 수 있게 되었습니다.

긴 글 읽어주셔서 감사합니다. 새해복 많이 받으세요!

📖 참고자료

@AllArgsConstructor - lombok Builder - baldung Builder pattern vs Constructor - stackoverflow @Builder on Constructor - lombok how many constructor arguments is too many - stackoverflow builder pattern에 대한 고찰 adding custom validation in lombok Step Builder Effective Java Consider Static Factory Methods instead of Constructors What are static factory methods? - stackoverflow What are the disadvantages of Java constructors?

지난번 Event Publisher를 사용하여 비동기적으로 조회수 이벤트를 처리한 글을 작성한 이후, 아래와 같은 질문을 받았습니다.

"10만 명의 사용자가 동호회를 접속했을 때, 조회수가 10만 만큼 올라가나요?"

조회수 증가 로직이 실패하는 경우가 언제일까 고민해보다가 동시성 이슈가 가장 먼저 떠올랐습니다.

그래서 이번 글에서는 아래의 질문에 대해 고민하고 해결해나가는 과정을 담아보려고 합니다! 😄

다수의 사용자가 하나의 동호회를 동시에 조회했을 때, 조회수가 정상적으로 올라갈까?

🖍️ java.util.concurrent

동시성 문제를 어떻게 경험하고, 테스트 할 수 있을까요?

자바의 java.util.concurrent 패키지를 살펴보도록 하겠습니다. 해당 패키지에는 ExecutorService 및 CountDownLatch와 같은 여러 동기화 장치가 포함되어 있습니다.

ExecutorService란?

스레드풀을 제공하며, 각각의 스레드에 작업을 할당할 수 있습니다.

Future<?> submit(Runnable task);

주어진 작업(task)을 실행하고, 모든 작업이 완료되었을 때 작업 상태와 결과를 보유한 Future 리스트를 반환합니다.

executorService.shutdown();

스레드 풀을 종료하여 리소스를 해제합니다.

CountDownLatch란?

CountDownLatch를 사용해 다른 스레드들이 주어진 일을 완료할 때까지 특정 스레드를 대기 상태에 들게 할 수 있습니다. 이는 각각의 스레드가 작업을 종료하면 1씩 감소하는 counter field입니다.

CountDownLatch latch = new CountDownLatch(numberOfThreads);

생성 시 초기 카운트 값(정수)을 설정합니다. 이때 numberOfThreads는 작업할 스레드의 개수와 동일한 값으로 설정합니다.

latch.countDown();

latch의 카운트 값을 감소시킵니다. 만약 현재 카운트 값이 0보다 크다면, 1 줄어듭니다.

latch.getCount();

현재 카운트 값을 반환합니다(long 타입). 디버깅 또는 테스트 용도로 활용할 수 있습니다.

latch.await();

카운트 값이 0이 될 때까지 스레드를 대기 상태로 유지합니다. 모든 스레드가 작업을 완료하여 카운트가 0이 될 때까지 메인 스레드가 대기합니다. 카운트 값이 0이 되면, 대기 중이던 모든 스레드가 깨어나고 대기 상태에서 해제됩니다.

✍️ 테스트 코드 작성

자, 이제 테스트 코드를 작성해보도록 합시다!

• 테스트 시나리오 100명의 사용자가 동시에 UUID가 club_token_1인 동호회를 조회하는 상황을 가정해보겠습니다. 해당 동호회에 대한 조회수는 100만큼 올라야 합니다.

@SpringBootTest를 사용하여 통합 테스트를 진행하였습니다.

@SpringBootTest(classes = BadmintonApplication.class)
@ActiveProfiles("test")
@Transactional
public class ClubReadConcurrencyTest {

    @Autowired
    private ClubStatisticsRepository clubStatisticsRepository;

    @Autowired
    private ClubStatisticsService clubStatisticsService;

    @Test
    void 동호회_조회_동시성_테스트() throws InterruptedException {
        ///given
        ExecutorService executorService = Executors.newFixedThreadPool(20);
        CountDownLatch latch = new CountDownLatch(100);

        //when
        for (int i = 0; i < 100; i++) {
            executorService.submit(() -> {
                try {
                    clubStatisticsService.increaseVisitedClubCount("club_token_1");
                } catch (Exception e) {
                    e.printStackTrace();
                } finally {
                    latch.countDown();
                }
            });
        }
        latch.await();
        executorService.shutdown();

        //then
        int visitedCount = clubStatisticsRepository.findByClubClubToken("club_token_1").getVisitedCount();
        assertThat(visitedCount).isEqualTo(100);
    }
}

😵‍💫 CountDownLatch, latch.await() 대체 뭐야?

이 개념이 저에게는 다소 어려웠기 때문에, 설명을 하고 넘어가려고 합니다. 이미 알고 계시다면 내용이 조금 길기 때문에 넘어가주세요 ... 🙏

테스트 코드를 실행하는 Test Worker 스레드, 비동기적으로 실행되는 20개의 스레드

System.out.println("스레드 이름: " + Thread.currentThread().getName());

중간 중간에 스레드의 이름을 찍어 보면 아래와 같이 출력됩니다.

Test Worker는 테스트 코드 실행을 위해 만들어진 스레드입니다. 이 스레드는 JUnit과 같은 테스트 프레임워크가 테스트를 실행할 때 기본적으로 사용하는 스레드 이름입니다.

그럼 그 아래 pool-3-thread로 시작하는 스레드는 무엇일까요?

Test Worker 스레드는 아래의 코드를 실행합니다.

ExecutorService executorService = Executors.newFixedThreadPool(20);

ExecutorService는 크기가 20인 스레드 풀을 생성합니다. 즉, 최대 20개의 스레드가 동시에 작업을 처리할 수 있습니다.

이제 submit() 메서드를 통해 스레드풀에 제출된 100개의 작업은 비동기적으로 처리됩니다.

latch.await()가 없다면?

Test Worker 스레드는 100개의 비동기 작업이 완료될 때까지 기다려주지 않습니다.

스레드풀에 제출된 100개의 작업이 아직 실행되고 있더라도, Test Worker 스레드는 아래로 쭉쭉 내려갑니다.

만약 latch.await()가 없었다면 Test Worker 스레드는 그 아래 executorService.shutdown()을 실행할 것입니다. 그럼 스레드풀이 종료되고 리소스가 해제되기 때문에 위에서 할당해준 작업들 또한 중단됩니다.

위의 그림을 통해 Thread1~20이 아직 작업을 처리 중인데, Test Worker 스레드는 실행을 마치고 종료된 모습을 확인할 수 있습니다.

즉, latch.await()가 없다면 동시성을 제어했더라도 테스트가 실패할 것입니다. Test Worker 스레드는 20개의 Sub 스레드가 수행하는 100개의 작업이 끝나기도 전에 종료되기 때문이죠.

이래서 CountDownLatch를 사용하는구나!

저희가 원하는 것은 Thread1~20이 100개의 작업을 모두 끝마치고 난 뒤의 결과값을 확인하는 것입니다.

따라서 Test Worker 스레드는 잠시 실행을 멈추고 20개의 Sub 스레드가 100개의 작업을 모두 마칠 때까지 기다려줘야 합니다. 이때 CountDownLatch라는 걸쇠를 사용할 수 있습니다.

CountDownLatch latch = new CountDownLatch(100);

카운트값을 100으로 설정해 CountDownLatch를 만들었습니다.

finally {
    latch.countDown();
}

하나의 작업이 완료될 때마다 finally 구문 안에 있는 latch.countDown();가 실행되어 카운트값이 1씩 감소합니다.

100개의 작업이 모두 완료되면, 카운트값이 0이 됩니다.

latch.await();

Test Worker 스레드가 위의 코드를 만나면, CountDownLatch의 카운트값을 확인합니다. 만약, 0보다 크다면 대기 상태에 머무릅니다. 0이라면, 대기 상태에서 해제됩니다.

위에서 확인했듯이, 스레드풀에 제출된 100개의 작업이 모두 완료되면 카운트값이 0이 되며, 이때 Test Worker 스레드가 대기 상태에서 해제됩니다!

즉, CountDownLatch는 Test Worker 스레드가 100개의 작업이 모두 완료될 때까지 대기 상태에 머무르도록 하는 역할을 합니다.

위의 그림을 통해 더이상 Test Worker 스레드가 비동기 작업이 끝나기 전에 종료되지 않고, 스레드풀에 제출된 작업이 모두 완료될 때까지 기다려주는 것을 확인할 수 있습니다.

Thread.sleep() 쓰면 되지 않아?

Thread.sleep()은 지정된 시간 동안 현재 스레드를 중단합니다. 다만, 의도한 이벤트 발생 시점에 맞춰 작업을 재개할 수 없습니다. 작업이 끝나는 정확한 시간을 예측하기 어렵기 때문에 테스트 수행 시 불필요한 대기 시간이 발생할 확률이 높습니다.

이와 반면, CountDownLatch 사용 시 정확한 이벤트 기반 동작이 가능합니다!

🤔 왜 이런 일이?

테스트한 결과, 평균 10% 정도의 성공률을 보였습니다. 즉 100명의 사용자가 동시에 조회했을 때, 조회수가 100으로 오르지 않고, 10에 웃도는 모습을 확인할 수 있었습니다.

예상했던 것보다도 너무 낮은 성공률을 보여서, 조회수를 올리는 로직을 다시 살펴보았습니다.

• ClubStatisticsService

@Transactional
public void increaseVisitedClubCount(String clubToken) {
        ClubStatistics clubStatistics = clubStatisticsReader.readClubStatistics(clubToken);
        clubStatistics.increaseVisitedCount();
        clubStatisticsStore.store(clubStatistics);
}

• ClubStatisticsEntity

public void increaseVisitedCount() {
    this.visitedCount++;
}

위와 같이 Entity 내부에 필드를 1씩 증가시키는 코드가 있습니다.

JPA Dirty Checking

JPA는 dirty checking으로 엔티티의 상태 변경을 감지하고, 트랜잭션이 커밋될 때 UPDATE 쿼리를 날립니다. 이때 Race Condition이 발생할 수 있습니다.

Race Condition

그림과 같이 Thread 1이 read()를 수행합니다. 이때 visitedCount 값은 0입니다. Thread 1이 visitedCount를 1 증가하여 DB에 반영하기 이전에, Thread 2가 read()를 수행합니다. 아직 visitedCount는 0입니다. 두 개의 스레드가 조회수를 올리고 싶었으나, 최종적으로 DB에 반영되는 값은 2가 아니라 1이 됩니다.

🧚 직접 Update Query 작성하기

JPA를 통한 업데이트를 할 때 락을 통해 동시성을 제어하지 않게 되면, 위와 같은 문제가 발생할 수 있습니다.

Update 쿼리를 직접 날려 간단하게 해결해보도록 하겠습니다. querydsl을 사용하여 DB의 row에 직접 +1을 수행합니다.

@Override
@Transactional
public void increaseClubVisitCount(String clubToken) {
        queryFactory.update(clubStatistics)
            .set(clubStatistics.visitedCount, clubStatistics.visitedCount.add(1))
            .where(clubStatistics.club.clubToken.eq(clubToken))
            .execute();
}

영속성 컨텍스트에서 객체를 읽어와 값을 1 증가시키고 JPA의 Dirty Checking을 통해 업데이트하는 이전 방식과 다르게, DB의 해당 행(row)에 직접 +1 연산을 수행하기 때문에 자동으로 락이 걸리며 동시성 문제가 해소됩니다.

🔓 락을 걸어보자!

위의 방식에는 어떤 문제점이 있을까요? DB Connection Pool 소진, Deadlock, DB 부하 증가 등의 문제가 발생할 수 있습니다.

다만, 기존 프로젝트에서는 위와 같이 UPDATE 쿼리를 직접 작성하는 것으로 동시성 문제를 해결하기로 했습니다. 데이터 정합성이 거의 100% 지켜졌고, 하나의 동호회를 조회하는데 높은 트래픽이 몰릴 일이 적어 큰 문제점을 느끼지 못했기 때문입니다.

그래도 . . . 아쉬우니 여러 가지 종류의 락을 걸어보면서 동시성 문제를 조금 더 깊게 공부해보기로 했습니다.

🚨 락을 걸 때 주의할 점 - @Transactional

@Override
@Transactional
public void increaseVisitedClubCount(String clubToken) {
        synchronized (this) {
            increaseClubVisitCount(clubToken);
        }
    }

private void increaseClubVisitCount(String clubToken) {
        ClubStatistics clubStatistics = clubStatisticsReader.readClubStatistics(clubToken);
        clubStatistics.increaseVisitedCount();
        clubStatisticsStore.store(clubStatistics);
}

synchronized 키워드를 붙여봤습니다. 위 코드에서는 어떠한 문제가 있을까요?

트랜잭션 내부에서 락을 거는 행위는 주의해야 합니다. 아래와 같은 문제가 발생할 수 있습니다.

1번 요청이 작업을 다 수행한 다음 lock을 반납했습니다. 그러나 아직 트랜잭션이 커밋되기 이전이라고 가정해보겠습니다.

그 사이에 2번 요청은 lock을 획득하고, visitCount를 읽습니다. 이때 읽은 visitCount값은 1이 아닌 0입니다.

1번 요청이 +1 증가시킨 조회수가 아직 DB에 반영되기 이전이기 때문입니다. 그런데 두 번째 요청이 1번 tx가 커밋되기 이전에 lock을 획득해버렸고, 이때 읽어들인 조회수는 아직 0입니다.

이는 트랜잭션 내부에 락을 걸었기 때문인데요, 커밋하지 않은 데이터를 다른 곳에서 조회하게 되면 데이터 정합성에 큰 문제가 발생합니다.

어떻게 해결할 수 있을까요?

락 내부에 @Transactional을 걸면 위의 문제가 해결됩니다!

@Override
public void increaseVisitedClubCount(String clubToken) {
        // 1. 락을 건다.
        synchronized (this) {
            increaseClubVisitCount(clubToken);
        }
    }

// 2. 트랜잭션이 시작된다.
@Transactional
public void increaseClubVisitCount(String clubToken) {
        ClubStatistics clubStatistics = clubStatisticsReader.readClubStatistics(clubToken);
        clubStatistics.increaseVisitedCount();
        clubStatisticsStore.store(clubStatistics);
}

앞선 코드와 다르게, 락을 획득하고 나서 트랜잭션이 시작됩니다. 작업을 수행한 다음, 커밋까지 완료되어야 락을 반납합니다.

즉, 커밋되지 않은 공유 자원의 경우 아직 락이 해제되지 않았기 때문에, *다른 스레드가 더이상 접근하지 못합니다. *

이를 통해 항상 커밋된 내용을 읽는 것을 보장할 수 있습니다.

🔎 요약 락과 @Transactional을 함께 사용할 때는 데이터 정합성을 위해 락 내부에서 트랜잭션이 시작되도록 합니다.

😕 Synchronized의 문제점

다만, Synchronized 키워드는 한 프로세스 내에서만 스레드의 접근 제한을 보장합니다. 따라서 여러 프로세스에서 데이터 정합성을 보장해주지 않습니다. 또한 자바 애플리케이션에 종속되기 때문에, 여러 서버로 확장되었을 때 사용하기 어렵습니다.

🔏 비관적 락

비관적락은 mysql에서 제공하는 레코드락입니다.

# user1 요청
start transaction;
select * from clubStatistics where clubToken = 1 for update; # visitCount = 0
/*
user 1 조회수 증가
- update visitCount # visitCount = 1
- insert club_statistics
*/
commit; # 커밋이 되는 순간, 락이 해제된다.ㅡㅡㅡㅡ

ClubStatistics 테이블에서 조회수를 조회할 때 락을 걸면, 커밋되기 전까지 읽거나 쓸 수 없습니다. 쿼리의 끝에 for update를 붙여 해당하는 레코드에 락을 걸 수 있습니다. 레코드락은 중첩해서 걸 수 없으며, 락이 해제될 때까지 기다려야 합니다. 커밋이 되면, 락이 해제됩니다.

# user2 요청
start transaction;
select * from clubStatistics where clubtoken = 1 for update; # 락이 해제되기를 기다림, 락을 건다. 
/*
user 2 조회수 증가
- update visitCount # visitCount = 2
- insert club_statistics
*/
commit;

user2는 락이 해제될 때까지 기다렸다가, user1의 요청이 커밋되는 순간 락을 획득합니다. 이때 읽어들인 visitCount는 1입니다.

아래와 같이 어노테이션을 통해 비관적락을 구현할 수 있습니다. 조회 시 락을 걸어, Transaction 범위 내에서 해당 레코드에 대한 접근 제한이 보장됩니다.

@Lock(LockModeType.PESSIMISTIC_WRITE)
ClubStatistics findByClubClubToken(String clubToken);

다만, 비관적 락의 경우 mysql에서 제공하는 락으로 DB에 병목이 생기면, 처리량에 문제가 생길 수 있습니다. 즉, DB에 부하가 생기며 성능 이슈가 발생할 가능성이 있습니다.

🧣 레디스락

레디스락은 분산락입니다. 즉, 분산 환경에서도 안정적으로 락을 걸고 해제할 수 있습니다. Java의 Redis client인 Redisson을 사용했습니다. Redisson은 Lock, Semaphore, CountDownLatch 등의 잠금 및 동기화 장치를 제공합니다.

기본적으로 Redis는 인메모리 DB이기에 더 빠르게 락을 획득 및 해제할 수 있습니다. 분산락에 대한 부하를 Redis 서버가 감당하기 때문에, 앞서 살펴봤던 DB 성능 문제를 방지할 수 있습니다.

build.gradle에 아래와 같이 의존성을 추가합니다.

• build.gradle

implementation 'org.redisson:redisson-spring-boot-starter:3.27.0'

• Executor

package org.badminton.infrastructure.statistics;

@Component
@Slf4j
@RequiredArgsConstructor
public class DistributeLockProcessorExecutorImpl implements DistributedLockProcessor {

    private final RedissonClient redissonClient;

    @Override
    public void execute(String lockName, long waitMilliSecond, long releaseMilliSecond, Runnable runnable) {
        RLock lock = redissonClient.getLock(lockName);
        try {
            boolean isLocked = lock.tryLock(waitMilliSecond, releaseMilliSecond, TimeUnit.MILLISECONDS);
            if (!isLocked) {
                throw new IllegalArgumentException("[" + lockName + "] lock 획득 실패");
            }
            runnable.run();
        } catch (InterruptedException e) {
            log.error(e.getMessage(), e);
            throw new RuntimeException(e);
        } finally {
            if (lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
        }
    }
}

• ClubStatisticsService

@Override
public void increaseVisitedClubCount(String clubToken) {
    String lockName = "CLUB_VISIT_LOCK_" + clubToken;
    distributedLockProcessor.execute(lockName, 10000, 10000,
            () -> increaseClubVisitCountWithNamedLock(clubToken)
    );
}

@Transactional
public void increaseClubVisitCountWithNamedLock(String clubToken) {
    ClubStatistics clubStatistics = clubStatisticsReader.readClubStatistics(clubToken);
    clubStatistics.increaseVisitedCount();
    clubStatisticsStore.store(clubStatistics);
}

🕰️ 세 가지 락 비교

100개 데이터를 테스트한 결과, 아래와 같은 결과를 확인했습니다.

1. 동시성 적용 X
   • 0.322s (322.807ms)
2. synchronized
   • 1.144s (1143.671ms)
3. 레디스락
   • 1.21s (1206.73ms)
4. mysql 락(비관적 락)
   • 0.634s (634.514ms)

당연히 동시성을 고려하지 않았을 때, 락을 걸지 않아 가장 빨랐습니다. 다만, 세 가지 락이 보여준 시간이 예상 밖이었는데, mysql 락이 가장 빨랐고 레디스락이 가장 느렸습니다. 이는 추가적으로 알아보려고 합니다.

⛳️ 조회수와 동시성

동시성에서 중요한 건, "공유 자원인가? 공유 자원이 아닌가?"를 판단하는 것입니다. 만약 공유 자원이라면, 얼마나 공유되고 있는지를 고민해보아야 합니다. 조회수의 경우, 동시성의 경합 조건이 실제로는 훨씬 덜할 것이라고 예상됩니다.

또한 조회수는 엄격하게 가져갈 것이 아니기 때문에, "조회수를 올리는데 별도의 락까지 써야 할까?"라고 생각했습니다. 어쩌다가 한 번씩 실패하는 경우에는 감내할 수 있기 때문입니다.

따라서, 최종적으로 처음에 소개했던 UPDATE 쿼리를 직접 날리는 방식을 택하게 되었습니다.

🌳 마치며

프로젝트에서 조회수 기능을 구현하며 동시성 문제를 고민해본 내용을 담아봤습니다. 아주 간단할거라 생각했는데, 고민해볼 만한 부분이 많아 재미있게 구현할 수 있었습니다!

긴 글 읽어주셔서 감사합니다 😄

📘 참고자료

CountDownLatch - baeldung ExecutorService - baeldung 비관적락 - baeldung Redisson - baeldung Distributed Locks with Redis Transactional with synchronized doesn't work - stackoverflow

프로젝트를 진행하며 조회수 업데이트를 비동기적으로 처리하게 되며 Event Publisher를 공부하게 되었습니다.

해당 글은 Event Publisher를 사용하게 된 이유와 기본적인 사용법을 코드 예시와 함께 설명하고 있습니다.

또한 @TransactionalEventListener와 @EventListener 동작의 차이점을 테스트하던 중 깨달음을 얻은 내용을 담고 있습니다.

바로 코드를 통해 확인해보겠습니다!

@Service
@RequiredArgsConstructor
public class ClubFacade {
    private final ClubService clubService;
    private final ClubStatisticsService clubStatisticsService;

    @Transactional
    public ClubInfo readClub(String clubToken) {
        var clubInfo = clubService.readClub(clubToken);
        clubStatisticsService.increaseClubVisitCount(clubToken);
        return clubInfo;
    }
    /* 
  * 생략
  */
}

동호회를 조회하는 서비스 코드 일부입니다. 동호회를 조회한 다음, 동호회 통계 서비스의 increaseClubVisitCount 메서드를 실행해 조회수를 1 올리고 있습니다.

📍 +) 조회수의 중요성

참고로, 저희 서비스의 경우 조회수를 사용자에게 직접적으로 보여주지 않고 있습니다. 인기 있는 동호회를 정렬할 때 내부적으로 사용하는 지표인데요.

이러한 이유로, 조회수의 정합성이 아주 중요하다고 판단하지 않았습니다. 즉, 10만 명의 사용자가 동호회를 조회했지만, 조회수가 10만보다 조금 적더라도, 이는 서비스에 큰 영향을 미치지 않습니다.

따라서 동호회 조회 시 조회수가 일부 올라가는데 실패하더라도, 사용자가 동호회를 정상적으로 조회할 수 있는 것이 더 중요한 요구사항으로 작용했습니다.

개발 중인 서비스에서 조회수가 어떤 역할을 하고 있는지, 또한 실시간성과 데이터 정합성이 어느 정도로 보장되어야 하는지를 고민해보면 좋을 것 같습니다!

🤔 문제점

1. 강결합

지금은 동호회와 관련된 서비스가 동호회 통계 서비스와 강하게 결합이 되어있습니다. 동호회를 조회할 때 ClubStatisticsService에 꼭 의존해야 할까요?

2. 조회수 쓰기 작업 실패 시 동호회 조회도 실패

조회수를 올리는 기능이 동기적으로 처리되고 있으며, 동호회 조회와 조회수 쓰기 작업이 하나의 트랜잭션으로 묶여 있습니다. 아래의 상황을 생각해보겠습니다.

조회수를 올리는 로직에서 예외가 발생한다면?

동호회 조회에는 성공했지만, 조회수를 올리는데 실패했다고 가정해보겠습니다. 이를 실패로 간주해야 할까요? 현재 동호회 조회와 조회수 쓰기 작업이 @Transactional로 묶여 있기 때문에 하나가 실패하면 나머지 작업도 실패한 것으로 간주됩니다.
조회수를 올리는데 실패했다고 동호회 조회 API가 에러를 응답해야 할까요?

앞서 이야기했듯이, 저희 서비스의 경우 조회수가 100% 정확하지 않더라도 사용자 경험에 큰 영향을 미치지 않습니다. 따라서 조회수가 실제와는 조금 다를 수도 있다는 점은 감수할 수 있다고 판단했습니다.

📮 Application Event Publisher

스프링에서 제공하는 Event 기능을 사용해 조회수를 올리는 작업을 비동기적으로 처리해 위의 두 가지 문제점을 해결할 수 있습니다.

1. Event

이벤트와 관련된 데이터를 저장하는 Placeholder, 또는 DTO 객체를 아래와 같이 작성합니다. 동호회 조회 이벤트의 경우, 동호회 UUID를 필요로 합니다.

** 참고로, Event는 아래와 같이 일반 객체로 만들어도 무방합니다. Spring Framework 4.2 이전에는 이벤트 객체가 반드시 ApplicationEvent를 상속해야 했습니다. 4.2 이후부터 publishEvent(Object event) 메서드가 오버로드되어 일반 객체를 이벤트 객체로 사용할 수 있습니다.

@Getter
@RequiredArgsConstructor
public class ReadClubEvent {

    private final String clubToken;
}

2. Listener

리스너는 @EventListener 어노테이션을 붙이거나 ApplicationListener 인터페이스를 정의해 구현할 수 있습니다. 아래 예시에서는 간단하게 어노테이션을 붙여 Event Listener를 구현했습니다.

파라미터에 정의한 타입의 이벤트가 발생하면 @EventListener 어노테이션을 붙인 퍼블릭 메서드가 동작합니다.

@Component
@RequiredArgsConstructor
public class ReadClubEventHandler {

    private final ClubStatisticsService clubStatisticsService;

    @EventListener
    public void readClubEventListener(ReadClubEvent event) {
        clubStatisticsService.increaseVisitedClubCount(event.getClubToken());
    }
}

이때 한 가지 기억해야 할 점은, 스프링은 default일 때 이벤트를 동기적(Synchronous)으로 처리합니다.

3. Publisher

이벤트와 이벤트 리스너가 준비되었으니, 이제 이벤트를 발행할 차례입니다.

3.1. ApplicationEventPublisher

ApplicationEventPublisher라는 함수형 인터페이스를 사용해 이벤트를 발행할 수 있는데요, 아래와 같이 publishEvent라는 추상 메서드를 포함하고 있습니다.

@FunctionalInterface
public interface ApplicationEventPublisher {
    default void publishEvent(ApplicationEvent event) {
        this.publishEvent((Object)event);
    }

    void publishEvent(Object event);
}

publishEvent 메서드를 통해 이벤트가 발행되면, Spring은 Application Context에 등록된 리스너 중 해당 이벤트와 매칭되는 리스너를 찾아 호출합니다.

해당 함수형 인터페이스는 ApplicationContext 를 구현한 AbstractApplicationContext 클래스에 구현되어 있습니다.

public interface ApplicationContext extends ApplicationEventPublisher /*, ... 생략*/ {

따라서 별도로 구현하지 않고, 간단하게 의존성을 주입받아 publishEvent메서드를 사용할 수 있습니다.

3.2. 코드에 적용

ApplicationEventPublisher에 대한 의존성을 추가하고, publishEvent 메서드를 호출해 이벤트를 발행합니다.

@Service
@RequiredArgsConstructor
public class ClubFacade {
    private final ClubService clubService;
    private final ApplicationEventPublisher eventPublisher;

    @Transactional
    public ClubInfo readClub(String clubToken) {
        var clubInfo = clubService.readClub(clubToken);
        eventPublisher.publishEvent(new ReadClubEvent(clubToken));
        return clubInfo;
    }
    /* 
  * 생략
  */
}

👛 Before & After

Before

@Service
@RequiredArgsConstructor
public class ClubFacade {
    private final ClubService clubService;
    private final ClubStatisticsService clubStatisticsService;

    @Transactional
    public ClubInfo readClub(String clubToken) {
        var clubInfo = clubService.readClub(clubToken);
        clubStatisticsService.increaseClubVisitCount(clubToken);
        return clubInfo;
    }
    /* 
  * 생략
  */
}

After

@Service
@RequiredArgsConstructor
public class ClubFacade {
    private final ClubService clubService;
    private final ApplicationEventPublisher eventPublisher;

    @Transactional
    public ClubInfo readClub(String clubToken) {
        var clubInfo = clubService.readClub(clubToken);
        eventPublisher.publishEvent(new ReadClubEvent(clubToken));
        return clubInfo;
    }
    /* 
  * 생략
  */
}

먼저, 더이상 ClubStatisticsService에 의존하고 있지 않습니다. 동호회 서비스와 동호회 통계 서비스 간의 결합도가 낮아졌습니다.

또한, 동호회 읽기 작업은 동호회 조회수를 올리는 쓰기 작업과 무관하게 동작합니다. 동호회 조회수를 올릴 때 예외가 발생하더라도, 동호회 읽기 API는 성공적으로 요청을 처리합니다.

☔️ 테스트.. 어라라?!

두 가지 테스트를 진행해보려고 합니다.

예상한 시나리오 1 이벤트 핸들러에서 예외가 발생하더라도, 동호회 조회 API는 정상 응답할 것이다.

동호회 조회수를 올릴 때 문제가 발생하더라도, 동호회 조회는 성공해야 한다는 요구사항이 있습니다. 따라서 Event Listener 내부에 예외를 발생하는 코드를 작성했습니다. 이벤트를 처리하다가 예외가 발생해도, 동호회 조회를 하는 API는 성공해야 합니다.

@Component
@RequiredArgsConstructor
public class ReadClubEventHandler {

    private final ClubStatisticsService clubStatisticsService;

    @EventListener
    public void readClubEventListener(ReadClubEvent event) {
        clubStatisticsService.increaseVisitedClubCount(event.getClubToken());
        // 예외를 발생시킨다.
        throw new BadmintonException(ErrorCode.CLUB_NOT_EXIST);
    }
}

그러나, 예상했던 것과는 다르게 에러를 응답하고 있습니다.

예상한 시나리오 2 @EventListener를 사용했기 때문에 트랜잭션 실패에도 불구하고 이벤트가 실행되어 조회수가 늘어나 있을 것이다.

@TransactionalEventListener를 붙인 이벤트 리스너는 기본적으로 트랜잭션 커밋 후 실행됩니다.

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)  // Default 옵션

트랜잭션 커밋 이후 리스너가 실행되며, 만약 트랜잭션이 실패하면 리스너는 실행되지 않습니다. 즉, @Transactional 내 모든 작업이 성공해야 이벤트 리스너가 실행됩니다.

이 둘의 차이점을 느껴보고자 먼저 @EventListener를 사용해 테스트를 진행했습니다. 아래와 같이 이벤트를 발행한 다음 예외를 발생하는 코드를 추가했습니다.

@Transactional
    public ClubCreateInfo createClub(ClubCreateCommand createCommand, String memberToken) {
        ClubCreateInfo clubCreateInfo = clubService.createClub(createCommand);
        clubMemberService.clubMemberOwner(memberToken, clubCreateInfo);
        eventPublisher.publishEvent(new CreateClubEvent(clubCreateInfo));
        // 예외를 발생시킨다. 
        throw new BadmintonException(ErrorCode.CLUB_NOT_EXIST);
    }

예상했던 것과 같이 트랜잭션이 종료되기 전이지만, 이벤트 리스너 내부의 코드로 진입하는 것을 확인했습니다.

다만, 최종적으로 롤백되어 조회수가 늘어나지 않았습니다.

(기존 조회수 110, API 호출 이후 조회수 여전히 110)

‼️ @Async를 안 붙이면 Spring은 이벤트를 동기적으로 처리

EventHandler에 @Async 어노테이션을 붙이지 않아 조회수를 증가하는 로직이 동기적으로 처리되고 있었습니다.

스프링은 default 옵션에서 이벤트를 동기적으로 처리하며, 이때 이벤트 리스너는 동일한 스레드에서 이벤트를 처리합니다. 즉, 동호회를 조회하고, 조회수를 올리는 두 가지 로직이 동일 스레드에서 실행됩니다.

따라서 동일 스레드 내에 예외가 발생했을 때 (1) 이를 실패로 간주해 에러를 응답하고, (2) 조회수 쓰기 작업은 롤백된 것입니다.

아래는SimpleApplicationEventMulticaster 클래스의 코드 일부입니다. 이벤트가 발생하면 이를 적합한 리스너에게 전달하며, 비동기 처리를 위해 TaskExecutor를 사용합니다.

public void multicastEvent(ApplicationEvent event, @Nullable ResolvableType eventType) {
        ResolvableType type = eventType != null ? eventType : ResolvableType.forInstance(event);
        Executor executor = this.getTaskExecutor();
        Iterator var5 = this.getApplicationListeners(event, type).iterator();

        while(true) {
            while(var5.hasNext()) {
                ApplicationListener<?> listener = (ApplicationListener)var5.next();
                /* Executor가 설정되어 있고 리스너가 비동기를 지원하면 */
                if (executor != null && listener.supportsAsyncExecution()) {
                    try {
                        executor.execute(() -> {
                        /* 이벤트를 리스너에게 전달 */
                            this.invokeListener(listener, event);
                        });
                    } catch (RejectedExecutionException var8) {
                        this.invokeListener(listener, event);
                    }
                } else {
                /* 설정된 Executor가 없다면 동기적으로 실행된다 */
                    this.invokeListener(listener, event);
                }
            }

            return;
        }
    }
        /* 생략 */

Executor가 없으면, 이벤트는 동기적으로 실행됩니다. 즉, 이벤트 리스너가 현재 스레드에서 호출됩니다.

반면, Executor가 설정되어 있다면, 이벤트는 비동기적으로 실행됩니다. 즉, 이벤트 리스너가 별도의 스레드에서 호출됩니다.

따라서, @Async 어노테이션을 붙여야 이벤트가 비동기적으로 처리됩니다. 이때 리스너는 이벤트를 별개의 스레드에서 처리합니다.

지금은 이벤트가 동기적으로 실행되고 있고 @Transactional로 묶여 있기 때문에 트랜잭션에 참여한 스레드에서 예외가 발생할 때 전부 롤백합니다. 그래서 조회수 증가 로직이 실행되었음에도 불구하고, 롤백이 된 것이죠.

🧵 동기적으로 실행 시 이벤트 리스너가 동일 스레드에서 동작

앞서 말했듯이, 이벤트 리스너가 동일 스레드에서 돌고 있으며, 동일 스레드 내에서 예외가 발생했으니 롤백시키고 있습니다.

동기적으로 이벤트를 실행할 때 정말 동일 스레드인지 직접 확인해보도록 하겠습니다.

먼저 아래와 같이 @Async 어노테이션 없이 기존처럼 이벤트를 동기적으로 처리해보도록 하겠습니다.

@Component
@RequiredArgsConstructor
public class ReadClubEventHandler {

    private final ClubStatisticsService clubStatisticsService;

    @EventListener
    public void readClubEventListener(ReadClubEvent event) {
        System.out.println("**** 이벤트 리스너 스레드 이름: " + Thread.currentThread().getName());
        clubStatisticsService.increaseVisitedClubCount(event.getClubToken());
    }
}

이벤트 리스너가 동호회를 조회하는 스레드와 동일한 스레드임을 확인했습니다.

이제 이벤트 리스너에 @Async 어노테이션을 붙여 이벤트를 비동기적으로 처리해보도록 하겠습니다.

@Component
@RequiredArgsConstructor
public class ReadClubEventHandler {

    private final ClubStatisticsService clubStatisticsService;

    @Async
    @EventListener
    public void readClubEventListener(ReadClubEvent event) {
        System.out.println("**** 이벤트 리스너 스레드 이름: " + Thread.currentThread().getName());
        clubStatisticsService.increaseVisitedClubCount(event.getClubToken());
    }
}

@SpringBootApplication
@EnableAsync
public class BadmintonApplication {
    public static void main(String[] args) {
        SpringApplication.run(BadmintonApplication.class, args);
    }
}

이벤트 리스너가 별개의 스레드에서 호출되는 것을 확인할 수 있었습니다.

이제 이벤트가 비동기적으로 처리되고 있으니, 앞서 예상했던 두 가지 시나리오를 다시 확인해보도록 하겠습니다.

예상한 시나리오 1 이벤트 핸들러에서 예외가 발생하더라도, 동호회 조회 API는 정상 응답할 것이다.

동호회 조회수를 올리는 로직에서 예외가 발생하지만, 이는 비동기적으로 처리되며 별도의 스레드에서 동작합니다. 따라서 동호회를 조회하는 API는 이벤트 리스너의 동작과는 무관하게 성공합니다.

예상한 시나리오 2 @EventListener를 사용했기 때문에 트랜잭션 실패에도 불구하고 이벤트가 실행되어 조회수가 늘어나 있을 것이다.

@TransactionalEventListener가 아닌 @EventListener를 사용했기 때문에, 트랜잭션이 실패했음에도 불구하고 이벤트가 처리되는 것을 확인했습니다. (기존에 조회수가 110이었고, 현재 1 증가한 상황)

🛤️ @TransactionalEventListener

위에서 @EventListener를 사용하면, 트랜잭션 실패 시에도 이와 무관하게 이벤트가 처리되는 것을 확인할 수 있었습니다.

다만, 조회수 읽기에 실패하면 조회수 또한 올라가지 않아야 한다는 요구사항이 있습니다. 이를 보장하려면, @TransactionalEventListener를 사용할 수 있습니다!

@EventListener 대신 @TransactionalEventListener를 사용하면 트랜잭션이 커밋되고 난 이후에 이벤트가 처리됩니다.

트랜잭션을 커밋하기 전에 예외를 발생시켜 이벤트가 정말 실행되지 않는지 확인해보도록 하겠습니다.

@Component
@RequiredArgsConstructor
public class ReadClubEventHandler {

    private final ClubStatisticsService clubStatisticsService;

    @Async
    @TransactionalEventListener
    public void readClubEventListener(ReadClubEvent event) {
        System.out.println("**** 이벤트 리스너 스레드 이름: " + Thread.currentThread().getName());
        clubStatisticsService.increaseVisitedClubCount(event.getClubToken());
    }
}

동호회 조회와 @Transactional로 함께 묶여 있는 블록 내에 예외를 던지는 코드를 작성했습니다.

@Transactional
    public ClubDetailsInfo readClub(String clubToken) {
        clubService.readClub(clubToken);
        eventPublisher.publishEvent(new ReadClubEvent(clubToken));
        throw new BadmintonException(ErrorCode.CLUB_NOT_EXIST);
    }

위에서 @EventListener를 사용했을 때는, 트랜잭션 커밋 여부와 상관없이 이벤트가 처리되었습니다.

반면, @TransactionalEventListener의 경우, 이벤트가 발행은 되지만, 트랜잭션 실패 시 이벤트가 처리되지 않는 것을 확인할 수 있었습니다.

이벤트가 발행은 되었으나, 트랜잭션이 실패했기 때문에 이벤트를 처리하지 않았습니다. 따라서 아래와 같이 조회수는 여전히 110입니다.

이제 동호회 조회에 실패하면, 동호회 조회수는 올라가지 않습니다! 😁

👀 헷갈렸던 부분

처음에는 @TransactionalEventListener 사용 시 트랜잭션이 실패했을 때 이벤트 처리가 롤백되는 것이라고 이해했습니다. 이는 틀린 말이며, 트랜잭션이 실패하면 이벤트 리스너가 아예 이벤트를 처리하지 않습니다. (혹시 저처럼 헷갈리신 분이 계실까봐 . . . 😅)

🔮 개선할 점

지금은 동호회 GET 요청이 들어왔을 때, 동일 사용자인지 등을 확인하지 않고 조회수를 올리고 있습니다. 동일 사용자에 대해서는 조회수를 1만 올리도록 제한하거나, 세션 정보를 활용해 개선할 예정입니다.

또한 레디스를 활용해 조회가 있을 때마다 DB에 업데이트를 하지 않고, 특정 시간이 지나거나 어느 정도 데이터가 쌓였을 때 DB에 업데이트를 하도록 수정하려고 합니다. 서비스에서 조회수의 실시간성이 아주 중요하다고 판단하지 않았기 때문입니다.

🎄 마치며

조회수를 비동기적으로 올리기 위해 Event Publisher를 공부하며 스레드에 대해서도 추가적인 공부를 할 수 있었습니다. 이제 조회수를 올리는 작업은 동호회 조회와는 별개의 스레드에서 비동기적으로 처리됩니다!

다만, 스프링에서 지원하는 Event는 동일 프로세스 내에서만 동작합니다. 스프링 이벤트 시스템이 ApplicationContext를 기반으로 동작하기 때문인데, 이러한 이유로 분산 환경에서는 별도의 메시징 시스템이 필요합니다. 카프카, RabbitMQ 등이 있으며 아직 공부해보지 못해서 추후에 적용해볼 계획입니다!

모두 해피 연말 보내세요 😁

📚 참고 자료

https://www.baeldung.com/spring-events

이 글은 커스텀 예외 처리를 어떻게 할지 고민하며 점진적으로 개선해나가는 과정을 담고 있습니다. 처음 커스텀 예외 클래스를 작성하시는 분부터, 더 좋은 예외 처리를 위해 고민하고 계시는 분들 모두에게 도움이 되는 글을 작성하고자 했습니다!

🙋‍♂️커스텀 예외를 왜 만들어야 하나요?

로또 번호는 1~45 사이의 숫자입니다. validateLottoNumber() 메서드는 이를 확인하고 범위를 벗어난 숫자에 대해 IllegalArgumentException을 던집니다.

public class LottoNumber implements Comparable<LottoNumber> {

    private final int lottoNumber;

    public LottoNumber(int lottoNumber) {
        validateLottoNumber(lottoNumber);
        this.lottoNumber = lottoNumber;
    }

    private void validateLottoNumber(int lottoNumber) {
        if(lottoNumber < 1 || lottoNumber > 45) {
            throw new IllegalArgumentException(lottoNumber);
        }
    }
}

메서드 파라미터에 잘못된 값이 입력되면 아래와 같이 에러가 발생합니다.

Exception in thread "main" java.lang.IllegalArgumentException
    at lotto.domain.lotto.LottoNumber.validateLottoNumber(LottoNumber.java:18)
    at lotto.domain.lotto.LottoNumber.<init>(LottoNumber.java:12)
    /* 생략 */

❓🙋‍이러한 에러 처리 방식에는 어떠한 문제점들이 있을까요?

1. 먼저, *예외의 원인을 분명하게 파악하기 어렵습니다. * 에러 메시지를 통해 validateLottoNumber 메서드에 문제가 발생했다는 것은 알 수 있습니다. 하지만 정확히 해당 메서드에 무슨 문제가 발생했는지 알 수 없습니다.

2. 또한, 어떤 값이 문제를 일으켰는지 알기 어렵습니다. 개발자는 로그를 통해 에러의 상세 내용을 확인할 수 있어야 합니다. 사용자가 잘못된 값을 입력했다면, 이를 로그로 남겨 개발자가 확인할 수 있어야 합니다.

단순히 IllegalArgumentException을 던지고, 아무런 메시지도 남기지 않는다면 예외가 발생할 때마다 디버깅을 반복적으로 해야겠죠!

위와 같은 이유로, 커스텀 예외를 만들고 예외가 발생한 원인을 구체적으로 남기는 것을 선호합니다.

🌱 어떻게 만드나요?

아주 간단합니다! 이번 3주차 미션의 요구사항에는 IllegalArgumentException을 던지는 것으로 되어 있었습니다. 그래서 CustomException 클래스를 만들고, IllegalArgumentException을 상속받도록 구현하면 됩니다.

public class InvalidLottoNumberException extends IllegalArgumentException{

    private static final String ERROR_MESSAGE = "[ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다.";

    public InvalidLottoNumberException() {
        super(ERROR_MESSAGE);
    }
}

이제 잘못된 값이 전달되면 아래와 같이 직접 정의한 메시지를 함께 확인할 수 있습니다.

Exception in thread "main" lotto.common.exception.InvalidLottoNumberException: [ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다.
    at lotto.domain.lotto.LottoNumber.validateLottoNumber(LottoNumber.java:18)
    at lotto.domain.lotto.LottoNumber.<init>(LottoNumber.java:12)
    at
    /* 생략 */

❓🙋‍ super()는 왜 하는거에요?

super(ERROR_MESSAGE)를 통해 부모 생성자가 호출됩니다. IllegalArgumentException를 잠깐 살펴보면 아래와 같은 생성자가 있습니다.

public IllegalArgumentException(String s) {
    super(s);
}

여기서도 부모 생성자를 호출하는데요, 이를 타고 들어가다 보면 최상위 Throwable이 나옵니다.

public Throwable(String message) {
    fillInStackTrace();
    detailMessage = message;
}

fillInStackTrace()는 예외가 발생한 시점의 스택 트레이스를 캡처합니다. 이를 통해 예외가 발생한 위치와 호출 경로를 추적할 수 있습니다.

detailMessage는 getMessage() 메서드를 통해 외부에서 조회할 수 있습니다. 따라서, InvalidLottoNumberException에서 전달한 메시지는 최상위 Throwable 클래스의 detailMessage 필드에 저장됩니다.

🐉 커스텀 예외 잘 만들기

이제부터 앞서 만든 커스텀 예외를 하나씩 고쳐보도록 하겠습니다!

1️⃣ 동적 메시지를 제공한다.

"[ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다."

해당 에러 메시지로는 어떤 로또 번호가 예외를 발생시켰는지 알기 어렵습니다. -1이었을 수도 있고, Integer.MAX_VALUE 정말 큰 수였을 수도 있죠.

개발자는 이슈가 생겼을 때 로그로 문제를 쉽게 파악할 수 있어야 합니다. 어떤 파라미터가 문제를 일으킨건지 빠르게 확인할 수 있어야 하는데요.

이때, 동적 메시지를 활용할 수 있습니다. 즉, 예외를 발생시킨 값을 메시지에 함께 제공하면 예외를 발생시킨 상황에 대한 파악을 더 빠르게 할 수 있습니다.

public class InvalidLottoNumberException extends IllegalArgumentException{

private static final String ERROR_MESSAGE = "[ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다.";

    public InvalidLottoNumberException(int invalidLottoNumber) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber + ")");
    }
}

커스텀 예외 클래스의 생성자에서 int 타입의 invalidLottoNumber를 전달받고 있습니다. 예외를 던지는 쪽에서는 아래와 같이 값을 전달합니다.

private void validateLottoNumber(int lottoNumber) {
    if(lottoNumber < 1 || lottoNumber > 45) {
        throw new InvalidLottoNumberException(lottoNumber);
    }
}

예외를 발생시킨 값을 에러 메시지를 통해 확인하고, 구체적인 상황을 파악하기가 쉬워졌습니다!

[ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다. (잘못된 로또 번호 : 90)

2️⃣ 예외 체이닝을 걸어준다.

예외 클래스를 만들땐 꼭 기존 예외랑 체이닝을 시켜줘야 합니다.

public LottoNumber readBonusNumber() {
    int bonusNumber;
    String input = Console.readLine();
    try {
        bonusNumber = Integer.parseInt(input);
    } catch (NumberFormatException e) {
        throw new InvalidLottoNumberException(input);
    }
    return new LottoNumber(bonusNumber);
}

보너스 번호를 사용자에게 입력받고, 숫자가 아니라면 InvalidLottoNumberException을 던지고 있습니다. String 변수를 int 타입으로 변환하는 과정에서 숫자가 아니라면 NumberFormatException이 발생합니다. 이를 try-catch로 잡아 커스텀 예외를 다시 던지고 있습니다.

이제 잘못된 보너스 번호를 입력해보겠습니다.

Exception in thread "main" lotto.common.exception.InvalidLottoNumberException: [ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다. (잘못된 로또 번호 : invalid)
    at lotto.interfaces.input.InputHandler.readBonusNumber(InputHandler.java:53)
    at lotto.interfaces.lotto.LottoController.getWinningLotto(LottoController.java:62)
    at lotto.interfaces.lotto.LottoController.lottoGameStart(LottoController.java:33)
    at lotto.Application.main(Application.java:10)

보시다시피 스택 트레이스에 NumberFormatException에 대한 정보가 어디에도 없습니다. 원천 예외가 있을 때는, 이를 cause에 담아야 스택 트레이스에 남습니다. 최상위 Throwable에서는 아래와 같이 cause를 받고 있습니다.

public Throwable(String message, Throwable cause) {
    fillInStackTrace();
    detailMessage = message;
    this.cause = cause;
}

여기에 cause를 전달하기 위해 커스텀 예외 클래스를 아래와 같이 수정할 수 있습니다.

public class InvalidLottoNumberException extends IllegalArgumentException{

    private static final String ERROR_MESSAGE = "[ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다.";

    /* 생략 */

    // 1번: 원천 예외가 없을 때
    public InvalidLottoNumberException(String invalidLottoNumber) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")");
    }

    // 2번: 원천 예외가 있을 때
    public InvalidLottoNumberException(String invalidLottoNumber, Exception e) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")", e);
    }
}

원천 예외를 받아, 이를 부모 생성자로 넘기고 있습니다.

원천 예외가 없을 때는 위쪽에 있는 생성자가 호출되고, NumberFormatException와 같이 원천 예외가 있을 때는 아래쪽에 있는 생성자가 호출됩니다.

따라서 커스텀 예외 클래스를 만들 때 위와 같이 두 가지 생성자를 모두 만들어야 합니다.

예외를 던지는 쪽에서는 아래와 같이 Exception을 함께 전달해주면 됩니다.

public LottoNumber readBonusNumber() {
    int bonusNumber;
    String input = Console.readLine();
    try {
        bonusNumber = Integer.parseInt(input);
    } catch (NumberFormatException e) {
        throw new InvalidLottoNumberException(input, e);
    }
    return new LottoNumber(bonusNumber);
}

이제 잘못된 보너스 번호 입력 시 아래와 같이 NumberFormatException도 함께 확인할 수 있습니다.

Exception in thread "main" lotto.common.exception.InvalidLottoNumberException: [ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다.(잘못된 로또 번호 : invalid)
    at lotto.interfaces.input.InputHandler.readBonusNumber(InputHandler.java:53)
    at lotto.interfaces.lotto.LottoController.getWinningLotto(LottoController.java:62)
    at lotto.interfaces.lotto.LottoController.lottoGameStart(LottoController.java:33)
    at lotto.Application.main(Application.java:10)
Caused by: java.lang.NumberFormatException: For input string: "invalid"
    at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
    at java.base/java.lang.Integer.parseInt(Integer.java:662)
    at java.base/java.lang.Integer.parseInt(Integer.java:778)
    at lotto.interfaces.input.InputHandler.readBonusNumber(InputHandler.java:51)
    ... 3 more

예외를 체이닝하면 예외의 원래 원인에 대한 자세한 정보를 제공할 수 있으며, 오류 발생 지점을 더 명확하게 파악하는데 필수적입니다.

3️⃣ 정의한 예외 vs 예기치 못한 예외: 구분의 중요성

개발을 하다보면, 종종 예외 상황을 마주하게 됩니다. 이때 커스텀 예외를 하나씩 만들며 예상치 못한 예외들을 줄여나가는데요! 이 둘을 구분하기 위해서 커스텀 예외가 상속받는 공통적인 예외 클래스를 추가적으로 하나 더 선언합니다.

바로 코드로 확인해보겠습니다!

public class LottoException extends IllegalArgumentException {

    private static final String ERROR_MESSAGE_HEADER = "[ERROR] ";
    private final String errorMessage;

    public LottoException(String message) {
        super(ERROR_MESSAGE_HEADER + message);
        this.errorMessage = ERROR_MESSAGE_HEADER + message;
    }

    public LottoException(String message, Exception e) {
        super(ERROR_MESSAGE_HEADER + message, e);
        this.errorMessage = ERROR_MESSAGE_HEADER + message;
    }
}

요구사항에 맞춰 IllegalArgumentException을 상속받은 LottoException 클래스를 하나 만들었습니다. 이는 앞으로 정의할 모든 커스텀 예외 클래스들이 상속받을 중추적인 예외 클래스인데요!

각 커스텀 예외에서 공통적으로 필요한 errorMessage를 갖고 있습니다. 또, [ERROR]를 메시지에 추가해주는 작업도 이쪽에서 수행합니다.

그럼, 다시 InvalidLottoNumberException을 수정해보겠습니다.

public class InvalidLottoNumberException extends LottoException{

    private static final String ERROR_MESSAGE = "로또 번호는 1부터 45 사이의 숫자여야 합니다.";

    public InvalidLottoNumberException(int invalidLottoNumber) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")");
    }

    public InvalidLottoNumberException(int invalidLottoNumber, Exception e) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")", e);
    }

    public InvalidLottoNumberException(String invalidLottoNumber) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")");
    }

    public InvalidLottoNumberException(String invalidLottoNumber, Exception e) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")", e);
    }
}

커스텀 예외 클래스가 상속받는 부모 클래스가 IllegalArgumentException에서 LottoException으로 변경되었습니다!

이렇게 했을 때의 장점은, 개발자가 정의한 예외와 그렇지 못한 예외를 구분할 수 있다는 점인데요!

예외를 처리하는 곳을 한 번 살펴보겠습니다.

private LottoMoney getLottoMoney() {
    while (true) {
        try {
            return inputHandler.readPurchaseAmount();
        } catch (LottoException e) {
            System.out.println(e.getMessage());
        } catch (Exception e) {
            System.out.println("예상치 못한 예외가 발생했습니다.");
    }
}

먼저 try-catch 블록에서 LottoException을 잡아 이를 처리합니다. 만약 LottoException이 아닌 다른 예외가 발생할 경우에는 하위 catch 블록이 실행되어 별도의 메시지를 출력하도록 했습니다.

❓🙋‍♂️ 이렇게 했을 때 장점이 무엇인가요?

😊 개발자가 정의된 예외와 예상치 못한 예외를 분리하여 처리할 수 있다.

private LottoMoney getLottoMoney() {
    while (true) {
        try {
            return inputHandler.readPurchaseAmount();
        } catch (IllegalArgumentException e) {
            System.out.println(e.getMessage());
        } 
    }
}

위의 코드에서는 개발자가 예상할 수 있는 예외(커스텀 예외)와 예상하지 못한 예외가 한곳에서 함께 처리되고 있습니다.

개발자가 미리 정의한 커스텀 예외는 특정 에러 메시지를 출력하고, 사용자로부터 다시 입력을 받도록 설계되어 있습니다. 그러나 예상치 못한 예외에 대해서는 다른 방식의 처리가 필요할 수 있습니다. 예를 들어, 에러 메시지를 띄운 후 시스템을 종료하거나, 별도의 에러 처리 로직을 실행할 수도 있습니다.

이럴 때 중추적인 예외를 만들어 처리하게 만들면, 개발자가 정의된 예외와 예상치 못한 예외를 분리하여 처리할 수 있습니다.

😊 예상치 못한 예외를 빠르게 파악하고, 그 수를 줄일 수 있다.

시스템에서 발생할 수 있는 예외를 미리 예측하고 대처하기 위해 예상치 못한 예외를 줄이고, 커스텀 예외를 정의하게 되는데요,

이때 try-catch에서 잡히지 못하는 예외는 모두 예상치 못한 예외로 간주되어, 미처 파악하지 못했던 예외 상황을 더 빠르게 구체화하는 데 도움을 줍니다.

이러한 이유로, LottoException 처럼 중추적인 예외를 하나 선언하고, 각 커스텀 예외 클래스가 이를 상속받도록 합니다. 예외를 처리하는 쪽에서 이 둘을 구분하여 핸들링해주면 얻을 수 있는 이점을 말씀드렸습니다.

🌳 마치며

Before & After

😈 Before

Exception in thread "main" java.lang.IllegalArgumentException
    at lotto.domain.lotto.LottoNumber.validateLottoNumber(LottoNumber.java:18)
    at lotto.domain.lotto.LottoNumber.<init>(LottoNumber.java:12)
    /* 생략 */

private void validateLottoNumber(int lottoNumber) {
    if(lottoNumber < 1 || lottoNumber > 45) {
        throw new IllegalArgumentException(lottoNumber);
    }
}

😁 After

Exception in thread "main" lotto.common.exception.InvalidLottoNumberException: [ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다. (잘못된 로또 번호 : invalid)
    at lotto.interfaces.input.InputHandler.readBonusNumber(InputHandler.java:53)
    at lotto.interfaces.lotto.LottoController.getWinningLotto(LottoController.java:62)
    at lotto.interfaces.lotto.LottoController.lottoGameStart(LottoController.java:33)
    at lotto.Application.main(Application.java:10)
Caused by: java.lang.NumberFormatException: For input string: "invalid"
    at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
    at java.base/java.lang.Integer.parseInt(Integer.java:662)
    at java.base/java.lang.Integer.parseInt(Integer.java:778)
    at lotto.interfaces.input.InputHandler.readBonusNumber(InputHandler.java:51)
    ... 3 more

public class InvalidLottoNumberException extends LottoException{

    private static final String ERROR_MESSAGE = "[ERROR] 로또 번호는 1부터 45 사이의 숫자여야 합니다.";

    public InvalidLottoNumberException(int invalidLottoNumber) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")");
    }

    public InvalidLottoNumberException(int invalidLottoNumber, Exception e) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")", e);
    }

    public InvalidLottoNumberException(String invalidLottoNumber) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")");
    }

    public InvalidLottoNumberException(String invalidLottoNumber, Exception e) {
        super(ERROR_MESSAGE + "(잘못된 로또 번호 : " + invalidLottoNumber+ ")", e);
    }
}

🌙 동적 메시지를 제공한다. 🌙 예외 체이닝을 걸어준다. 🌙 정의한 예외와 예상치 못한 예외를 구분한다.

이 세 가지를 적용해 커스텀 예외 클래스를 만들며 예외 처리 로직을 개선해보았습니다! 이슈가 생겼을 때 문제를 파악하기 쉽게 하려면, 어떤 파라미터가 문제를 일으킨 건지, 원천 예외가 있다면 무엇인지를 메시지에 잘 적어주는 것이 필요하다고 생각합니다.

아직 글에 담지 못한 내용이 많은데, 이는 2탄에서 이어가도록 하겠습니다..! ✨

2탄에서는, 아래와 같은 내용을 담아보려고 합니다!

_1. 에러 코드, 에러 메시지 관리하기 2. 커스텀 예외 클래스를 어디까지 나눠야 하지? 너무 많아지는거 아니야..? 3. 스프링에서 예외 처리 4. 자바의 표준 예외 활용하기?!?! 5. 로그도 IO야 _

1탄 내용에 부족한 점이 있거나, 2탄에서 듣고 싶은 이야기가 있으시다면 댓글로 많이 남겨주세요! 😁💚

참고자료

예외 체이닝 관련 https://www.baeldung.com/java-chained-exceptions

프리코스 1주차 미션을 수행하며 느낀 점들을 글로 남기고자 합니다. 48개의 커밋과 110개의 코드 리뷰를 주고 받으며 스스로 성장한 내용을 담고 있습니다.

👀 내 목표는 무엇이었을까?

목표를 설정하고, 이를 달성했을 때의 성취감을 좋아합니다. 성취감 중독으로 굴러가는 개발 일상 저에게는 성취감이 항상 다음 성장을 위한 동력이 되어 줍니다. 그러기 위해서는 목표를 설정하고, 이를 달성하기 위한 작은 계획들을 세우고 있습니다. 또 짧게라도 회고를 매일 작성하고 있는데요! 노션에서 아래와 같이 일정을 관리하고 있습니다.

지원서에 기재한 프리코스 목표는 아래와 같습니다.

1. 프레임워크 없이 객체 지향 설계를 처음부터 연습
2. 테스트 코드 작성
3. 좋은 영향력을 끼치기 위한 노력

이를 위해 세운 세부적인 계획은 아래와 같습니다.

✅ SOLID 원칙 준수하기 ✅ 다양한 디자인 패턴 코드에 녹여보기 ✅ TDD 첫 도전 ✅ 채널에 일주일에 적어도 2개씩 글 올리기 ✅ 코드 리뷰 열심히 참여하기

목표를 세웠다면, 이를 의식적으로 챙기면서 열심히 하루하루 굴러갑니다. ( •_•) ○ ) ○ )

📚 학습 과정

1주차를 어떻게 보냈는지 간단하게 되돌아보겠습니다.

🌙 1일차

기능 구현 목록을 정리하고, 문제 요구사항을 구체화했습니다. 간단한 요구사항이라고 생각했지만, 생각할 부분과 추가해야 하는 검증이 매우 많았습니다. 최대한 여러 가지 경우의 수를 생각해보며 어떻게 설계할지 고민했습니다.

🌙 2일차

TDD를 도전하기로 목표를 잡았습니다. Red - Green Cycle을 경험하며 작은 단위로 개발을 시작했습니다. 테스트 코드를 먼저 작성하고 개발을 하다 보니 자연스럽게 한 가지 일만 하는 메서드를 만들 수 있게 되었습니다. 벌써 첫 번째 계획 일부 달성!? 또 작은 커밋 단위를 지킬 수 있게 되었습니다. 기존에 프로젝트를 진행할 때 몇 백줄의 코드를 한 번에 커밋을 하던 행동을 깊게 반성하게 되었습니다.. 이때까지만 해도 TDD 최고!! 를 외쳤던 것 같습니다.

🌙 3일차

어랏 !? 생각보다 할 일이 너무 많다는 것을 느꼈습니다. 벌써 3일차인데 20개 남짓의 체크 박스 중에 3개밖에 완료하지 못했습니다. 이때부터 TDD의 스텝을 놓치기 시작했습니다. 큰 기능 단위로 구현을 했고 변경의 범위가 넓어지게 되었습니다.

🌙 4, 5일차

프로젝트 일정이 바빠 프리코스를 수행하지 못했습니다.

🌙 6일차

객체를 다시 정의했습니다. 요구사항을 다시 분석하며 Parser, Number, Separator, Calculator 등의 객체를 만들었고, 각각의 객체가 가질 상태와 행위, 의존성을 고민했습니다.

Parser는 Separator를 기준으로 문자열을 자르고, Calculator는 Number들을 계산합니다.

객체는 반드시 처음에 정의해야지

🌙 7일차

기능 구현을 완료했고, 세부적인 리팩토링을 진행했습니다. 변수명과 메서드명이 적절한지, 객체가 올바른 책임을 갖고 있는지 등을 고민했습니다.

📮 코드 리뷰

내가 작성한 리뷰 📖

총 13분의 코드를 리뷰하며 좋은 리뷰를 할 수 있도록 노력했고, 결과적으로 제 성장에도 많은 도움을 얻었습니다.

코드 리뷰를 할 때, 아래의 내용을 생각하며 좋은 리뷰를 하기 위해 노력하고 있습니다.

✅ 추상적으로 말하지 않기. 의견이 갈리는 것 같지만 개인적으로는, 구체적인 해결책까지 제시하는 걸 선호합니다. 서로의 의도를 이해하지 못해 두 번 질문이 오가는 것이 불편할 때가 있습니다.

✅ 상황에 적합한 리뷰를 하기. 너무 현실성이 떨어지는 리뷰는 지양하고 있습니다. 리뷰를 하시는 분의 코드 스타일과 상황을 존중하는 리뷰를 해야 한다고 생각합니다.

✅ 이렇게 해주세요 ❌ 이렇게 하는 거에 대해 어떻게 생각하세요? ⭕ 물론 상황마다 더 적합한 선택이 존재하지만, 기존에 내가 익숙한 방식이 틀릴 수도 있다는 것을 항상 전제에 두고 있습니다. 그렇기에 내가 작성한 코멘트가 무조건 정답이라고 강요하는 듯한 말투는 지양하고 있습니다.

이 외에도 세세하게 신경 쓰는 포인트가 많고, 앞으로도 좋은 리뷰를 하기 위해 많이 노력하려고 합니다!

내가 받은 소중한 리뷰들 🎁

https://github.com/woowacourse-precourse/java-calculator-7/pull/1037

감사하게도 총 11분께서 좋은 리뷰들을 남겨주셨습니다. 생각지도 못했던 부분을 짚어주시기도 했고, 더 좋은 방향성을 제시하거나 사소한 실수들을 바로잡아 주신 분도 계셨습니다.

시간을 들여 코드를 읽어주시고, 또 리뷰를 작성해주신 분들에 대한 기본적인 예의로 꼼꼼하게 읽어본 뒤, 댓글과 이모지를 열심히 달았습니다. 👀 🎉

많은 리뷰에서 공통된 몇 가지 사항에 있어 아래에 정리해보았습니다.

✍️ 코드리뷰를 통해 발견한 개선할 점들

1️⃣ 적절하지 않은 네이밍

네이밍이 굉장히 중요하다는 것을 이번 코드 리뷰를 통해 알게 되었습니다.

처음 제 코드를 보시는 분들은 클래스 이름을 통해 "아, 여기 이러한 기능들이 있겠구나" 생각하시고, 메서드 이름을 통해 "이 메서드는 이러한 역할을 수행하겠지?" 추측하시게 됩니다.

그런데 Calculator 라는 클래스에 들어가봤더니 정작 하는 기능은 문자열을 자르는 기능이라면 코드를 파악하는데 더 오랜 시간이 걸리겠죠.

이처럼 네이밍은 제 코드에 대한 첫인상이며, 가독성을 위한 중요한 역할을 수행하기에 더 신경을 써야 겠다는 다짐을 하게 되었습니다.

2️⃣ 변경에 대비해 상수 처리는 기본!

이번 과제에서 전반적으로 상수 처리가 미흡했던 것 같습니다. 특히 단일 문자로 구성된 Character 타입은 상수 처리를 할 생각을 하지 않고 하드코딩을 하게 되었습니다.

public Separators() {
        separators = new HashSet<>(Arrays.asList(':', ','));

기본 구분자는 언제든지 콜론(:)에서 쌍따옴표(") 등으로 변경이 될 가능성이 있기 때문에, 이를 상수 처리하는 것은 변경에 대비하는데 큰 도움이 됩니다.

작다고 무시하지 말고, 꼼꼼하게 상수 처리를 해야겠습니다!

3️⃣ 불필요한 주석은 지양하자

코드 리뷰를 받을 것에 대비해 메서드마다 주석을 달게 되었습니다. 보시는 분들의 편의성을 생각하고, 가독성을 높이기 위함이었는데요.

/*
* 리스트의 각 요소를 검증하고, Number 타입으로 변환하여 반환한다.
*/

다만, 코드 가독성은 주석이 아니라 네이밍, 클린 코드 등을 통해 보장되어야 합니다. 가독성이 충분히 지켜지지 않을 것 같다는 걱정에 주석을 달게 되었는데, 코드만 읽어도 술술 읽혀야 하겠네요 ..! 정말 많은 노력이 필요한 부분 같습니다.

💫 목표를 달성했는가?

✅ SOLID 원칙 준수하기 ✅ 다양한 디자인 패턴 코드에 녹여보기 ✅ TDD 첫 도전 ✅ 채널에 일주일에 적어도 2개씩 글 올리기 ✅ 코드 리뷰 열심히 참여하기

1주차 목표를 모두 달성했습니다!

함께 나누기 채널에 Commit Message 를 편하게 작성할 수 있는 plugin 관련 글, Intellij Ultimate 학생 계정으로 무료 이용하는 방법을 공유했습니다!

✨ 칭찬할 점

1주차에 세운 목표를 모두 달성했습니다! 코드 리뷰도 기존에 생각했던 것보다 훨씬 많은 양을 주고 받으며 많은 깨달음과 배움을 얻었습니다. 커뮤니티의 글들을 열심히 읽어보고, 또 배움을 직접 공유하기도 하며, 함께 성장하는 기분을 느끼고 있습니다! 진정한 몰입의 길을 걷는 것 같아 뿌듯했습니다.

🤔 아쉬운 점, 그리고 다음 목표를 세우자!

1️⃣ TDD .. 더 잘하고 싶어

비록 중간에 큰 단위의 리팩토링을 하며 TDD의 스텝을 꽈당 놓치게 되었지만, 처음으로 TDD에 도전해본 결과 많은 장점을 느꼈습니다. 리팩토링을 하더라도, 안전 장치가 존재해서 기존에 구현한 기능이 정상적으로 작동하는지 테스트할 수 있습니다. 또, 꼼꼼한 설계를 위한 지름길이 되어주기도 했습니다. 다만, 완전한 TDD를 하기에는 시간도, 실력도 부족함이 많다는 것을 느꼈습니다. TDD를 왜 실패했는지, 그 원인을 아래와 같이 정리했습니다.

🌨️ 원인 1 public 으로 선언한 메서드의 접근 제어자를 private으로 바꾸며 기존에 작성한 테스트를 사용할 수 없게 되었습니다.

🌨️ 원인 2 TDD를 실천하려고 하니 평소 개발하던 속도의 3배 정도가 걸렸습니다. 처음이라 익숙하지 않아 시간이 오래 걸렸고, 답답한 마음에 테스트 코드 작성을 후순위로 미루게 되었습니다.

🌨️ 원인 3 객체 지향 설계를 연습하자는 목표와 맞지 않게 초반에 객체에 대한 고민 없이 기능만 작성하여 개발을 시작했습니다. 중간에 추가적인 객체의 필요성을 느끼며 설계가 한 번 크게 변경되었습니다. 이때 큰 범위의 변경이 발생하며 TDD의 스텝을 놓쳤습니다.

2️⃣ 스트림 사용

정말 정말 부끄럽지만, 프로젝트를 할 때 스트림 사용에 익숙하지 않아 Gpt 에 많이 의존했던 것 같습니다. 스트림 사용에 더 자유로워질 수 있도록 많은 연습이 필요할 것 같습니다. 프리코스 미션을 수행하는 동안 Gpt를 사용하지 않고 있기 때문에, 스트림 사용에 더 자유로워질 수 있도록 많은 연습을 할 수 있을 것 같습니다!

3️⃣ 객체의 책임과 협력 관계에 대한 아쉬움

객체가 어떠한 책임을 갖고 어떠한 역할을 수행하는지에 대한 고민이 부족했던 것 같습니다. 또 객체를 정의하고, 어떤 식으로 협력하며 기능을 동작시킬지 고민해보는 시간이 부족했습니다. 다음 주차 미션부터는, 이러한 부분을 많이 고민하며 객체 설계부터 더 꼼꼼히 해보려고 합니다!

🐋 마치며

정말 많은 고민과 연습, 그리고 깨달음이 있었던 1주차였습니다. 특히 코드 리뷰를 통해 많은 도움을 얻었습니다. 함께 성장하는 경험을 하게 해준 모든 분들께 감사합니다! 이제 시작이기 때문에, 앞으로의 성장이 무척이나 기대됩니다! 읽어주셔서 감사합니다 :)

❓🙋‍♂️ 이 객체는 상태를 가지지 않는데, static 메서드로 선언해보는 것은 어떨까요?

우아한 테크코스 7기 프리코스를 수행하며 위와 같은 리뷰를 받게 되었습니다. 이를 보며 고민한 과정을 글로 남기고자 합니다.

아래의 Parser는 문자열에서 커스텀 구분자가 있는지 확인하여 구분자 리스트를 반환하고, 이를 기준으로 문자열을 자르는 등의 기능을 수행합니다. static 메서드가 아닌 인스턴스 메서드로 존재합니다.

public class Parser {

    private static final int SEPARATOR_LOCATION_INDEX = 2;

    public Separators getSeparatorList(boolean hasCustomSeparator, String inputStr) {
        Separators separators = new Separators();
        if (hasCustomSeparator) {
            separators.addCustomSeparator(inputStr.charAt(SEPARATOR_LOCATION_INDEX));
        }
        return separators;
    }

    public String[] splitStrBySeparator(Separators separators, String slicedStr) {
        String delimiter = separators.getSeparatorsRegex();
        String[] splitStr = slicedStr.split(delimiter);
        return Arrays.stream(splitStr)
                .filter(str -> !str.trim().isEmpty())
                .toArray(String[]::new);
    }

    /* 생략 */

<객체지향의 사실과 오해>라는 책을 보면 객체는 상태와 행위로 이루어져 있고, 행위로 상태가 변경됩니다.

1주차 미션에서 Number, Separator와 같은 객체는 상태와 행위를 가지고 있습니다.

이와 반면, Parser는 내부 상태를 가지지 않으며 행위만 존재합니다. 이렇게 상태가 없는 객체의 메서드는 static으로 선언해야 할까요?

아래는 제가 받은 리뷰의 일부입니다.

객체는 상태와 행위로 이루어져 있습니다.
그런데 Parser의 경우 상태 없이 행위만 정의하고 있습니다.
이렇게 상태가 없는 객체의 메서드는 static으로 선언하는게 어떨까요?
그럼 객체를 직접 생성할 필요도 없고, 기능만 수행하는 객체로 유지할 수 있을 것 같습니다. 

🙋‍♂️ 지금부터 이 질문에 대해 제가 고민을 한 과정을 공유해보려고 합니다!

🌱 함수와 메서드의 차이

먼저 함수와 메서드의 차이점에 대해 짚고 넘어가려고 합니다. 자바에서는 함수라는 표현을 잘 사용하지 않고 주로 메서드라고 부릅니다. 이 둘의 차이점은 뭐가 있을까요?

1️⃣ 함수

함수는 전달 받은 입력(파라미터)에 의해서만 결과가 바뀝니다.

public static String[] splitStrBySeparator(Separators separators, String slicedStr) {
    String delimiter = separators.getDelimiter();
    String[] splitStr = slicedStr.split(delimiter);
    return Arrays.stream(splitStr)
        .filter(str -> !str.trim().isEmpty())
        .toArray(String[]::new);
}

이는 구분자를 기준으로 문자열을 자르는 함수입니다. 파라미터로 받은 Separators, slicedStr에 따라 결과가 달라집니다. 즉, splitStrBySeparator라는 함수는 *오직 파라미터에 의해서만 결과가 바뀝니다. *

함수는 객체 지향 언어인 Java 보다는 절차 지향 언어에서 주로 정의됩니다. 절차 지향 언어에서는 클래스를 사용하지 않고, 외부에서 함수를 전역적으로 선언할 수 있습니다. 이를 통해 함수는 특정 클래스에 속하지 않고 코드 어디에서든 접근 가능해집니다.

그러나 자바에서는 모든 함수(메서드)가 반드시 클래스에 속해야 하기 때문에 이를 클래스 내부에 static 메서드의 형태로 정의하게 됩니다. 이렇게 정의된 static 메서드는 함수라고 부를 수 있습니다.

2️⃣ 메서드

그럼 메서드는 어떨까요? 메서드는 파라미터에 의해서도 결과가 달라지지만, 내부 상태에 의해서도 변화합니다.

public class Separators {

    private final Set<Character> separators;
    private String separatorsRegex;

    public Separators() {
        separators = new HashSet<>(Arrays.asList(':', ','));
    }

    public void addCustomSeparator(Character customSeparator) {
        validateSeparator(customSeparator);
        separators.add(customSeparator);
    }

    public String getSeparatorsRegex() {
        if (separatorsRegex == null) {
            makeDelimiter();
        }
        return this.separatorsRegex;
    }

    private void makeDelimiter() {
        StringBuilder delimiter = new StringBuilder();
        delimiter.append("[");
        for (Character separator : this.separators) {
            if (separator == '-' || separator == '[' || separator == ']') {
                delimiter.append("\\");
            }
            delimiter.append(separator);
        }
        delimiter.append("]");
        this.separatorsRegex = delimiter.toString();
    }

    private void validateSeparator(Character separator) {
        if (Character.isDigit(separator)) {
            throw new InvalidSeparatorException(separator);
        }
    }
}

separators라는 내부 상태가 변경되면서 getSeparatorsRegex 메서드의 반환 값도 달라집니다. 이처럼 메서드는 객체 안에 정의된 함수이며, 파라미터 뿐 아니라 객체의 내부 상태에 의해서도 변경될 수 있습니다.

또한 메서드는 메서드가 속해있는 클래스의 인스턴스를 통해서만 호출될 수 있습니다. 메서드가 해당 객체의 상태에 접근할 수 있고, 객체의 상태를 변경할 수 있기 때문이죠.

정리하자면, 함수는 파라미터에 의해서만 결과가 바뀌며, 메서드는 내부 상태에 의해서도 바뀝니다. 객체 안에 있는 함수를 메서드라고 부르며, 모든 메서드는 함수입니다. 반대로, 모든 함수가 메서드가 되는 것은 아닙니다.

📮 static method는 객체의 장점을 활용할 수 없다.

앞서 이야기한 흐름에 따르면, static 메서드는 함수와 같습니다. static 메서드는 오직 파라미터에 의해서만 결과가 바뀌며, 객체의 상태를 접근하거나 수정할 수 없습니다.

상태가 없는 객체의 메서드는 static method로 선언해도 인스턴스 메서드로 사용할 때와 큰 차이점은 없습니다.

다만, 클래스 내부의 모든 메서드를 static으로 선언했다면(주로 ~Util 등으로 이름 지은), 이는 객체라고 부를 수 없습니다. 따라서 객체의 장점을 이용할 수 없게 됩니다.

1️⃣ 다형성

제일 먼저, 다형성을 활용할 수 없습니다. 예를 들어 Parser 라는 인터페이스를 두고, StringParser, NumberParser 처럼 다양한 구현체를 만든다고 가정해보겠습니다.

🌙 Parser

public interface Parser {
    String[] parse(String input);
}

🌙 CommaParser

public class CommaParser implements Parser {
    @Override
    public String[] parse(String input) {
        return input.split(",");
    }
}

🌙 ColonParser

public class ColonParser implements Parser {
    @Override
    public String[] parse(String input) {
        return input.split(":");
    }
}

Parser를 인터페이스로 선언하고, 내부에 문자열을 자르는 행위를 나타내는 parse 메서드를 두었습니다.

Parser를 구현한 CommaParser, ColonParser는 각각 쉼표(,), 콜론(:)을 기준으로 문자열을 잘라서 반환합니다. "자른다"는 행위를 재사용할 수 있게 되었습니다.

이와 같이 parser 메서드를 static으로 선언하지 않고, 인스턴스 메서드로 선언함으로써 *Parser는 객체로 활용될 수 있습니다. *

반면, parse 메서드를 static으로 선언한다면, 위처럼 *다형성이라는 장점을 활용할 수 없게 됩니다. *

public class ParserStatic {

    public static String[] parse(String input) {
        return input.split(",");
    }
}

ParserStatic 클래스는 객체라고 말하기 어렵습니다. 여러 가지 ParserStatic을 만들 수도 없고, parse라는 메서드를 재사용할 수도 없습니다. 앞의 예시처럼 쉼표(,), 콜론(:) 등 구분자를 기준으로 다양한 parse 메서드를 구현할 수 없어졌습니다.

1주차 프리코스 미션에서 지금 당장은 Parser가 확장될 일이 없어 보이지만, 만약 객체의 다형성이 필요한 시점이 왔을 때, static 메서드로만 선언한 클래스는 확장하여 사용할 수 없습니다. 확장에 닫혀 있다는 것은 좋지 않은 설계입니다.

또한 객체 지향 프로그래밍에서 다형성은 중요한 개념이기 때문에 다형성을 활용할 수 없다는 것은 큰 단점이라고 생각했습니다.

2️⃣ 독립적 단위 테스트의 어려움

두 번째로, 클래스 내부의 메서드를 모두 static으로 선언하게 된다면, 이를 모킹하여 테스트하는 일이 굉장히 어려워집니다.

먼저 모킹을 하는 이유는, 의존하는 클래스에 대한 의존성을 잠시 끊고 독립적으로 단위 테스트하기 위함입니다.

그러나 static 메서드는 Parser를 모킹해 테스트하고 싶을 때, 이를 불가능하게 만듭니다.

parse 메서드를 static으로 선언하지 않고, Parser를 사용하는 StringWrapper라는 클래스를 테스트하는 예시를 살펴 보도록 하겠습니다.

StringWrapper 클래스에 문자열을 자르고 이를 인덱싱하고 감싸서 반환하는 기능을 하는 메서드를 선언했습니다.

public class StringWrapper {

    private final Parser parser;

    public StringWrapper(Parser parser) {
        this.parser = parser;
    }

    public String wrap(String input) {
        String[] splitInput = parser.parse(input);
        StringBuilder result = new StringBuilder();
        for (int i = 0; i < splitInput.length; i++) {
            result.append(i);
            result.append(splitInput[i]);
        }
        return String.valueOf(result);
    }
}

StringWrapper는 Parser 인터페이스에 의존하며, 다양한 Parser 구현체를 주입받습니다.

이제 StringWrapper를 독립적으로 단위 테스트해보도록 하겠습니다. FakeParser를 만들고 이를 StringWrapper에 모킹해 테스트하려고 합니다.

StringWrapper를 단위 테스트하는 코드는 아래와 같습니다.

@Test
void fakeParserTest() {
    FakeParser fakeParser = new FakeParser();
    StringWrapper stringWrapper = new StringWrapper(fakeParser);
    assertThat(stringWrapper.wrap("a,b:c")).isEqualTo("0fake1parser2for3test");
}

public class FakeParser implements Parser {
    @Override
    public String[] parse(String input) {
        return new String[] {"fake", "parser", "for", "test"};
    }
}

FakeParser는 input과는 무관하게 항상 동일한 결과를 리턴하는 가짜 목 객체입니다. 이로써 StringWrapper를 독립적으로 단위테스트 할 수 있게 됩니다. Parser와는 무관하게 StringWrapper 만을 테스트할 수 있게 되는 것이죠.

이제 parse 메서드를 static 메서드로 선언하고, 위의 과정을 다시 살펴보도록 하겠습니다.

public class StringWrapper {

    public String wrap(String input) {
        String[] splitInput = ParserStatic.parse(input);
        StringBuilder result = new StringBuilder();
        for (int i = 0; i < splitInput.length; i++) {
            result.append(i);
            result.append(splitInput[i]);
        }
        return String.valueOf(result);
    }
}

StringWrapper에서 ParserStatic.parse(클래스 이름.메서드명)로 ParserStatic 클래스의 parse 메서드를 사용하고 있습니다.

StringWrapper에 대한 테스트 코드는 아래와 같습니다.

@Test
void staticParserTest() {
    StringWrapper stringWrapper = new StringWrapper();
    assertThat(stringWrapper.wrap("a,b:c")).isEqualTo("0a1b:c");
}

그런데 이때, ParserStatic 클래스를 수정하다가 아래처럼 문제가 발생한다면 어떻게 될까요?

public class ParserStatic {

    public static String[] parse(String input) {
        throw new IllegalArgumentException("ParserStatic 클래스에 문제 발생");
    }
}

parse 메서드에서 예외를 발생하기 때문에 StringWrapper에 대한 단위테스트도 실패하게 됩니다.

StringWrapper가 의존하고 있는 ParserStatic에 문제가 발생했을 때 이 영향이 StringWrapper에 미치고 있기 때문에, 이러한 의존성을 끊고 목 객체를 생성하고 싶습니다.

그러나 static 메서드의 경우 앞선 에시처럼 가짜 목 객체를 생성해 테스트에 활용할 수가 없습니다. 이로써 static 메서드를 포함한 클래스를 모킹하여 테스트하기가 어려워집니다.

📚 static 메서드로 선언한다는 것은

static 메서드를 사용할 경우, 위와 같은 객체의 장점을 잃어버리기 때문에 잘 생각해보고 사용해야 할 것 같습니다.

단순히 상태가 없다면 static 메서드를 사용해야 한다는 것은 틀린 말입니다. 객체는 상태가 있을 수도 있고, 없을 수도 있습니다. 중요한 것은 static 메서드가 나열된 클래스는 객체로 활용될 수가 없기 때문에, 해당 클래스를 객체로 볼 것인지 아닌지를 먼저 고려해보아야 합니다. 만약 Parser를 객체로 보지 않는다면, static 메서드로 선언할 수도 있습니다. 그러나 단순히 상태가 없다고 static으로 만들면 안됩니다.

그 예시로, Spring 프로젝트를 할 때 Service, Controller 등 @Component가 붙어 빈에 등록되는 객체들은 모두 내부에 상태(인스턴스 변수)를 가질 수 없습니다. 이들은 싱글톤 빈에서 관리되기 때문에 애플리케이션 전체에서 하나의 인스턴스만 생성되어 여러 요청에서 공유됩니다. 즉, 멀티스레드에서 공유되는 객체기 때문에 변경이 가능한 상태를 뒀을 때 동시성 문제가 발생할 수 있습니다. 이들은 상태를 가지지는 않지만 명백한 객체입니다.

🤔 그럼 static method는 쓰지 말아야 하는가?

엘레강트 오브젝트라는 책에서 static은 객체가 아니니까 절대 쓰지 말라고 합니다. 그러나 코드나 설계에는 항상 트레이드 오프가 존재하기 때문에 적절한 시점에 사용할 줄 알아야 한다고 생각합니다. static을 통해 구현하는 것도 방법 중의 하나이며, static 메서드를 사용할 때가 더 적합한 상황도 분명히 존재합니다.

그렇기 때문에 static method로 선언할 때와 객체의 인스턴스 메서드로 선언할 때의 차이점을 분명히 알고, 필요할 때 적절한 방식을 잘 선택할 줄 아는 것이 중요합니다.

🌳 결론

1주차 미션에서 제가 정의한 Parser의 경우 구체적인 클래스입니다. 또한 객체 내부에 상태를 가지고 있지 않기 때문에 static 메서드로 선언해도, 동작하는 데에 큰 차이점은 없습니다. 다만, 요구사항이 변경되어 Parser를 인터페이스로 만들고, CommaParser, ColonParser 등 다양한 구현체를 만들게 된다면, Parser는 반드시 객체로 만들어야 합니다. static 메서드로만 동작하는 클래스는 객체라고 부를 수 없습니다. 따라서 객체가 상태를 가지지 않으면 static 메서드를 사용하는 것이 아니라, 해당 클래스를 객체로 볼 것인지를 먼저 고민해볼 필요가 있습니다. 저의 경우 Parser를 객체로 바라봤습니다. static 메서드 또한 분명 필요한 경우가 있기 때문에 이에 대한 공부가 더 필요할 것 같습니다!

1. Spring Security 설정

package org.example.catch_line.config;

@EnableWebSecurity // 스프링 시큐리티 필터가 스프링 필터체인에 등록된다.
@EnableMethodSecurity(securedEnabled = true, prePostEnabled = true)
// secured 어노테이션 사용 가능(특정 메서드에 간단하게 걸고 싶을 때 사용) "ROLE_ADMIN"
// @PreAuthorize 어노테이션 사용 가능 "hasRole('ROLE_MANAGER') or hasRole('ROLE_ADMIN')" 함수가 실행되기 전에 권한을 검사
@Configuration
@RequiredArgsConstructor
public class SecurityConfig{

    private final PrincipleOAuth2DetailsService principleOAuth2DetailsService;
    private final PrincipalDetailsService principalDetailsService;

    @Bean
    public static BCryptPasswordEncoder bCryptPasswordEncoder() {   // for hash encrypt
        return new BCryptPasswordEncoder();
    }

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http, PrincipleOAuth2DetailsService principleOAuth2DetailsService) throws Exception {
        http
                .cors(cors -> cors.configurationSource(corsConfigurationSource()))  // CORS 설정을 최신 방식으로 변경
                .csrf(AbstractHttpConfigurer::disable)
                .headers(headers -> headers.frameOptions(frameOptions -> frameOptions.disable()))  // frameOptions 설정
                .authorizeHttpRequests(requests ->requests
                        .requestMatchers("/**", "/static/**", "/images/**", "/signup", "/login", "/restaurants/**", "/owner").permitAll()
                        .requestMatchers("/members", "/history").authenticated() // 인증이 필요
                        .anyRequest().permitAll()
                )
                // 일반 로그인
                .formLogin(formLogin -> formLogin
                        .loginPage("/login")  // 로그인 페이지 URL
                        .loginProcessingUrl("/loginProcess")  // 로그인 처리 URL (여기에 POST 요청이 와야 함)
                        .defaultSuccessUrl("/")
                        .failureUrl("/login?error=true")
                        .permitAll()
                )
                        // Oauth 로그인
                .oauth2Login(login -> login
                        .loginPage("/login/oauth")
                        .defaultSuccessUrl("/loginSuccess")
                        .userInfoEndpoint()
                        .userService(principleOAuth2DetailsService) // OAuth 사용자 로그인 처리
                )
                .userDetailsService(principalDetailsService);  // 일반 사용자 로그인 처리

//                .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS));

        return http.build();
    }
    @Bean
    public CorsConfigurationSource corsConfigurationSource() {
        CorsConfiguration configuration = new CorsConfiguration();
        configuration.setAllowedOrigins(Arrays.asList("http://localhost:8080", "http://localhost:8081"));
        configuration.setAllowedMethods(Arrays.asList("GET", "POST", "PUT", "DELETE", "OPTIONS"));
        configuration.setAllowedHeaders(Arrays.asList("*"));
        configuration.setAllowCredentials(true);

        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        source.registerCorsConfiguration("/**", configuration);
        return source;
    }
}

2. Authentication 객체에 저장되는 PrincipalDetail → UserDetails, OAuth2User 둘 다 구현

두 개의 생성자를 통해 일반 로그인 사용자와 OAuth 로그인 사용자를 구분했다. 일반 로그인을 한 경우 UserDetails가 생기며, OAuth로 로그인을 할 경우 OAuth2User가 생성된다.

package org.example.catch_line.config.auth;

import lombok.Data;
import org.apache.logging.log4j.util.Strings;
import org.example.catch_line.common.constant.Role;
import org.example.catch_line.user.member.model.entity.MemberEntity;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.oauth2.core.user.OAuth2User;

import java.util.ArrayList;
import java.util.Collection;
import java.util.Map;

@Data
public class PrincipalDetail implements UserDetails, OAuth2User {

    private MemberEntity member;

    private Map<String,Object> attributes;

    // 일반 로그인 생성자
    public PrincipalDetail(MemberEntity member) {
        this.member = member;
    }

    // Oauth 로그인 생성자
    public PrincipalDetail(MemberEntity member, Map<String, Object> attributes) {
        this.member = member;
        this.attributes = attributes;
    }

    @Override
    public Map<String, Object> getAttributes() {
        return attributes;
    }

    // 잘 사용하지 않는다.
    @Override
    public String getName() {
        return Strings.EMPTY;
    }

    @Override
    public Collection<? extends GrantedAuthority> getAuthorities() {
        Collection<GrantedAuthority> collect = new ArrayList<>();
        collect.add(new GrantedAuthority() {
            @Override
            public String getAuthority() {
                return Role.USER.getDescription();
            }
        });
        return collect;
    }

    @Override
    public String getPassword() {
        return member.getPassword() != null ? member.getPassword().getEncodedPassword() : "";
    }

    @Override
    public String getUsername() {
        return member.getEmail().getEmailValue();
    }

}

일반 로그인과 OAuth 로그인 각각 서비스 구현

1. 일반 로그인 서비스 구현 PrincipalDetailsService

package org.example.catch_line.config.auth;

@Service
@RequiredArgsConstructor
public class PrincipalDetailsService implements UserDetailsService {

    // 시큐리티 session (내부 Authentication (내부 UserDetails ))
    private final MemberDataProvider memberDataProvider;

    // 함수 종료 시 @AuthenticationPrincipal 어노테이션이 만들어진다.
    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        MemberEntity member = memberDataProvider.provideMemberByEmail(new Email(username));
        return new PrincipalDetail(member);

    }
}

2. OAuth2 로그인 서비스 구현

package org.example.catch_line.config.auth;

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.example.catch_line.common.constant.Role;
import org.example.catch_line.common.model.vo.Email;
import org.example.catch_line.user.member.model.entity.MemberEntity;
import org.example.catch_line.user.member.model.provider.MemberDataProvider;
import org.springframework.security.core.GrantedAuthority;
import org.springframework.security.core.authority.AuthorityUtils;
import org.springframework.security.oauth2.client.userinfo.DefaultOAuth2UserService;
import org.springframework.security.oauth2.client.userinfo.OAuth2UserRequest;
import org.springframework.security.oauth2.core.OAuth2AuthenticationException;
import org.springframework.security.oauth2.core.user.OAuth2User;
import org.springframework.stereotype.Service;
import org.thymeleaf.util.StringUtils;

import java.util.List;
import java.util.Map;

@Service
@RequiredArgsConstructor
@Slf4j
public class PrincipleOAuth2DetailsService extends DefaultOAuth2UserService {

    private final MemberDataProvider memberDataProvider;

    @Override
    public OAuth2User loadUser(OAuth2UserRequest userRequest) throws OAuth2AuthenticationException {

        OAuth2User oAuth2User = super.loadUser(userRequest);

        // Role generate
        List<GrantedAuthority> authorities = AuthorityUtils.createAuthorityList(Role.USER.getDescription());

        Map<String, Object> attributes = oAuth2User.getAttributes();
        log.info("attributes: {}", attributes);

        Map<String, Object> properties = (Map<String, Object>) attributes.get("properties");
        String name = (String) properties.get("nickname"); // properties에서 닉네임 가져오기

        Map<String, Object> kakaoAccount = (Map<String, Object>) attributes.get("kakao_account");
        String email = (String) kakaoAccount.get("email"); // kakao_account에서 이메일 가져오기

        String provider = userRequest.getClientRegistration().getRegistrationId(); // kakao
        Long providerId = ((Number) attributes.get("id")).longValue();
        String nickname = provider + "_" + StringUtils.substring(providerId, 0, 7); // kakao_이름

        if (memberDataProvider.isNotDuplicateKakaoMember(providerId, new Email(email))) {
            MemberEntity member = MemberEntity.builder()
                    .name(name)
                    .nickname(nickname)
                    .email(new Email(email))
                    .kakaoMemberId(providerId)
                    .build();
            memberDataProvider.saveMember(member);
        }

        MemberEntity member = memberDataProvider.provideMemberByKakaoMemberId(providerId);

        // 어떤 OAuth2 공급자를 통해 로그인하는지, 해당 공급자에서 사용자의 고유 식별자를 나타내는 필드명이 무엇인지를 반환한다.
        // 지금 kakao login만 사용하기 때문에 필요없지만, 추후 구현 위해 남겨 놓는다.
        String userNameAttributeName = userRequest.getClientRegistration()
                .getProviderDetails()
                .getUserInfoEndpoint()
                .getUserNameAttributeName();

        return new PrincipalDetail(member, oAuth2User.getAttributes());
    }
}

마치며

일반 로그인과 OAuth2 로그인을 동시에 사용하기 위해 Security 설정을 어떻게 할 수 있는지 알아봤다.

필터는 모든 요청에 대해 동작한다. 특정 url에서만 필터가 동작하도록 하기 위해 White List를 리스트 형태로 만들었다. 다만 아래와 같은 상황에서 어떻게 구현할지 고민이 되었다.

/restaurants는 통과, /restaurants/{restaurant-id}/waitings는 통과하면 안될 때 필터 조건을 어떻게 줄 수 있을까?

1. 화이트 리스트 설정에서 /restaurants는 제외

private static final List<String> WHITELIST_URLS = Arrays.asList(
    "/login",
    "/logout",
    "/signup",
    "/static",
    "/css",
    "/js",
    "/owner"
);

2. 인증이 필요한 /restaurants 하위 경로를 블랙 리스트에 추가

private static final List<String> BLACKLIST_URLS = Arrays.asList(
    "/reviews/create",
    "/scraps",
    "/waiting",
    "/reservation"
);

3. shouldNotFilter에서는 white list를 처리

@Override
protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
    String requestURI = request.getRequestURI();
    return WHITELIST_URLS.stream().anyMatch(requestURI::startsWith);
}

4. doFilterInternal 내부에서 /restaurants로 시작하면서 블랙 리스트에 해당되지 않는 URI는 필터 통과

if (requestURI.startsWith("/restaurants") && !isBlacklisted(requestURI)) {
        chain.doFilter(request, response);
        return;
}

OncePerRequestFilter의 shouldNotFilter

BasicAuthenticationFilter는 OncePerRequestFilter를 상속받는다. OncePerRequestFilter는 아래와 같은 메서드를 재정의하여 사용할 수 있다.

*protected boolean* shouldNotFilter(*HttpServletRequest* request) *throws* ServletException {    
            *return false*;
}

아래와 같은 화이트리스트가 있다고 가정하자.

private static final List<String> WHITELIST_URLS = Arrays.asList(
            "/owner/login",
            "/owner/signup",
            "/templates",
            "/static",
            "/css",
            "/js"
);

기존에는 아래와 같은 메서드를 만들어 WHITELIST_URLS로 시작하는 경로는 모두 필터를 통과시켰다.

private boolean isWhitelisted(String requestURI) {
        return WHITELIST_URLS.stream().anyMatch(url ->  requestURI.startsWith(url));
}

doFilterInternal 메서드 안에는 아래와 같이 isWhitelisted를 동작시켜 검증하는 코드가 존재했다.

if (isWhitelisted(requestURI)) {
        chain.doFilter(request, response);
        return;
}

shouldNotFilter 메서드는 true를 반환할 경우 필터가 적용되지 않으며, false를 반환할 경우 필터가 적용된다.

@Override
protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
        String requestURI = request.getRequestURI();
    return WHITELIST_URLS.stream().anyMatch(requestURI::startsWith);
}

마치며

간단하게 화이트리스트와 블랙리스트를 구현하여 url을 상세하게 나누어 필터 조건을 주었다.

@Bean
// Primary 지정해버리면 다른 config 파일이더라도 무조건 이것만 사용된다. -> Bean에 이름 지정 필요
@Primary
public AuthenticationManager memberAuthenticationManager(HttpSecurity http) throws Exception {
        DaoAuthenticationProvider provider = new DaoAuthenticationProvider();
        provider.setUserDetailsService(memberDefaultLoginService);
        provider.setPasswordEncoder(bCryptPasswordEncoder());
        return new ProviderManager(provider);
}

@Bean
public AuthenticationManager ownerAuthenticationManager(HttpSecurity http) throws Exception {
        DaoAuthenticationProvider provider = new DaoAuthenticationProvider();
        provider.setUserDetailsService(ownerLoginService);
        provider.setPasswordEncoder(bCryptPasswordEncoder());
        return new ProviderManager(provider);
}

1. @Qualifier를 통해 사용할 AuthenticationManager의 이름을 지정해준다.

2. FilterChain에 AuthenticationManager authenticationManager만 파라미터로 넣어주면 @Primary로 지정한 AuthenticationManager만 들어간다. 다른 Security Config 파일을 사용해도 마찬가지다. 그래서 반드시 이름으로 둘을 구분하고, 하나의 config에서 둘 다 사용할 경우 둘 다 넣어줘야 한다.

3. AuthenticationFilter의 경우 아래와 같이 authenticationManager의 authenticate을 통해 UserDetailsService를 호출하여 로그인 요청을 처리한다.

    *Authentication* authentication = authenticationManager.authenticate(authenticationToken);

4. AuthorizationFilter의 경우 BasicAuthenticationFilter를 상속받는다. 이 필터가 내부에 AuthenticationManager를 갖고 있기 때문에 필요하다. → 🌟OncePerRequestFilter로 변경 가능할지?

5. 위와 같은 이유로 두 개의 필터에서 모두 AuthenticationManager를 필요로 한다.

6. Authentication Manager를 잘 맞게 넣어준다.

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http,
                @Qualifier("memberAuthenticationManager") AuthenticationManager memberAuthenticationManager,
        @Qualifier("ownerAuthenticationManager") AuthenticationManager ownerAuthenticationManager) throws Exception {

// form Login disable -> 해당 필터 사용할 수 있도록 추가, AuthenticationManager 넣어줘야 한다.

        MemberJwtAuthenticationFilter memberJwtAuthenticationFilter = new MemberJwtAuthenticationFilter(memberAuthenticationManager);
        MemberJwtAuthorizationFilter memberJwtAuthorizationFilter = new MemberJwtAuthorizationFilter(memberAuthenticationManager);

        OwnerJwtAuthenticationFilter ownerJwtAuthenticationFilter = new OwnerJwtAuthenticationFilter(ownerAuthenticationManager);
        OwnerJwtAuthorizationFilter ownerJwtAuthorizationFilter = new OwnerJwtAuthorizationFilter(ownerAuthenticationManager);
     /*
     * 생략 
     */
}

Kernel 360의 기술세미나란?

프로젝트를 하며 했던 기술적인 공부, 고민들의 해결 과정 등을 크루들 앞에서 발표하는 시간입니다!

저의 경우에는 VO(Value Object)를 주제로 발표를 진행했습니다!

주제 선정 🧘

제가 주제를 선정한 기준은 아래와 같았습니다!

1. 프로젝트를 하며 학습한 내용일 것!
2. 많은 고민을 거쳐 문제를 해결한 과정을 담을 수 있을 것!
3. 크루들의 공감이 갈 수 있는 주제일 것!

저희 팀에서 E2E 프로젝트를 진행하며 Builder 패턴에 대한 고민을 하며 VO를 적용하여 해결한 과정을 크루들과 공유하고 싶었습니다.

발표에 대한 두려움 😧

사실 저는 20학번입니다 !! 두둥

코로나 시기에 비대면으로 학교를 다녀서 발표에 점점 자신이 없어지게 되었습니다 😭 Kernel에 들어와서 발표할 기회가 많이 있었고, 이를 최대한 활용하려고 했습니다!

아이디어 발표, 프로젝트 설계 발표, 프로젝트 중간 발표, 최종 발표, 기술 세미나 등 생각보다 많은 기회가 있습니다.

두 달 동안 위의 발표를 모두 해볼 수 있었습니다! 점점 발표에 두려움은 없어졌고, 어떻게 하면 이 내용을 잘 전달할 수 있는가 등의 실용적인 고민들을 하게 되었습니다 ㅎㅎ

목차 정하기 🍬

하고 싶은 이야기를 정했으니, 목차를 정하기 시작했습니다. 목차를 정할 때는 최종적으로 어떤 이야기를 전달하고 싶은지를 계속 생각하면서 시나리오를 잘 만들어야 하는 것 같습니다.

다른 사람이 하는 이야기가 잘 와닿기 위해서는 이야기들의 최종 종착지가 뚜렷해야 하고, 그 흐름이 납득이 가야 하는 것 같습니다!

VO에 대해 하고 싶은 이야기들을 효율적으로 전달하려면 발표가 어떤 구성으로 이루어져야 하는지를 생각해봤습니다.

저희 팀이 VO를 사용하게 된 이유는 생성자 방식에서 타입 안전성을 보장하기 위함이었습니다! 왜 빌더 패턴 대신 생성자 방식을 사용하는지, VO를 사용하면 어떻게 달라지는지를 시작으로 VO의 특징을 코드와 함께 제시하기로 했습니다.

이렇게 정해진 목차는 아래와 같습니다 ✨

✅ VO 개념 💵 실생활 속 VO 예시 ❓ VO를 사용하는 이유

1. 타입 안전성
2. 원자적 객체 생성 🚼 VO 특징 1. 불변성
   • 만약 내부 상태 변경이 필요하다면?
   • 대표적인 불변 클래스 - String
   • 잦은 객체 생성에 대한 고민? 🍋‍ VO 특징 2. 생성 시 값을 검증 🟰 VO 특징 3. 동등성
   • Equals, Hashcode

발표 준비 🙋‍♀️

여러분들은 발표를 어떻게 준비하시나요? 저희 크루들은 대본을 작성해서 외우기도 하고, 내용을 머릿속에 잘 정리해 막힘없이 줄줄 이야기하기도 합니다!

저는 대본을 작성해도 결국 입에 붙는 말로 발표를 하게 되는 것 같아서 발표할 내용을 처음부터 끝까지 입으로 말하는 연습을 합니다!

발표 내용을 구성하고 장표를 준비하는 동안 이미 발표 내용은 머리에 다 들어있습니다. 다만 이를 매끄럽게 말하려면 연습이 필요한 것 같습니다 ㅎㅎ

발표 시간도 계산해보고, 매끄럽지 못한 부분도 알 수 있게 됩니다!

발표, 그리고 그 이후 💭

기술 세미나를 통해 VO와 관련하여 하고 싶었던 이야기를 잘 전달할 수 있었습니다! 퀴즈 시간에 발표를 크루들이 잘 이해했는지 확인할 수 있었습니다.

또, Q&A 시간에 크루분들의 질문을 받으며 저도 조금 더 공부해야 할 점들을 알게 되었고, 멘토님과 소통하며 이를 보완할 수 있었습니다!

기술 세미나를 통해 VO를 누구에게나 잘 설명할 수 있게 되었습니다. "공부라는 것이 이런게 아닐까?"라는 생각도 들었고, "무언가를 제대로 알고 있다고 이야기하려면 이만큼은 공부해야 하는 거구나..."라는 생각도 했습니다.

발표를 준비하면서, 프로젝트 기간 동안 공부했던 내용을 정리할 수 있었고, 더 밀도가 높은 지식을 쌓을 수 있게 되었습니다. 이를 다른 사람들 앞에서 발표하고 지식을 공유하는 일이 얼마나 중요한지 알 수 있었던 시간이었던 것 같습니다. 또 발표에서 끝나지 않고, 추가적인 Q&A를 통해 생각을 확장할 수 있었던 점도 좋았습니다.

이후에 기술 세미나의 내용을 블로그에 정리하며 VO와 관련한 모든 고민들과 생각의 과정, 발표 내용, Q&A 등을 한꺼번에 실을 수 있었습니다!

혹시.. 궁금하시다면 아래의 링크를 통해 확인해주세요 😄

기술세미나 블로그 - VO

마치며

기술 세미나는 어떤 기술에 대해 본인이 무엇을 모르고, 무엇을 아는지를 명확하게 알고 부족한 점을 채워 내 것으로 만들 수 있는 시간입니다. 이를 사람들 앞에서 설명하며 내가 알고 있는 것을 스스로 증명할 수 있는 기회가 되기도 하는 것 같습니다. 앞으로도 기술을 배울 때 다른 사람 앞에서 설명할 수 있을 정도의 공부를 하려고 다짐했습니다.

긴 글 읽어주셔서 감사합니다🍀 (모두 기술 세미나하세요~~!)

Kernel 360 2기의 경우, 오전 10시에 출근하여 오후 7시에 퇴근합니다! 출퇴근 시간에서 살짝 벗어나 있어서 좋은 것 같습니다😄

스크럼

Kernel 360 교육 과정은 팀 프로젝트 위주로 이루어지기 때문에 주로 10시에는 스크럼을 하게 됩니다!

마일스톤을 보며 오늘의 계획을 세우고, 팀원들과 공유해야 할 이야기들을 합니다. 상황에 따라 짧게는 10분에서 길게는 2시간까지도 하는 것 같습니다!

지하의 회의실에서 진행한 스크럼 사진인데요! 멘토링을 받기 위해 질문할 내용들을 정리해야 하는 날이었나 봅니다 ㅎㅎ

팀원들의 진행 상황을 공유하고, 어노테이션에 관한 이야기를 나눈 것 같습니다.

업무 집중 시간

몇 주가 지나면 하루를 함께하는 팀원들과 많이 친해지게 되는데요! 모르는 내용을 옆자리 팀원에게 질문하기도 하고, 개발을 하며 생기는 고민들을 공유하기도 합니다. 그러다 보면 가끔씩은 업무의 흐름이 끊길 때도 있습니다. 이를 방지하기 위해 업무 집중 시간이 있습니다! 회사에서도 업무 집중 시간이 있다고 해요!

이 시간 동안에는 최대한 대화를 삼가고, 본인의 업무에 집중해야 합니다! 하고 싶은 말이 있거나 질문하고 싶은 점이 있어도 온라인으로 소통하거나 조금 기다리는 것이 권장됩니다!

점심 시간 🍤🍱🍝

오전 동안 열심히 개발을 하다 보면 점심 시간이 됩니다!! 교육 장소가 봉은사역에 위치해 있기 때문에 크루들은 코엑스에서 식사를 하기도 하고, 주변 맛집들을 탐방하기도 합니다.

맛집들을 살짝.. 소개하자면!!

1. 한식이 먹고 싶다면..? 솥밥집!!

여긴 가지 솥밥이 정말 맛있습니다 🤤 새벽 두시인데 지금도 먹고 싶네요 . .

2. 항상 사람이 많고 모든 메뉴가 맛있는 쌀국수집!

여긴 항상 인근 직장인 분들로 붐비는 것 같습니다. 저희 식사 시간이 1시에서 2시라 한산할 때 먹을 수가 있어서 좋아요 ㅎㅎ

3. 코엑스 햄버거 맛집!

어떤 크루 분은 여길 일주일에 2~3번도 가시는 것 같더라구요 🍔 느끼하지 않고 산뜻한 수제 버거라 완전 제 취향입니다! 너무 맛있어 보여요. . . 🥹

점심 시간 이야기가 역시 신나네요 😝

특강

적어도 2주에 한 번씩은 아주 좋은 특강들이 있습니다! 이날에는 Git 브랜치 전략과 Github 활용법에 대한 특강을 진행해주셨는데요!

Git 같은 경우 능숙하게 사용할 줄 알아야 프로젝트를 진행함에 무리가 없기 때문에 열심히 들었던 것 같습니다.

현업에서 어떻게 브랜치 관리를 하시는지, 커밋 메시지와 이슈는 어떻게 작성하시는지를 아주 자세하게 설명해주셔서 프로젝트를 진행하며 정말 큰 도움이 되었던 특강이었습니다.

디렉터님께서 아주 인맥이 넓으시기 때문에 정말 대단하신 분들께서 엄청난 특강을 많이 해주시는 것 같습니다! 이것도 Kernel 360의 특장점이라고 생각합니다 😄

개발

다시 자리에 앉아서 열심히 개발을 합니다!! (책상이 조금 더러운데, 평소에는 깨끗합니다..ㅎㅎ)

멘토링

제가 아주 좋아하는 시간입니다!! 멘토링을 하고 나면 몰랐던 점들도 해소되고, 응원에 힘입어 더 열심히 하게 되는 것 같습니다! 한 주 동안 개발하며 마주한 기술적인 어려움과 고민들을 멘토님과 공유하면서 아주 알찬 시간을 보낼 수 있습니다.

멘토님께서 정말 적극적으로 도움을 주려고 하시고, 저희의 수준에 맞게 아주 쉽게 설명을 해주시는 것 같아 항상 큰 도움을 받고 있는 것 같습니다!

꼭 Kernel 360에 들어와서 멘토님들을 만나보세요 .. 😇

마치며

저의 하루 일과를 소개해드린 것 같아요! 정말 시간이 순식간에 흐르기 때문에 항상 열심히 하려고 노력하고 있습니다! 오늘은 평범한 하루의 일과를 소개했지만, 기술 세미나, 프로젝트 발표, 설계 회의 등 재미난 일들이 아주 많습니다! 위에 소개한 일과는 정말 극히 일부에 불과하니까요 ㅎㅎ

Kernel에서의 하루는 힘들기도 하지만 정말 재밌습니다. 다들 잠을 4~7시간 사이로만 주무시는데도 정말 몰입해서 개발을 하고 있는 모습을 보면 저도 덩달아 열심히 하게 됩니다! 또 회의하고 특강을 듣고 멘토링을 받는 그 모든 과정이 재밌기 때문에 모두 들어오셔서 경험해보셨으면 좋겠습니다.

긴 글 읽어주셔서 감사합니다🍀

최종 합격 발표 이후 떨리는 마음으로 봉은사역 패스트 파이브 건물로 향했습니다! 교육 장소는 봉은사역 6번 출구에서 4분 거리에 위치해 있습니다.

패스트파이브 삼성 4호점

깨끗한 신축 건물에 기분이 좋아졌던 기억이 납니다 ㅎㅎ 백엔드와 프론트엔드 크루분들, 디렉터님, 운영 매니저님들께서 한 곳에 모여 오리엔테이션이 진행되었습니다 !

kernel 360의 교육 방식

먼저 디렉터님들께서 kernel 360 교육의 특징을 말씀해주셨습니다. 지난 하반기부터 백엔드 부트캠프를 알아보다가 kernel에 오게 된 이유가 바로 여기 있는데요 .. !!

일단 kernel 360 교육 과정에는 공식적인 강사님이 계시지 않습니다! 오직 디렉터님, 운영 매니저님, 멘토님, 그리고 크루가 있는데요!

"그럼 어떻게 공부를 하지?" 라고 생각하실 수도 있을 것 같습니다!

kernel 360의 교육은 프로젝트, 멘토링, 동료 학습으로 이루어져 있습니다. 크루들은 프로젝트를 통해 함께 학습하며 서로에게 멘토가 되기도, 멘티가 되기도 합니다. 직접 부딪히고 실패를 통해 학습하는 경험은 아주 커다란 효과가 있는데요!

나와 맞지 않는 강의식 교육

"Spring 완전 정복!"이라는 강의를 다 들으면 정말 Spring을 이용해 백엔드 개발을 잘 할 수 있게 될까요? 저의 경우에는 아니었습니다😢

처음 강의를 결제할 때는 “아, 이 44시간 짜리 강의를 다 들으면 난 스프링으로 프로그램을 만들 수 있겠지?!”라는 기대감으로 강의를 수강하기 시작합니다.

그렇지만 이 44시간 짜리 강의는 완강하기도 어려웠고, 다 듣는다고 해서 강의의 내용이 완전하게 내 것이 되기도 어렵습니다.

학습의 주도권이 강사님에게 있고, 강사님이 정해준 목차를 따라가게 됩니다. "지금 내가 필요한 공부는 이거야!" "다음주에는 이걸 만들기 위해서 이런걸 공부하고 싶어!" 이런 마음을 가지고 스스로 공부를 하는 것이 아니라 수동적으로 학습에 임하게 됩니다.

저의 경우에는 하고 싶은 공부와 공부를 통해 얻고 싶은 것이 명확할 때 몰입하여 학습하고, 그 속도도 훨씬 빠릅니다.

다만 강의를 들을 때는 졸리기도 하고, 다음날 공부할 주제는 강사님이 정해주시기 때문에 많은 생각을 하지 않고 수강합니다. 그러다 보니 듣고, 쓰고, 따라 치기 바쁠 때도 많았습니다. 가끔은 지금 하고 있는 공부가 왜 필요한지 파악하지도 못했던 것 같습니다😭

kernel 만의 특별한 교육

kernel 360에서 크루들은 주로 프로젝트, 동료 학습, 멘토링을 통해 성장합니다. 크루들의 성장 속도가 매우 빠른 이유는 여기에 있다고 생각합니다!

학습의 주도권은 그 누구도 아닌 내가 가지고 있기!

kernel 360에서는 어떤 공부가 언제 필요한지를 스스로 깨닫게 됩니다. 공부를 했다면 그 성과가 있어야 할 텐데요! 과정 내내 프로젝트가 진행되기 때문에 학습한 결과를 곧장 적용하여 내 것으로 만들 수 있습니다.

학습 동기가 쉽게 생기기에, 학습 목표가 뚜렷하고 단기간에 빠른 성장을 하게 됩니다.

또한 동료 학습을 통해 서로의 지식들을 흡수하게 됩니다. 하루에 적게는 9시간, 많게는 15시간까지 크루들과 함께 있게 되면 정말 많은 지식을 서로에게 배울 수 있게 되는 것 같습니다!

학습에 대한 동기와 동료 학습이 주는 효과는 정말 매우 컸습니다! 저의 경우 혼자서는 강의로 6개월 동안 할 공부를 kernel에서는 한 달만에 했던 것 같습니다.

디렉터님께서 개발 분야에서 학습이라는 것은 지식을 많이 기억하고 있다기보다 "만들 수 있는가?"에 대한 것이라고 말씀해주셨습니다.

강의를 아무리 열심히 듣고 따라 치고 필기를 하더라도 그 강의의 코드를 혼자 처음부터 끝까지 만들 수 없다면 제대로 학습했다고 말하기는 어렵습니다. 제 것이 아니라 그 강의의 코드이니까요.

그런데 kernel에서는 처음부터 스스로 만듭니다. 정말 많은 어려움을 마주하지만, 디렉터님과 운영 매니저님들, 멘토님들, 그리고 크루분들께 많은 도움을 받아 직접 만들 수 있게 됩니다.

처음에는 방법을 몰라 헤매고 많이 어렵기도 하지만 결국에 만들 줄 알게 되는 경험은 아주 크다고 생각합니다. 강의가 만들어준 것이 아니라 내가 실패하며 직접 만들어낸 것이기 때문이죠.

초중고, 대학까지 강의 위주로 진행되는 주입식 교육에 지치셨다면, 꼭 kernel에서 공부해보셨으면 좋겠습니다! ㅎㅎ

Ice Breaking 시간

여러분들의 MBTI는 무엇인가요? 앞글자만 밝히자면 저는 E입니다.. ㅎㅎ 그런데 혼자 공부하는 몇개월동안 정말 낯도 많이 가리고 점점 I가 되어 가는 느낌이었습니다 🤣 처음 보는 사람들과 대화하는 것이 역시 편하지는 않은데요.. !

Kernel 360에서는 이러한 크루들의 걱정을 미리 알고 있었던 것 같습니다! 개발 부트캠프의 아이스 브레이킹에서는 무엇을 할까요?

저는 딱딱한 자기소개를 하고 자바를 어디까지 아는지.. Spring은 쓸 줄 아는지.. 이런 이야기가 오가는 어색한 담소 시간일거라고 생각했습니다.ㅎㅎ

그런데 전혀 아니었습니다! 무려 젓가락으로 높이 높이 탑 쌓기 게임을 했습니다🙄

어색함도 잠시, 모든 크루들이 열심히 힘을 모아 젓가락 탑을 쌓기 시작했습니다. 이런저런 전략을 고민하며 고무줄로 나무 젓가락을 엮어 높은 탑을 만들었습니다!

정말 열심히 만들고 있네요! ㅎㅎ 놀랍게도 저희 팀이 1등을 했습니다!! 역시 언변 능력은 아주 중요한 것 같습니다..

탑을 만들고 돌아가며 탑에 대한 소개를 했는데, 저희 팀원분이 정말 말씀을 잘해주셔서 1등을 했던 것 같습니다. 😄

정말 특별한 Kernel 360 만의 아이스 브레이킹 시간이었던 것 같습니다!

마치며

돌아오는 길에는 이렇게 예쁜 삼성동의 하늘을 볼 수 있었습니다. 처음 모든 분들을 뵙고 인사하는 자리이기도 했기 때문에 많이 긴장이 되었는지 무지 피곤하더라고요 ㅎㅎ 그렇지만 아주 좋은 시작의 기운을 받았던 것 같습니다! 앞으로의 6개월을 알차게 채워나가보려고 합니다.

긴 글 읽어주셔서 감사합니다 🍀

• command 이용해 사용하는 것을 추천

https://daunje0.tistory.com/6

github의 wiki나 다양한 기능을 활용하자!

코드리뷰

• 코드리뷰를 요청한 개발자가 미처 발견하지 못한 버그가 숨어있는 경우는 분쟁의 소지가 없음

• 더 좋은 코드에 대해 논의할 때는 조심스러운 상황이 발생하기도 함

• "더 좋은 코드"가 개발자간에 다를 수 있기 때문

• 코드리뷰의 유형

  • 질의응답
  • 칭찬 ^^ 선칭찬 후요구
  • 이해한 내용 확인하기

• 코드리뷰 요청자는 작업 내용을 최대한 작게 가져간다

• Comment: 버그가 있는 코드는 아니지만 가급적 수정해줬으면 좋겠다는 의도 전달

• Approve: 코멘트는 전달하지만 문제가 있는 코드는 아니므로 수용 여부는 개발자가 결정

• Request Changes: 반드시 수정해야 하는 코멘트를 전달(버그를 유발하는 코드)

  • 거의 안씀

브랜치 관리 전략

• git에서 브랜치는 개발자간의 독립적인 공간을 제공
• 브랜치 명만 보고도 해당 작업이 어떤 작업인지 유추 가능
• 원격에 브랜치가 쌓이는 것은 좋지 않다. merge 이후 삭제?

GitFlow

master branch는 언제든지 문제없이 빌드되어야 하고 배포될 수 있는 고결한 상태를 유지한다.

새로운 배포

• master -> develop -> release

• develop branch에는 여러 feature branch가 모인다. 버그 발생, 빌드 안됨 등이 발생 가능하다. 런타임 동안 알 수 있기 때문에 release에서 QA가 진행되며 바로 바로 수정하고 commit이 쌓일 것이다.

• 작업이 완료되면 master branch에 올라간다.

branch 종류

• feature 기능개발을 위해 develop으로부터 생성하는 브랜치
• develop 완료된 feature 브랜치들이 머지되는 브랜치, 배포 간격 사이에 추가 기능들이 머지되어 있음
• hotfix 이미 배포되어 있는 상태에서 급히 수정이 필요한 버그가 있을 경우 master로부터 생성되는 브랜치, 수정 이후 master와 develop으로 머지
• release 배포 시점이 다가오면 develop으로부터 생성

정기배포가 있는 환경에 적합하며 수시배포 환경에선 사용되는 브랜치가 많음

실무에서 개발 시 작업 흐름

이슈 관리 도구(jira)

• 머지된 기능은 테스트서버에 배포되어 테스트 진행

• 테스트 완료 후 프로덕션 수준까지 배포가 되면 이슈관리도구의 티켓 종료

• Task > Sub Task > 건별로 PR이 갈 수가 있도록

• 요령이 없이 작게 올리는 것의 폐해

  • "작업 단위"를 작게 쪼갠다는 단위

  • 작업을 완료하지 않고 중간에 올리라는 말이 아니다. "이거 아직 안되서 그래요." 이런 Comment가 오고 간다면 작업 단위를 잘못 나눈 것이다.

1. CI(지속적인 통합) 관점: 잘게 나누고 master에 merge되고 배포되는 것
2. 현실적인 방안 master에서 중간 branch를 하나 딴다. 거기서 개발자들이 브랜치를 각각 또 판다. feature branch에서 중간 branch에 merge한 이후 master로 들어갈 때는 큰 commit이 발생.

feature 브랜치

• feature/configure-json
• 개인당 하나씩 브랜치를 따라.
• merge되면 사라지는 branch 이름보다는 commit 메시지가 더 중요하지 않을까?

commit 메시지와 merge 전략

https://meetup.nhncloud.com/posts/122

• 시간이 지난 후 해당 코드변경이 왜 발생했는지를 나타내는 중요한 메시지
• 어떻게, 무엇에 대한 커밋인지보다는 왜 발생한 커밋인지를 적는게 중요

• 작업 완료 이후 브랜치를 머지할때 3가지 방식 존재
• merge: feature 브랜치에서 작업한 커밋 히스토리가 그대로 main 브랜치에 포함됨

1. 일반 Merge

2. Squash Merge

• feature 브랜치에서 작업한 내용을 하나의 커밋으로 합침.
• 새로운 커밋 메시지 필요
• Issue Id도 여기서 넣으면 된다.
• Squash Merge를 할 때 커밋 메시지를 제대로 작성하면 매번 커밋할 때마다 메시지 고민 하지 않아도 된다.

• 퉁쳐질 때 커밋 메시지만 잘 쓰면 됨
• 일반 Merge를 하면 처음부터 커밋 메시지에 신경을 많이 써야 한다. Main 브랜치에 들어가니까!

3. Rebase Merge

• main 브랜치에 머지 시 각 커밋들이 재배치됨
• 좋은데, 충돌나기 쉬운 방법

테스트용 브랜치

• 동시에 QA
• feature -> test
• feature -> master

Git 명령어

Git pull

다른 팀원이 Pull Request, Merge 완료 -> pull

git pull의 동작 방식

• Fetch: 원격 저장소의 최신 변경 사항을 로컬 저장소로 가져옵니다.
• Merge: 가져온 변경 사항을 현재 로컬 브랜치에 병합합니다.

코드가 지워질 수 있는 경우

git pull은 단순히 원격 저장소의 변경 사항을 로컬로 가져와 병합하는 과정이기 때문에 직접적으로 코드를 삭제하지 않는다. 하지만 다음과 같은 경우 충돌이 발생할 수 있다.

• 동일한 파일의 동일한 부분을 수정한 경우: 로컬과 원격 저장소에서 동일한 파일의 동일한 부분을 수정한 경우 충돌이 발생한다. 이 경우 Git은 자동으로 병합할 수 없기 때문에 수동으로 충돌을 해결해야 한다.
• 삭제된 파일을 수정한 경우: 원격 저장소에서 삭제된 파일을 로컬에서 수정한 경우에도 충돌이 발생할 수 있다.

Git Fetch

❗ fetch 와 pull 의 차이점

pull 을 실행하면, 원격 저장소의 내용을 가져와 자동으로 병합 작업을 실행하게 된다. 그러나 단순히 원격 저장소의 내용을 확인만 하고 로컬 데이터와 병합은 하고 싶지 않은 경우에는 fetch 명령어를 사용하면 된다.

fetch 를 실행하면, 원격 저장소의 최신 이력을 확인할 수 있다. 이 때 가져온 최신 커밋 이력은 이름 없는 브랜치로 로컬에 가져오게 된다.

다른 작업자들의 작업물을 바로 내 로컬에 반영하려면 fetch는 잊고 pull만 하면 된다(fetch + 내 파일에 반영이 pull 이므로)

Web 이란?

(World Wide Web, WWW, W3) 인터넷에 연결된 컴퓨터를 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간을 말합니다. Web은 크게 세 가지로 구성됩니다. 첫 번째, URI입니다. URI는 리소스 식별자로서 특정 사이트, 특정 쇼핑 목록, 동영상 목록 등 웹 상의 모든 정보에 접근할 수 있는 주소입니다. 특정 리소스에 대해서는 유니크한 주소가 한 개만 존재합니다. 두 번째는 HTML입니다. 이는 XML을 바탕으로한 범용 문서 포맷입니다. 서버에 특정 리소스를 요청하게 되면 HTML로 구성된 문자열 형태가 내려오게 되며 Chrome, Safari, Explorer에서 사용자가 알아보기 쉬운 형태로 표현해줍니다. 세 번째로 HTTP입니다. 이는 어플리케이션을 컨트롤하는 프로토콜입니다. 프로토콜이란, 약속입니다. 데이터를 주고 받을 때 서로 약속한 형태를 프로토콜이라고 합니다. GET, POST, PUT, DELETE 등의 여러 Method가 존재합니다.

HTTP란?

HTTP란 Web에서 데이터를 주고 받는 프로토콜(약속)입니다. 실제로는 HTML, XML, JSON, Image, Voice, Video, Javascript, PDF 등 다양한 컴퓨터에서 다룰 수 있는 것은 모두 전송할 수 있습니다. HTTP는 TCP를 기반으로 한 REST의 특징을 모두 구현하고 있는 Web 기반의 프로토콜입니다.

• 특정한 데이터를 상대방에게 보내는 행위를 통신이라고 합니다.

통신을 간략하게 설명

데이터를 요청하는 쪽에서 어떠한 데이터를 받고 싶다는 요청 메시지를 작성을 합니다. 이는 주소 형태일 수도 있고, 메시지 바디가 채워져 있을 수도 있습니다. 서버의 HTTP 통신을 이용하여 특정 데이터에 대한 요청 메시지를 전송합니다. 이때 어디로 요청을 하겠다는 URI가 필요합니다. 서버에서는 항상 리슨하고 있다가 요청 메시지를 수신합니다. 이를 해석하고 애플리케이션을 할당하여 로직을 통해 HTML, JSON 형태의 데이터로 응답 메시지를 송신합니다. 클라이언트는 응답 메시지를 수신하고 해석하여 브라우저로 데이터를 표시하고 처리합니다.

• 멱등성 동일한 연산을 여러 번 수행해도 결과가 달라지지 않는 성질

• 안정성 호출해도 리소스가 변경되지 않는 성질 GET 메서드는 단순히 데이터를 조회하는 기능을 수행하기 때문에 리소스를 변경 및 수정하지 않으니 안전한 HTTP 메서드이다. 반면에 POST PUT PATCH DELETE와 같은 메서드들은 호출할 경우 데이터에 변경이 발생하거나, 서버에서 삭제되기 때문에 안전하지 않는 HTTP 메서드라고 볼 수 있다.

GET 메서드

리소스를 취득할 때 사용하는 HTTP 메서드입니다. (R) 멱등성, 안정성을 보장합니다. URI의 주소에 대해서 Path Variable(ex. /naver.com/mail/)을 가질 수 있으며 Query Parameter(ex. ?name='')를 통해서 조작할 수 있습니다. http 바디에 데이터를 실을 수 없습니다. GET은 리소스를 취득할 때 쓰고 데이터 바디를 쓰지 않기로 약속했습니다.

POST 메서드

리소스를 생성하고 추가할 때 사용하는 HTTP 메서드입니다. (C) 요청을 할 때마다 서버에 새로운 데이터가 생기기 때문에 멱등하지 않습니다. 서버에 데이터를 요청할 때마다 서버의 데이터 상태가 바뀌기 때문에 안정성을 가지지 않습니다. 주소에 Path Variable을 가질 수 있습니다. Query Parameter의 용도는 특정 리소스를 찾기 위해 필터를 걸 때 사용을 하는 것이기 때문에 POST 메서드에서는 사용하지 않습니다. HTTP Data Body에 어떤 리소스를 생성할 것인지 작성할 수 있습니다.

PUT 메서드

리소스를 갱신하거나 생성할 때 사용합니다. (C/U) 데이터가 없으면 생성하고 있다면 갱신합니다. 멱등하지만 안정성은 없습니다. 요청을 할 때마다 리소스를 계속해서 변경하기 때문입니다. Path Variable을 가지며 Query Parameter는 사용하지 않습니다. Data Body는 가집니다.

DELETE 메서드

리소스를 삭제할 때 사용합니다. (D) 멱등하지만 안정성은 없습니다. Path Variable을 가지며 Query Parameter를 사용할 수 있씁니다. Data Body는 사용하지 않습니다.

HTTP 상태 코드

클라이언트가 서버에 요청을 했을 때 응답에 대한 코드입니다.

• 100번대: 처리가 계속되고 있는 상태입니다. 클라이언트는 요청을 계속 하거나 서버의 지시에 따라서 재요청합니다.
• 200번대: 요청이 성공한 상태입니다.
  • PUT 메서드의 상태 코드
• 200: 데이터가 수정됨 201: 데이터가 생성됨
• 300번대: 다른 리소스로 리다이렉트합니다. 자동으로 Response의 새로운 주소(리소스)로 다시 요청합니다.
• 400번대: 클라이언트의 요청에 에러가 있는 상태입니다. 재전송을 하여도 에러가 해결되지 않습니다.
• 500번대: 서버 처리 중 에러가 발생한 상태입니다. 재전송 시 에러가 해결될 수도 있습니다.

REST API 개론

REST란?

네트워크 아키텍처 원리 중 하나입니다.

1. Client, Server 클라이언트와 서버가 독립적으로 분리되어져 있는 상태여야 합니다. 떨어져 있는 상태에서 서로의 자원의 상태를 주고받습니다.

2. Stateless 요청에 대해서 클라이언트의 상태를 서버에 저장하지 않습니다.

3. 캐시 클라이언트는 서버의 응답을 캐시할 수 있어야 합니다. 클라이언트가 캐시를 통해서 응답을 재사용할 수 있어야 하며, 이를 통해서 서버의 부하를 낮춥니다.

4. 계층화 서버와 클라이언트 사이에 방화벽, 게이트웨이, Proxy 등 다계층 형태를 구성할 수 있어야 하며, 확장할 수 있어야 합니다.

5. 인터페이스 일관성 아키텍처를 단순화시키고 작은 단위로 분리하여서, 클라이언트, 서버가 독립적으로 개선될 수 있어야 합니다.

• 자원 식별 웹 기반의 REST에서는 URI를 사용하여 리소스에 접근합니다.

• 메시지를 통한 리소스 조작 Web에서는 다양한 방식으로 데이터를 전송할 수 있습니다. 그 중에는 HTML, XML, JSON, TEXT 등 다양한 방법이 있습니다. 이 중에서 리소스의 타입을 알려주기 위해서 header 부분에 content-type(헤더)를 통해서 어떠한 타입인지를 지정할 수 있습니다.

• 자기 서술적 메시지 요청하는 데이터가 어떻게 처리되어야 하는지 충분한 데이터를 포함할 수 있어야 합니다. HTTP 기반의 REST 에서는 HTTP Method와 Header의 정보로 이를 표현할 수 있습니다.

• 애플리케이션 상태에 대한 엔진으로서 하이퍼미디어 REST API를 개발할 때에도 단순히 Client 요청에 대한 데이터만 내리는 것이 아닌 관련된 리소스에 대한 Link 정보까지 같이 포함되어야 합니다.

6. Code On Demand

URI란?

Uniform Resource Identifier의 약자로 인터넷에서 특정 자원을 나타내는 주소값이며 해당 값은 유일합니다.

URL이란?

Uniform Resource Loader의 약자로 인터넷 상에서의 자원, 특정 파일이 어디에 위치하는지 식별하는 주소입니다.

URI와 URL의 차이는?

URL은 URI의 하위 개념입니다. URL은 리소스의 위치를 지정하는 반면, URI는 리소스를 식별합니다. URL은 실제 위치를 가리키는 역할을 하며 URI는 리소스를 찾는 것에 중점을 둡니다.

URI = 식별자, URL = 식별자 + 위치

• naver.com은 URI입니다. 리소스의 이름만 나타내기 때문입니다.
• https://naver.com은 URL입니다. 이름과 더불어, 어떻게 도달할 수 있는지 위치까지 함께 나타내기 때문입니다. (프로토콜 'https' 포함)

URL은 어떻게 위치를 찾고 도달할 수 있는지까지 포함되어야 하기 때문에 URL은 프로토콜 + 이름(또는 번호)의 형태여야 합니다.

• Scheme: 리소스에 접근하는 데 사용할 프로토콜. 웹에서는 http 또는 https를 사용
• Host: 접근할 대상(서버)의 호스트 명
• Path: 접근할 대상(서버)의 경로에 대한 상세 정보

JPA(Java Persistence API)란?

ORM을 위한 Java 표준 API

• ORM: 객체, 관계형 데이터베이스를 맵핑
• 인터페이스 집합(JDBC)

JPA 구현체: HIBRNATE, OpenJpa, EclipseLink, DataNucleus, ...

Persistence(영속성): 애플리케이션 종료 후에도 객체(데이터)가 유지되는 것

ORM(Object/Relation Mapping) Framework - HIBERNATE

• JPA API 구현
• 객체와 DB 테이블 간의 연결을 해주는 프레임워크
• 객체 모델(object model)과 관계형 모델(relational model)의 차이를 해소

• 객체는 참조로 연결된 형태

• RDB는 고정되어 있는 2차원 테이블

• 이 두 모델 간의 변환을 HIBERNATE(Orm Framework)이다.

객체 모델과 관계형 모델의 비교

JPA의 개요와 설정 SQL Mapper(MyBatis) vs ORM framework(HIBERNATE)

1. SQL Mapper DB 중심 개발

• SQL 직접 작성
• 데이터 저장할 클래스 작성
• MyBatis
• 큰 회사들이 많다.

DB에 변경 사항 발생 시 고쳐야 할 것이 많다.

2. ORM framework(HIBERNATE)

• 자바 클래스 작성

  • 변경 사항 발생 시 Entity만 변경하면 HIBERNATE ORM이 자동 반영

• HIBERNATE ORM이 테이블 자동 생성

  • SQL문 자동 생성
  • 유지보수에 유리
  • 복잡한 일처리, 성능 면에서 문제

둘 다 장단점이 존재한다. 오래된 기업들은 RDB가 중요하고 실무에서 복잡한 일처리하기 위해서는 JPA로 하기 어렵다. DB 중심 개발을 바꾸기가 쉽지 않다.

Spring Data 저장소 종류가 달라도 일관된 데이터 처리 방법을 제공

엔터티 매니저 팩토리와 엔터티 메니저

EntityManager와 EntityManagerFactory

EntityManagerFactory: EntityManager를 생성. 애플리케이션에 하나 EntityManager: Entity를 관리하는 객체. Entity를 저장 관리. 사용자당 하나. 공유 불가

사용자는 직접 DB에 명령내리는 대신, EntityManager로만 작업

저장은 persist(), 조회는 find(), 삭제는 remove(), 변경은 Entity의 setter를 이용

Entity 클래스의 작성

Entity 클래스: DB 테이블의 한 행(row)을 정의한 것.

• 클래스에 @Entity를 붙인다.
• 키(PK)로 사용할 속성에 @Id를 붙인다.

*** 순서는 보장되지 않는다.

database에서는 대소문자 구분하지 않는다.

Entity 클래스의 작성을 위한 애너테이션

@Generated 자동 번호 생성을 적용할 속성에 사용

GenerationType.TABLE GenerationType.SEQUENCE GenerationType.IDENTITY GenerationType.AUTO

EntityTransaction

EntityManager entityManager = entityManagerFactory.createEntityManager();
EntityTransaction tx = entityManager.getTransaction(); //트랜잭션 얻기

User user = new User(); // User 객체를 생성하고 초기화
user.setId("aaa");
user.setPassword("1234");

tx.begin(); // 트랜잭션을 시작
entityManager.persist(user); // User 객체를 저장
tx.commit(); // 트랜잭션을 종료(작업 내용을 DB에 반영)

Hibernate가 SQL을 자동 생성한다.

PreparedStatement

1. 성능
2. 보안

Transaction이란? 더 이상 나눌 수 없는 작업의 단위

• 모두 성공하지 않으면 실패
• 하나 이상의 작업을 묶은 것이 Transaction이다.

Commit과 Rollback

1. 커밋: 작업 내용을 DB에 영구적으로 저장
2. 롤백: 최근 변경사항을 취소(마지막 커밋으로 복귀)

PersistenceContext = PC = Entity 저장공간

*** AC = Application Context = 빈(bean) 저장소

• entity를 저장하는 공간
• EntityManager마다 PersistenceContext를 하나씩 가지고 있다.

비영속 상태와 영속 상태

• 처음 entity를 생성 시 비영속 상태이다.

  • PersistenctContext에 저장되지 않았다.

• em.persist(entity) : 비영속 상태의 entity가 PersistenceContext에 저장되고 엔터티를 영속 상태로 바꾸고, SQL 저장소에 INSERT문을 저장한다.

• em.remove(entity) : Entity Manager가 PersistenceContext에서 해당 Entity를 제거

• em.flush() : db에 sql이 전송된다. SQL 저장소에 누적된 SQL문을 DB로 전달. tx.rollback() 가능

PersistenceContext의 캐시

• 실제 Entity가 저장되는 공간(Map). Entity의 @Id컬럼을 Key로 사용
• key와 value
• em.find(User.class, "a") : 캐시에서 Entity를 먼저 조회. 캐시에 없을 때만 DB에서 조회한다.
• em.clear()를 통해 캐시를 비운다.

redirect와 forward의 처리 과정 비교

• 2번 요청, 2번 응답

• 요청을 받아서 (request 객체) 다른 프로그램으로 그대로 전달
• 1번 요청, 1번 응답

RedirectView

HTTP 요청과 요청 방법

1. URL 직접 입력으로 요청(GET)
2. 링크 <a>로 요청(GET)
3. 폼 <form>으로 요청(GET, POST)
4. redirect: 다른 URL로 이동(GET). 자동 재요청. 브라우저 URL 변경됨.
5. forward: 요청(GET, POST)을 다른 URL로 전달. 브라우저 URL 변경 안됨.

원격 프로그램의 실행

웹 브라우저 + WAS(톰캣) -> 원격 프로그램의 실행

1. 프로그램 등록 @Controller 을 통해 프로그램 등록
2. URL과 프로그램을 연결 이 URL을 연결했을 때 실행될 메서드를 연결해준다.

@Controller // 1. 프로그램 등록
public class Hello {
    @RequestMapping("/hello") // 2. URL과 main()을 연결
    public void main() {
        System.out.println("Hello");
    }
}

원래 static이 없다면 객체를 생성해야 한다. 다만, @Controller 어노테이션이 붙은 프로그램은 스프링이 자동으로 객체를 생성해주기 때문에 인스턴스 메서드(static이 안 붙은 메서드)가 URL이 연결되어 다른 컴퓨터에서 호출될 수 있다.

** 인텔리제이 단축키 패키지를 선택한 상태에서 Command + N 해당 패키지에 파일 추가

** github

• git add .: 현재 디렉토리와 그 하위 디렉토리에서 변경된 파일들만 스테이징한다. 새로운 파일과 변경된 파일을 스테이징하지만, 이미 삭제된 파일은 스테이징하지 않는다.
• git add -A: 리포지토리 전체에서 모든 변경 사항을 스테이징한다. 새로운 파일, 변경될 파일뿐만 아니라 삭제된 파일도 스테이징한다.

따라서, 프로젝트 전체에서 변경 사항을 커밋하려는 경우 'git add -A'를 사용하는 것이 더 안전하며, 특정 디렉토리에서만 작업하는 경우 'git add .'를 사용할 수 있다.

클라이언트와 서버

클라이언트와 서버는 역할로 구분한다.

서버의 종류

• Email을 서비스하면 Email Server
• Web을 서비스하면 Web Server

브라우저를 통해 사용하는 서비스들은 Web Server를 통해 이루어진다.

한 대의 컴퓨터에 서버 프로그램이 여러 개 설치되어 있다면 같은 IP 내에 서비스가 존재하기 때문에 포트가 필요하다. 서버 프로그램은 특정 포트와 연결되어 있다. Email Server는 25번 포트, File Server는 22번 포트, Web Server는 80번 포트를 기본적으로 사용한다.

WAS란?

Web Application을 서비스하는 서버이다.

• Application = Server

클라이언트가 애플리케이션을 사용할 수 있게 해준다. 서버에 있는 프로그램을 클라이언트에게 서비스해주는 프로그램이다.

HTTP 요청과 응답

1. DNS에 문의

사용자는 브라우저에 URL을 입력하게 된다. 이때 DNS 서버가 도메인 이름(fastcampus.co.kr)이 IP 주소(111.222.33.44)를 알려준다. 해당 IP 주소가 있는 웹 서버에 요청이 간다.

2. TCP 연결(3-way handshake)

• SYN / ACK + SYN / ACK
• 연결을 하면 두개의 Stream이 생긴다. I/O Stream

3. HTTP 요청

4. HTTP 응답

• 헤더 + 바디(html)

5. 응답을 수신하고 연결을 종료 (재사용)

원격 프로그램에 데이터 전달하기

HttpServletRequest

1. HttpServletRequest

• 클래스
• http 요청 정보를 제공
• URL로 블라우저에서 클라이언트가 요청을 한다. Tomcat이 요청 정보를 받아서 HttpServletRequest 객체를 생성한다. 이 객체에 요청 정보를 받는 것이다.
• 메서드의 매개 변수에 HttpServletRequest request를 적어주면 메서드 안에서 해당 객체의 메서드를 사용할 수가 있다.

2. HttpServletRequest의 메서드

• getScheme()
• getServerName()
• getServerPort()
• getContextPath(): Web Application 시작 루트 경로이다. 루트로 설정 시 없을 수도 있다.
• getRequestURI(): 서버 Name과 Port를 제외한 부분
• getQueryString(): ?부터 끝까지. 원격 프로그램에 data를 전달할 때 사용한다. &는 구분자이다. 값의 name과 value를 구분자(&)를 통해 원격 프로그램에 전달한다.
• getRequestURL()

위의 메서드를 통해 원하는 정보를 얻을 수 있다. URL을 잘라서 원하는 것을 얻을 필요가 없다.

String year = request.getParameter("year");
String month = request.getParameter("month");
String day = request.getParameter("day");

// Enumeration은 Iterator의 old version이다.
Enueration enum = request.getParameterNames();
Map paramMap = request.getParameterMap();

// 같은 name이 많을 때 배열로 반환한다. 
// 만약 getParameter()를 사용 시 첫 번째 value만 반환된다.
/* ex) 체크박스의 경우 
hobby=computer&hobby=drawing&hobby=music 
이런 식으로 들어오게 된다. */

String[] yearArr = request.getParameterValues("year");

GET과 POST의 차이점

GET

입력한 내용이 query string으로 URL뒤에 붙는다.

• 서버로부터 리소스를 얻어오기(=읽기)
• 요청에 body가 없다.
• URL에 전송 데이터가 있다.
• Query String을 통해 데이터를 전달(소용량)
• URL에 데이터 노출되므로 보안에 취약
• 데이터 공유에 유리 ex. 검색 엔진에서 검색단어 전송에 이용

POST

URL 뒤에 query string이 붙지 않고 별도로 전송이 된다.

• 글 쓰기
• 전송할 데이터가 body에 있어서 URL에 붙이지 않는다.
• 서버에 데이터를 올리기 위해 설계됨.
• 전송 데이터 크기의 제한이 없음(대용량)
• 보안에 유리, 데이터 공유에는 불리 ex. 게시판에 글쓰기, 로그인, 회원가입

HTTP 요청 방법

1. URL 직접 입력 - GET
2. <a> - GET
3. <form> - GET이 default, POST

HTTP 요청과 응답

프로토콜이란?

서로 간의 통신을 위한 규칙 주고 받을 데이터에 대한 형식을 정의한 것

HTTP

Hyper Text Transfer Protocol 단순하고 읽기 쉽다. 텍스트 기반의 프로토콜

클라이언트가 브라우저에 URL을 입력하면 HTTP 요청 메시지를 만들어 서버에 요청 메시지를 보낸다. 서버는 이를 보고 HTTP 응답 메시지를 만들어 클라이언트에게 보여준다.

상태를 유지하지 않는다(stateless) 클라이언트 정보를 저장하지 않는다. 서버에 부담이 없어진다.

확장 가능하다. 커스텀 헤더 추가 가능

상태 코드

• 1XX: Informational(정보 제공) 임시 응답으로 현재 클라이언트의 요청까지는 처리되었으니 계속 진행하라는 의미입니다. HTTP 1.1 버전부터 추가되었습니다.
• 2XX: Success(성공) 클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미입니다.
• 3XX: Redirection(리다이렉션) 완전한 처리를 위해서 추가 동작이 필요한 경우입니다. 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도하라는 의미입니다.
• 4XX: Client Error(클라이언트 에러) 없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미합니다.
• 5XX: Server Error(서버 에러) 서버 사정으로 메시지 처리에 문제가 발생한 경우입니다. 서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생하는 경우를 의미합니다.

텍스트 파일과 바이너리 파일

• 바이너리 파일: 문자와 숫자가 저장되어 있는 파일
• 텍스트 파일: 문자만 있는 저장되어 있는 파일

원격 프로그램으로 응답하기

정적 리소스와 동적 리소스

• 정적 리소스 메서드가 호출 될 때마다 다른 결과가 반환된다.

static 폴더의 index.html (정적 리소스)

src/main/resources/static 폴더에 위치한 파일들은 정적 리소스로 취급된다. 이 파일들은 서버 측 처리 없이 그대로 클라이언트에 제공된다. 따라서 localhost:8080/index.html로 직접 접근할 수 있다.

templates 폴더의 index2.html (동적 리소스):

src/main/resources/templates 폴더에 위치한 파일들은 동적 리소스로 취급된다. 이 파일들은 주로 템플릿 엔진(예: Thymeleaf)을 통해 처리되어야 한다. 직접 URL로 접근할 수 없으며, 컨트롤러를 통해 접근해야 한다.

templates 폴더의 index2.html에 접근하려면 컨트롤러를 만들어야 한다.

@Controller
public class HomeController {
    @GetMapping("/index2")
    public String showIndex2() {
        return "index2";
    }
}

이후 localhost:8080/index2로 접근하면 index2.html이 보일 것입니다.

만약, localhost:8080/index2.html로 접근하면 error 페이지가 나온다.

Spring Boot는 templates 폴더의 파일을 직접 URL로 접근할 수 있는 정적 리소스로 취급하지 않는다. 따라서 해당 URL에 맞는 컨트롤러 매핑이 없으면 404 에러가 발생하고, 기본 에러 페이지가 표시된다.

요약

static 폴더

• 정적 파일 직접 제공 (CSS, JavaScript, 이미지 등)

templates 폴더

• 동적 콘텐츠를 위한 템플릿 파일 (컨트롤러를 통해 접근)

이러한 구조는 보안과 유연성을 위해 설계되었다. 동적 콘텐츠는 서버 측 로직을 통해 제어되어야 하므로, 직접 접근을 제한하고 컨트롤러를 통해 접근하도록 한다.

HttpServletResponse로 응답하기

Tomcat이 response 객체를 생성해서 준다. 요청 시 사용할 수 있는 객체, 응답에 사용할 수 있는 객체가 있다.

응답에 필요한 출력 스트림을 담아서 준다.

response.getWriter()

• 출력 스트림 얻어온다.
• 응답을 얻을 수 있다.

response.setStatus(200);
response.setContentType("text/html");

PrintWriter out = response.getWriter();
out.println("<html>");
out.println("<head></head>");
out.println("<body>Monday</body>);
out.println("</html>");
out.close();

톰캣은 응답의 헤더를 기본적으로 만들어준다. 헤더는 변경과 확장이 가능하다.

HttpServletResponse의 메서드

코드의 분리

1. 관심사
2. 변하는 것과 변하지 않는 것
3. 중복 코드 - 별도의 메서드로 만들어 제거해야 함.

OOP - 변경에 대비

객체 지향 설계 5대 원칙

1. 단일 책임 원칙(SRP) 하나의 메서드는 하나의 책임(Concern=관심사=작업)만 가진다.
2. 개방 폐쇄 원칙(OCP) 상속 Open, 변경 Closed
3. 리스코프 치환 원칙(LSP)
4. 인터페이스 분리 원칙(ISP)
5. 의존관계 역전 원칙(DIP)

• 코드가 너무 구체적이면 변경에 불리
• "추상화" 통해 변경에 유리

Spring의 Reflection API

@Controller
public void date(@HttpservletRequest request) {

    request.getParameter("year");
    request.getParameter("month");
    request.getParameter("day");
}

위의 코드를 아래처럼 바꿀 수 있다.

@Controller
public void date(int year, int month, int day) {
}

각 매개변수에는 @RequestParam이 생략되어 있다.

DispatcherServlet

1. 입력 & 변환

• request.getParameter()
• String -> int

2. 모델 생성

• Controller 메서드에 Model을 선언하면 DispatcherServlet이 모델 객체를 생성해서 넘겨줌. (객체의 주소를 줌)
• 뷰에 Model이 넘어오면 이를 사용할 수 있다.
• 작업 결과를 보여줄 View의 이름을 반환
• 매개변수가 참조형일 경우 원본 객체를 수정할 수가 있다.

컨트롤러 메서드의 반환타입

1. String 뷰 이름을 반환

   @GetMapping("/getYoil")
   pubic String main(int year, int month, int day) {
   
    return "yoil" // resources/templates/yoil.html
   }

2. void 맵핑된 url의 끝단어가 뷰 이름

@GetMapping("/yoil") //resources/templates/yoil.html
public void main(int year, int month, int day) {
}

• JSP 방식

@RestContoller와 @Controller의 차이점은?

@RestController 어노테이션은 메소드의 반환값을 HTTP 응답 본문으로 직접 전송한다. Thymeleaf 템플릿을 사용하려면 @Controller 어노테이션을 사용해야 한다.

@RequestParam과 @ModelAttribute

@ModelAttribute

• 적용 대상을 Model의 속성으로 자동 추가해준다.
• 반환 타입 또는 컨트롤러 메서드의 매개변수에 적용 가능
• Controller 메서드 파라미터에서 참조형 앞에 사용할 경우 어노테이션 생략 가능

1. 참조형에만 사용 가능하다. ex. int, char 등 사용 불가하다.

2. 메서드 앞에 사용

   @ModelAttribute("yoil")
    private char getYoil(MyDate myDate) {
        /*** 생략 ***/
        char yoil = '일';
        return yoil;
    }

• 이 메서드의 반환값(yoil)을 "yoil"이라는 이름으로 모델에 자동으로 추가한다.
• 모든 요청 처리 전에 이 메서드가 실행된다. 따라서, char yoil = getYoil(myDate);을 추가할 필요가 없다. 또한, main 메서드가 실행될 때 모델에는 이미 "yoil" 속성이 추가되어 있다.

3. 파라미터 앞에 사용

   @Controller
   public class YoilTeller {
    @RequestMapping("/yoil")
    public String getYoil(@ModelAttribute MyDate myDate, Model model) {
   
        return "yoil";
   }
   

- Spring은 요청 파라미터를 MyDate 객체에 자동으로 바인딩한다.
예) "/yoil?year=2023&month=7&day=20" 요청이 오면, myDate 객체의 각 필드에 값이 설정된다.
- 생략되는 코드 
```java
model.addAttribute("myDate", date);

• Model model 뷰에 전달할 데이터를 담는 객체 *** Model은 스프링이 자동으로 주입하는 객체이므로 @ModelAttribute 어노테이션을 붙일 필요가 없다.

@Controller
public class YoilTeller {
    @RequestMapping("/yoil")
    public String main(@ModelAttribute MyDate date, Model model) throws IOException {

        return "yoil";
    }

    @ModelAttribute("yoil")
    private char getYoil(MyDate date) {
        Calendar cal = Calendar.getInstance(); // 현재 날짜와 시간을 갖는 cal
        cal.clear(); // cal의 모든 필드를 초기화
        cal.set(date.getYear(), date.getMonth() - 1, date.getDay());

        int dayOfWeek = cal.get(Calendar.DAY_OF_WEEK);
        char yoil = "일월화수목금토".charAt(dayOfWeek - 1);
        return yoil;
    }
}

** 이때, 컨트롤러 메서드의 매개변수가 기본형일 경우 @RequestParam이 생략된 것이며, 참조형일 경우 @ModelAttribute가 생략된 것이다.

WebDataBinder의 역할

@RequestMapping("getYoil")
public String main(@ModelAttribute MyDate date, BindingResult result) {
}

URL -> getYoil?year=2023&month=1&day=2

Map<String, String>

1. 타입 변환

• string -> int

2. 데이터 검증(validator)

MyDate

@RequestParam

• 요청의 파라미터를 연결할 때 매개변수에 붙이는 애너테이션

1. HttpServletRequest

서블릿(Servlet)은 개발자가 HTTP 요청 메시지를 편리하게 사용할 수 있도록 HTTP 메시지를 대신 파싱한다. 이렇게 파싱된 메시지를 HttpServletRequest 객체에 담아서 제공하는 것이다. 즉, HttpServletRequest는 서블릿이 HTTP 요청 메시지를 파싱한 결과를 담은 객체이다. HttpServletRequest를 사용하면 HTTP 요청 메시지를 편리하게 조회할 수 있게 된다.

@RequestMapping("/requestParam")
public void main(HttpServletRequest request) {
    String year = request.getParameter("year");
}

2. Reflection API

@RequestMapping("/requestParam")
public void main(@RequestParam String year) {
}

• request.getParameter() 필요 없어짐.

• 여기서 더해, @RequestParam도 생략하는 것이 좋다.

  • @RequestParam(name="year", required=true)
  • year이 필수값이 된다.

• @RequestParam이 붙었다면 반드시 client에서 year 정보가 넘어와야 한다.

• http://localhost/requestParam

  • 400 Bad Request

• http://localhost/requestParam?year

  • 빈 문자열로 처리되어 값이 넘어온 것으로 본다.

3. WebDataBinder 덕분에 .. @RequestParam도 생략 가능

@RequestMapping("/requestParam")
public void main(String year) {
}

• required = false

  • year이 넘어오지 않아도 null로 처리되며 에러가 발생하지 않는다.

• http://localhost/requestParam

• http://localhost/requestParam?year

브라우저를 통해서 요청받은 값이 실제 서버의 객체에 바인딩 될 때, 중간 역할을 한다.

1. 타입변환
2. 데이터 검증

➡️ 변환 결과나 에러는 BindingResult에 저장

4. WebDataBinder의 타입 변환

@RequestMapping("/requestParam")
public void main(int year) {
}

• http://localhost/requestParam

  • 500 error(server)

  • required=false이기에 client는 잘못한 것이 없다.

  • year = null

  • null을 int로 타입 변환하려고 하니까 error 발생

• http://localhost/requestParam?year

  • 400 error(client)
  • year = ""
  • 빈 문자열은 int로 변환될 수 없다.

@RequestMapping("/requestParam")
public void main(@RequestParam(required=false, defaultValue="1") int year) {
}

• default value를 설정함으로써 사용 가능

로그인 화면 만들기

@RequestMapping, @GetMapping, @PostMapping

• @RequestMapping의 default method는 GET이다.

@Controller
@RequestMapping
public class LoginController {

    @RequestMapping("/login/login", method = RequestMethod.GET)
    public String login(){
        return "login";

}

@Controller
@RequestMapping
public class LoginController {

    @GetMapping("/login/login")
    public String login(){
        return "login";

}

두 코드는 동일하다. URL이 같아도 method가 다르면 서버가 요청을 구별할 수 있다.

만약, 하나의 메서드로 GET, POST를 둘 다 처리하는 경우에는 @RequestMapping으로 사용해야 한다.

@Controller
@RequestMapping
public class LoginController {

    @RequestMapping("/login/login", method = {RequestMethod.GET, RequestMethod.POST})
    public String login(){
        return "login";

}

클래스에 붙이는 @RequestMapping 맵핑될 URL의 공통 부분을 @RequestMapping으로 클래스에 적용

@Controller
@RequestMapping("/login")
public class LoginController {

    @PostMapping("/login")
    public String login(){
        return "login";

}

URL Encoding URL에 포함된 non-ASCII 문자를 문자 코드(16진수) 문자열로 변환

String msg = URLEncoder.encode("id 또는 pwd가 일치하지 않습니다", "utf-8");

Redirect

@GetMapping

return "redirect:/login/login";

url 다시쓰기

• URL을 변경하는 것.
• 주로 URL에 쿼리 스트링을 추가

String msg = "id 또는 pwd가 일치하지 않습니다";
return "redirect:/login/login?msg="+msg;

• queryString으로 다른 정보를 추가
• 이때 한글이 포함되어 있다면 URL 인코딩을 직접 처리
• 브라우저를 통해 입력한 경우 ASCII가 아닌 문자가 포함되어 있다면 수동으로 처리해야 한다.

ThymeLeaf 엔진

1. model

<!DOCTYPE html>
<html lang="en" xmlns:th="http://www.thymeleaf.org">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<h1 th:text="|id=${id}|">asdf</h1>
<h1 th:text="|pwd=${pwd}|">1234</h1>
</body>
</html>

json 이외의 형식이 들어가려면 | |로 감싸주어야 한다.

2. query parameter

   <h1 th:text="${param.msg}"></h1>