ilot의 블로그

[Mybatis] Param 어노테이션 없이 여러 파라미터를 넣을 때 null 오류가 발생하는 경우

ilot — Tue, 16 May 2023 09:29:51 +0900

Mybatis 에서 한 메서드에 여러 파라미터를 넣을 경우, xml sql에서 파라미터를 구분지을 수 있게 @Param 어노테이션을 제공한다.

@Mapper
public interface FooRepository {

    List<BarVO> selectBars(@Param("name") String name, @Param("code") String code);

}

어떤 로컬 PC에서는 @Param을 생략해도 잘 동작하나, 일부 로컬 PC에서는 아래와 같은 에러가 발생한다.

org.mybatis.spring.MyBatisSystemException: null

에러가 발생한 PC에서는 intellij의 build tool을 gradle이 아닌 intellij에서 제공하는 gradle을 사용하고 있었기 때문이었다.

Intellij Settings > Build, Execution, Deployment > Build Tools > Gradle 에서

Build and run using, Run tests using을 Gradle로 바꿔주자.

위 세팅을 Intellij로 바꿔주면, 빌드나 실행속도가 꽤 빨라지나, 가벼운 만큼 일부의 기능만 제공하는 모양이다.

[OOP] 우아한 객체지향 _ 의존성을 이용해 설계 진화시키기

ilot — Sun, 20 Nov 2022 21:31:07 +0900

객체지향 스터디를 준비하던 중, 객체지향의 사실과 오해의 저자이신 조영호 님의 객체지향 세미나를 보게 되었다.

자료

영상 : https://www.youtube.com/watch?v=dJ5C4qRqAgA

slideshare : https://www.slideshare.net/baejjae93/ss-150432699

우아한 객체지향

2019년 6월 우아한 Tech 세미나 우아한 객체지향

www.slideshare.net

코드
- 1단계 : https://github.com/eternity-oop/Woowahan-OO-01-object-reference
- 2단계 : https://github.com/eternity-oop/Woowahan-OO-02-domain-service
- 3단계 : https://github.com/eternity-oop/Woowahan-OO-03-domain-event

의존성이란?

객체 세계에서 협력은 필수적이며, 객체가 협력한다는 것은 객체 간의 의존성이 존재하는 것이다. 의존성이란, 파라미터나 리턴값 또는 지역 변수 등으로 다른 객체를 참조하는 것을 의미한다.

애플리케이션 설계 시 어떤 코드를 어떤 패키지에, 어떤 클래스에 넣을 지 많은 고민을 하게 되는데, 의존성의 경우 변경에 초점을 맞추어야 한다. 즉, 협력 관계에 있는 객체 중 하나가 변경이 되면, 다른 객체가 변경되지 않도록 고려해야 한다.

클래스 의존성

(1) 연관 관계

class A {
  private B b;
}

A와 B 객체 사이에서 요청이 빈번하다면, 의도적으로 연관 관계를 맺어줄 수 있다.

(2) 의존 관계

class A {
  public B method(B b) {
    return new B();
  }
}

(3) 상속 관계

class A extends B {

}

(4) 실체화 관계

class A implements B {

}

패키지 의존성

패키지에 포함된 클래스 사이의 의존성

패키지 의존성

좋은 의존성 관리를 위한 규칙

(1) 양방향 의존성을 피하라

문제

class A {

  private B b;

  public void setA(B b) {
    this.b = b;
    this.b.setA(this);
  }
}

class B {

  private A a;

  public void setA(A a) {
    this.a = a;
  }

}

위처럼 A와 B는 서로 연관 관계가 존재하고, B가 바뀔 때 A도 바뀌고, A가 바뀔 때 B도 바뀌게 된다. 가급적이면 단방향으로 구현하자.

해결책

class A {
  private B b;

  public void setA(B b) {
    this.b = b;
  }
}

class B {
}

(2) 다중성이 적은 방향을 선택하라

문제

class A {
  private Collections<B> bs;
}

class B {
}

Collection을 다루다 발생 우려되는 문제가 많으므로, 일대다보다 다대일을 권장한다.

해결책

class A {
}

class B {
  private A a;
}

(3) 의존성이 필요없다면 제거하라

(4) 패키지 사이의 의존성 사이클을 제거하라

예제 소개

본 예제는 배달의민족 앱에서 장바구니에 있는 메뉴를 주문하는 로직을 단순화한 것이다.

도메인 컨셉

가게 & 메뉴

주문

문제점

손님이 장바구니에 1인 세트를 저장한 상태다. 단, 장바구니의 값은 손님의 로컬 저장소에만 저장된다고 가정한다. 이때 사장님이 1인 세트를 0.5인 세트로 변경한다면? 메뉴가 불일치하는 문제가 발생한다. 이를 위해 주문을 검증하는 로직을 만든다.
주문 검증 로직
- 메뉴의 이름과 주문 항목의 이름 비교
- 옵션 그룹의 이름과 주문 옵션 그룹의 이름 비교
- 옵션의 이름과 주문 옵션의 이름 비교
- 옵션의 가격과 주문 옵션의 가격 비교
- 가게가 영업 중인지 확인
- 최소 주문 금액 이상인지 확인

주문 검증 로직을 토대로 협력 설계하기

관계에는 방향성이 필요하다. 관계의 방향 == 협력의 방향 == 의존성의 방향

설계 개선하기_객체 참조로 인한 문제점

문제

Shop과 Order 사이에 의존성 사이클이 발생한다.

해결1_중간 객체를 이용한 의존성 사이클 끊기

해결2_객체 참조 끊어내기

객체 참조의 단점

도메인이 전부 연결되어 있는 상태라면, JPA 같은 경우 연관된 모든 도메인 값을 DB로부터 가져오므로, lazy loading 이슈가 발생할 수 있다. 따라서, 한 도메인을 읽어올 때 어디까지 읽어와야 하는 지 고민을 해야 한다. 즉, 트랜잭션 경계를 적절히 지정해야 한다.

Primary Key만 가지게 하자

Repository로 탐색해오면 되므로, 약한 결합도를 가지게 된다.

해결3_때로는 절차지향이 낫다

모든 Validation 로직을 각 객체에 넣게 되면, 어떤 Validation 로직이 수행되는 지 헷갈릴 수 있다. Validation 로직 같은 경우 한 눈으로 보는게 유리할 수 있기 때문에, 이런 경우 OrderValidator와 같은 객체를 새로 생성하여, Validation 책임을 위임시킬 수 있다. 이로써 가독성이 좋아질 수 있다.

설계 개선하기_패키지 사이클로 인한 문제점

// 공사중

출처
https://jojoldu.tistory.com/425

[Design Pattern] Factory Method Pattern (팩토리 메서드 패턴)

ilot — Sun, 13 Nov 2022 22:34:04 +0900

팩토리 메서드 패턴 (Factory Method Pattern)

구체적으로 어떤 인스턴스를 만들지는 서브클래스가 정한다.
인스턴스를 생성하는 책임을 구체 클래스가 아닌 인터페이스의 메서드로 감싸게 된다.
다양한 구현체(Product)가 있고, 그 중에서 특정한 구현체를 만들 수 있는 다양한 팩토리(Creator)를 제공할 수 있다.

팩토리 메서드 패턴

장점

기존에 인스턴스 생성 코드를 건드리지 않고 비슷한 류의 인스턴스 생성 코드를 만들 수 있어 OCP를 보장한다. (Creator와 Product의 느슨한 결합)

단점

클래스가 많아진다.

예시 (as-is)

public class Ship {

  private String name;

  private String color;

  private String logo;

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  public String getColor() {
    return color;
  }

  public void setColor(String color) {
    this.color = color;
  }

  public String getLogo() {
    return logo;
  }

  public void setLogo(String logo) {
    this.logo = logo;
  }

  @Override
  public String toString() {
    return "Ship{" +
        "name='" + name + '\'' +
        ", color='" + color + '\'' +
        ", logo='" + logo + '\'' +
        '}';
  }
}

public class ShipFactory {

  public static Ship orderShip(String name, String email) {
    // validate
    if (name == null || name.isBlank()) {
      throw new IllegalArgumentException("배 이름을 지어주세요.");
    }
    if (email == null || email.isBlank()) {
      throw new IllegalArgumentException("연락처를 남겨주세요.");
    }

    prepareFor(name);

    Ship ship = new Ship();
    ship.setName(name);

    // Customizing for specific name
    if (name.equalsIgnoreCase("whiteship")) {
      ship.setLogo("\uD83D\uDEE5️");
    } else if (name.equalsIgnoreCase("blackship")) {
      ship.setLogo("⚓");
    }

    // coloring
    if (name.equalsIgnoreCase("whiteship")) {
      ship.setColor("whiteship");
    } else if (name.equalsIgnoreCase("blackship")) {
      ship.setColor("black");
    }

    // notify
    sendEmailTo(email, ship);

    return ship;
  }

  private static void prepareFor(String name) {
    System.out.println(name + " 만들 준비 중");
  }

  private static void sendEmailTo(String email, Ship ship) {
    System.out.println(ship.getName() + " 다 만들었습니다.");
  }

}

public class Client {

  public static void main(String[] args) {
    Ship whiteship = ShipFactory.orderShip("Whiteship", "keesun@mail.com");
    System.out.println(whiteship);

    Ship blackship = ShipFactory.orderShip("Blackship", "keesun@mail.com");
    System.out.println(blackship);
  }

}

orderShip은 name과 color에 따라 로직이 변경된다.

Ship에 신규 특성이 추가되면, (Yellowship, ...) orderShip 로직이 계속 변경되어 OCP에 어긋나게 된다. 변경에 닫혀있지 않게 된다.

예시 (to-be)

public class Ship {

  private String name;

  private String color;

  private String logo;

  public String getName() {
    return name;
  }

  public void setName(String name) {
    this.name = name;
  }

  public String getColor() {
    return color;
  }

  public void setColor(String color) {
    this.color = color;
  }

  public String getLogo() {
    return logo;
  }

  public void setLogo(String logo) {
    this.logo = logo;
  }

  @Override
  public String toString() {
    return "Ship{" +
        "name='" + name + '\'' +
        ", color='" + color + '\'' +
        ", logo='" + logo + '\'' +
        '}';
  }

}

public Whiteship extends Ship {

  public Whiteship() {
    setName("whiteship");
    setLogo("\uD83D\uDEE5️");
    setColor("white");
  }

}

public Blackship extends Ship {

  public Blackship() {
    setName("blackship");
    setLogo("⚓");
    setColor("black");
  }

}

public interface ShipFactory {

  default Ship orderShip(String name, String email) {
    validate(name, email);
    prepareFor(name);
    Ship ship = createShip();
    sentEmailTo(email, ship);
    return ship;
  }

  Ship createShip();

  private void validate(String name, String email) {
    // validate
    if (name == null || name.isBlank()) {
      throw new IllegalArgumentException("배 이름을 지어주세요.");
    }
    if (email == null || email.isBlank()) {
      throw new IllegalArgumentException("연락처를 남겨주세요.");
    }
  }

  private void prepareFor(String name) {
    System.out.println(name + " 만들 준비 중");
  }
  
  private void sendEmailTo(String email, Ship ship) {
    System.out.println(ship.getName() + " 다 만들었습니다.");
  }

}

public class WhiteshipFactory implements ShipFactory {

  @Override
  public Ship createShip() {
    return new Whiteship();
  }

}

public class BlackshipFactory implements ShipFactory {

  @Override
  public Ship createShip() {
    return new Blackship();
  }

}

public class Client {

  public static void main(String[] args) {
    Ship whiteship = new WhiteshipFactory.orderShip("Whiteship", "keesun@mail.com");
    System.out.println(whiteship);

    Ship blackship = new BlackshipFactory.orderShip("Blackship", "keesun@mail.com");
    System.out.println(blackship);
  }

}

WhiteShip이 있는 와중에, BlackShip을 추가하려고 해도 BlackshipFactory와 Blackship만 생성하면 되기 때문에 WhiteshipFactory와 Whiteship에 코드 변경을 요하지 않는다. OCP를 충족시킨 코드가 되었다.

예시 (to-be) : Client에 DI 적용하기

// ...

public class Client {

  public static void main(String[] args) {
    Client client = new Client();
    client.print(new WhiteshipFactory(), "whiteship", "keesun@mail.com");
    client.print(new BlackshipFactory(), "blackship", "keesun@mail.com");
  }

  // shipFactory를 메서드 파라미터로 의존성 주입 (DI)
  private void print(ShipFactory shipFactory, String name, String email) {
    System.out.println(shipFactory.ordership(name, email));
  }

}

활용

단순한 팩토리 패턴
- 매개변수의 값에 따라 또는 메서드에 따라 각기 다른 인스턴스를 리턴하는 단순한 버전의 팩토리 패턴
- java.lang.Calendar 또는 java.lang.NumberFormat
스프링의 BeanFactory
- Object 타입의 Product를 만드는 BeanFactory라는 Creator이고, 그것에 대한 구현체가 ClassPathXmlApplicationContext, AnnotationConfigApplicationContext이다.
- Product는 Object이고, getBean시 가져오는 값이 ConcreteProduct가 된다.

출처
https://www.inflearn.com/course/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4

[Design Pattern] Singleton Pattern (싱글톤 패턴)

ilot — Sat, 12 Nov 2022 21:34:40 +0900

싱글톤 패턴 (Singleton Pattern)

인스턴스를 오직 한개만 제공하는 클래스
시스템 런타임, 환경 세팅에 대한 정보 등 인스턴스가 여러 개일 때 문제가 생길 수 있는 경우가 있다. 인스턴스를 오직 한 개만 만들어 제공하는 클래스가 필요하다.

싱글톤 패턴

예시 (as-is)

public class Settings {

}

public class App {
  
  public static void main(String[] args) {
    Settings settings = new Settings();
    Settings settings1 = new Settings();
    System.out.println(settings != settings1);
  }
  
}

싱글톤 패턴을 적용하려면, 위 settings != settings1에서 false가 나와야 한다.

예시 (싱글톤 패턴을 가장 단순히 구현하는 방법, thread-safe 하지 않음)

public class Settings {

  private static Settings instance;

  private Settings() {}
  
  public static Settings getInstance() {
    if (instance == null) { // A
      instance = new Settings(); // B
    }
    
    return instance;
  }

}

public class App {
  
  public static void main(String[] args) {
    Settings settings = Settings.getInstance();
    Settings settings1 = Settings.getInstance();
    System.out.println(settings != settings1);
  }
  
}

웹 애플리케이션은 보통 멀티 쓰레드로 구현하게 되는데, 위 싱글톤 객체를 thread-safe하지 않다.

두 쓰레드가 Settings.getInstance()로 접근했을 때, 한 쓰레드가 A를 거쳐 B로 진입한 뒤, 다른 쓰레드가 A로 들어왔다고 가정해보자. 그러면 다른 쓰레드가 A를 판별할 때, 한 쓰레드에서 new Settings()를 아직 거치지 못해 instance는 null일 수 있다. 따라서, 한 쓰레드와 다른 쓰레드의 Settings 객체가 달라질 수 있다.

예시 (멀티 쓰레드 환경에서 안전하게 구현하는 방법)

sychronized

public class Settings {

  private static Settings instance;

  private Settings() {}
  
  public static synchronized Settings getInstance() {
    if (instance == null) {
      instance = new Settings();
    }
    
    return instance;
  }

}

public class App {
  
  public static void main(String[] args) {
    Settings settings = Settings.getInstance();
    Settings settings1 = Settings.getInstance();
    System.out.println(settings != settings1);
  }
  
}

java에서 지원하는 synchronized 키워드는 여러 개의 스레드가 한 개의 자원을 사용하고자 할 때, 현재 데이터를 사용하고 있는 해당 스레드를 제외하고 나머지 스레드들은 데이터에 접근 할 수 없도록 막는다. 하지만 getInstace를 한 쓰레드만 사용할 수 있기 때문에, 성능 저하가 발생할 수 있다.

이른 초기화 (eager initialization)

public class Settings {

  private static final Settings INSTANCE = new Settings();

  private Settings() {}
  
  public static Settings getInstance() {
    return INSTANCE;
  }

}

public class App {
  
  public static void main(String[] args) {
    Settings settings = Settings.getInstance();
    Settings settings1 = Settings.getInstance();
    System.out.println(settings != settings1);
  }
  
}

생성자를 통해 객체를 생성하는 게 큰 자원이 소모되지 않는다면, instance를 미리 초기화할 수 있다.

double checked locking 사용하기

이른 초기화 방식으로 하기에는 생성자 호출 자원이 너무 크고, synchronized 방식으로 하기에는 자원 낭비가 걱정된다면, double checked locking 방식을 사용하여 효율적인 synchronized 블록을 만들 수 있다.

public class Settings {

  private static volatile Settings instance;

  private Settings() {}
  
  public static Settings getInstance() {
    if (instance == null) { // A
      synchronized (Settings.class) { // B
        if (instance == null) { // C
          instance = new Settings(); // D
        }
      }
    }
    return instance; // E
  }

}

public class App {
  
  public static void main(String[] args) {
    Settings settings = Settings.getInstance();
    Settings settings1 = Settings.getInstance();
    System.out.println(settings != settings1);
  }
  
}

두 쓰레드가 Settings.getInstance()로 접근했을 때, 한 쓰레드가 A를 거쳐 B, C로 진입한 뒤, 다른 쓰레드가 A, B로 들어왔다고 가정해보자. 한 쓰레드가 synchronized 블록을 마칠때까지 다른 쓰레드는 B에서 wait 한다. 한 쓰레드가 D에서 생성자를 호출하고, synchronized 블록을 마치면 다른 쓰레드가 synchronized 블록에 진입이 가능해지고, 다른 쓰레드는 C에서 false가 나오기 때문에, D를 거치지 않고 return문 E를 타고 메서드를 마친다. 제3자 쓰레드는 이미 instance가 만들어져 있으므로, A -> E를 타고 instance를 반환할 것이다.

getInstance 호출 때마다 동기화 처리를 하지 않기 때문에, synchronized 방식에 비해 효율적이다.

여기서 volatile을 사용하지 않으면, 인스턴스가 두개 이상 발생할 수 있다.

키워드 volatile이란, java 변수를 Main Memory에 저장하겠다는 것을 명시한다. volatile이 명시된 변수의 값을 읽을 때마다, CPU cache에 저장된 값이 아닌 Main Memory에서 읽는다. volatile이 명시된 변수의 값을 변경할 때마다, Main Memory에서도 수정이 일어난다.

멀티 쓰레드 애플리케이션에서의 non-volatile 변수에 대한 작업은 성능상의 이유로 CPU cahce를 사용한다. 따라서, 위 Settings instance를 volatile 처리하지 않으면, 멀티 쓰레드 환경 아래 각각 쓰레드는 instance를 CPU Cache에서 읽어오게 되는데, 한 쓰레드에서 instance를 변경해도, 다른 쓰레드에서 변경한 값이 보이지 않을 수가 있다. 즉, instance가 Main Memory로부터 실시간으로 동기화 되었다는 사실을 보장할 수 없다.

static inner 클래스 사용하기

위 double checked locking 방식은 유용하나, volatile 키워드 때문에 java 1.5 이상에서만 동작한다. 따라서 1.5 이하 버전에서도 활용될 수 있는 static inner 클래스를 사용하도록 하자.

public class Settings {

  private Settings() {}
  
  private static class SettingsHolder {
    private static final Settings INSTANCE = new Settings();
  }
  
  public static Settings getInstance() {
    return SettingsHolder.INSTANCE;
  }

}

public class App {
  
  public static void main(String[] args) {
    Settings settings = Settings.getInstance();
    Settings settings1 = Settings.getInstance();
    System.out.println(settings != settings1);
  }
  
}

클래스는 Singleton 클래스가 Load 될 때에도 Load 되지 않다가 getInstance()가 호출됐을 때 비로소 JVM 메모리에 로드되고, 인스턴스를 생성하게 된다.

INSTANCE가 static이기 때문에 초기화가 이루어진다. LazyHolder 클래스가 초기화 되면서 INSTANCE 객체도 Settings의 생성자의 의해 생성도 이루어지며, 이 과정에서 static이기 때문에 하나의 인스턴스만 생성되는 것을 보장해준다. 그리고 final로 선언했기 때문에 다시 instance가 할당되는 것 또한 막을 수 있다.

static inner 클래스 사용 시 싱글톤 구현 방법을 깨뜨리는 방법

리플렉션 사용

public class Settings {

  private Settings() {}
  
  private static class SettingsHolder {
    private static final Settings INSTANCE = new Settings();
  }
  
  public static Settings getInstance() {
    return SettingsHolder.INSTANCE;
  }

}

public class App {
  
  public static void main(String[] args) {
    Settings settings = Settings.getInstance();
    
    Constructor<Settings> declaredConstructor = Settings.class.getDeclaredConstructor();
    declaredConstructor.setAccessible(true);
    Settings settings1 = declaredConstructor.newInstance();
    
    System.out.println(settings != settings1); // true
  }
  
}

직렬화와 역직렬화 사용하기

public class Settings implements Serializable {

  private Settings() {}
  
  private static class SettingsHolder {
    private static final Settings INSTANCE = new Settings();
  }
  
  public static Settings getInstance() {
    return SettingsHolder.INSTANCE;
  }

}

public class App {
  
  public static void main(String[] args) throws IOException {
    Settings settings = Settings.getInstance();
    Settings settings1 = null;
    
    try (ObjectOutput out = new ObjectOutputStream(new FileOutputStream("settings.obj"))) {
      out.writeObject(settings); // 직렬화되어 파일로 써졌다.
    }
    
    try (ObjectInput in = new ObjectInputStream(new FileInputStream("settings.obj"))) {
      settings1 = (Settings) in.readObject(); // 파일을 역직렬화 하였다.
    }
    
    System.out.println(settings != settings1); // true
  }

}

예시 (안전하고 단순하게 구현하는 방법)

public enum Settings {

  INSTANCE;

}

public class App {
  
  public static void main(String[] args) throws IOException {
    Settings settings = Settings.INSTANCE;
    Settings settings1 = Settings.INSTANCE;
    
    System.out.println(settings != settings1); // false
  }

}

enum은 Serializable을 구현하고 있기 때문에, 직렬화 & 역직렬화를 해도 기존 객체를 가져온다.
리플렉션은 enum의 constructor 사용을 금하고 있다.
단, JVM이 구동될 때 미리 생성된다. 그리고 상속을 쓰지 못하는 단점이 있다.

활용

스프링에서 빈의 스코프 중에 하나인 싱글톤 스코프
다른 디자인 패턴 구현체의 일부로 쓰이기도 한다. (빌더, 퍼사드, 추상 팩토리 등)
자바의 java.lang.Runtime

Runtime runtime = Runtime.getRuntime();

출처
https://www.inflearn.com/course/%EB%94%94%EC%9E%90%EC%9D%B8-%ED%8C%A8%ED%84%B4
https://junghyungil.tistory.com/150

[Spring] 서비스는 트랜잭션, 도메인의 순서 보장 역할만 제공한다

ilot — Wed, 9 Nov 2022 14:00:30 +0900

서론

스프링에서는 @Controller, @Service, @Repository 등의 애노테이션을 사용하여 웹 계층을 분리하고 있다. 이 중 @Service는 사실상 @Component와 기능 차이가 없지만, 스프링에게 해당 클래스가 서비스 레이어 클래스라는 것을 알리는 역할을 한다고 한다. 그렇다면 Service Layer는 무슨 역할을 하는 걸까.

3 tier 아키텍처

보통 스프링 프로젝트는 3 tier 방식으로 구성한다.

프레젠테이션 계층

화면에 보여주는 기술을 사용하는 영역.
컨트롤러에서 사용자의 요청에 맞는 응답처리를 진행하며, HTML엔진(thymeleaf), HTML등이 담당하는 영역.
Spring MVC 객체로, 컨트롤러, DispatcherServlet, 컨트롤러, 뷰, 모델이 포함된다.

서비스 계층

순수한 비지니스 로직을 담고 있는 영역.
이 영역의 설계는 고객의 요구사항과 정확히 일치해야 한다.
프레젠테이션 계층과 데이터 엑세스 계층의 중간다리 역할을 한다.

데이터 엑세스 계층

데이터를 어떤 방식으로 보관하고, 사용하는 가에 대한 설계가 들어가는 계층.
일반적으로 DBMS를 많이 사용하지만, 상황에 따라서 API 호출, NoSQL, Kafka 등의 기술이 포함될 수 있다.
데이터의 CRUD 연산을 수행하는 Mapper와 결과를 객체로 리턴하는 DAO을 포함한다.

오브젝트 중심 아키텍처

3 tier 아키텍처에 확장하여, Layer 간 데이터 전송 객체인 DTO와 특정 특정 도메인을 개념적으로 표현한 것인 Domain Model이 포함된 오브젝트 중심 아키텍처가 존재한다.

오브젝트 중심 아키텍처

Web Layer

흔히 사용하는 Controller와 JSP 등의 뷰 템플릿 영역이다.
이외에도 filter, interceptor, ControllerAdvice 등 외부 요청과 응답에 대한 전반적인 영역이다.
3 tier 아키텍처의 프레젠테이션 계층과 유사하다.

Service Layer

@Service에 사용되는 서비스 영역이다.
일반적으로 Controller와 DAO의 중간 영역으로 사용된다.
@Transactional이 사용되어야 하는 영역이다.
3 tier 아키텍처의 서비스 계층과 유사하다.

Repository Layer

DB와 같이 데이터 저장소에 접근하는 영역이다.
DAO(Data Access Object)영역이다.
3 tier 아키텍처의 데이터 엑세스 계층과 유사하다.

DTOs

DTO(Data Transfer Object)는 계층 간에 데이터 교환을 위한 객체다.
Web Layer에서 사용될 객체나 Repositroy Layer에서 결과로 넘겨주는 객체 등이다.

Domain Model

도메인이라 불리는 개발 대상을 모든 사람이 동일한 관점에서 이해할 수 있고 공유할 수 있도록 단순화시킨 것을 도메인 모델이라고 한다. (ex. 택시앱에서 배차, 탑승, 요금 등은 모두 도메인)
JPA의 경우 @Entity를 사용된 영역이 도메인 모델이다.
다만, 무조건 DB의 테이블과 관계가 있어야만 도메인은 아니다.
VO(Value Object)처럼 값 객체들도 이영역 해당된다.

서비스 차원에서 - 3 tier 아키텍처 vs 오브젝트 중심 아키텍처

주문 취소에 대한 메서드가 있을 때, 각 아키텍처 방식으로 서비스 단에서 cancelOrder를 구현해보았다.

예시 - 3 tier 아키텍처

@Transactional
public Order cancelOrder(int orderId) {
  // 1) 주문정보, 결제정보, 배송정보 조회
  OrdersDto order = ordersDao.selectOrders(orderId);
  BillingDto billing = billingDao.selectBilling(orderId);
  DeliveryDto delivery = deliveryDao.selectDelivery(orderId);
  
  // 2) 배송 취소 여부 확인
  String deliveryStatus = delivery.getStatus();
  
  // 3) 배송중이라면 배송 취소
  if ("IN_PROGRESS".equals(deliveryStatus)) {
    delivery.setStatus("CANCEL");
    deliveryDao.update(delivery);
  }
  
  // 4) 각 테이블에 취소상태 갱신
  order.setStatus("CANCEL");
  ordersDao.update(order);
  
  billing.setStatus("CANCEL");
  billingDao.update(billing);
  
  return order;

}

Service에서 모든 비지니스 로직을 처리하기 때문에 구현이 매우 쉽고 단순하지만 구조가 복잡해질 수록 모듈화의 복잡도도 높아지게 된다.
order, billing, delivery는 단순히 정보만 담겨있고, 모든 로직은 Service 단에 존재한다.

빈약한 도메인 오브젝트

단순히 정보만 담겨있는 오브젝트를 빈약한 (Anemic) 오브젝트라 함
도메인 오브젝트 기능이라 하면 도메인 오브젝트의 비즈니스 로직이라 볼 수 있음
빈약한 도메인 오브젝트의 경우 비즈니스 로직이 전부 서비스 계층에 있기 때문에 거대 서비스 계층구조와 비슷함
도메인 오브젝트는 독립적으로 존재하면서 일관된 구조의 정보를 담아서 전달하는데만 사용됨
SQL에 의존적인 데이터 방식보다 유연하고 간결하지만, 서비스 계층의 메소드에 대부분의 비즈니스 로직이 있기 때문에 재사용성이 떨어지고 중복의 문제가 발생하기 쉬움

예시 - 오브젝트 중심 아키텍처

@Transactional
public Order cancelOrder(int orderId) {
  // 1) 주문정보, 결제정보, 배송정보 조회
  OrdersDto order = ordersDao.selectOrders(orderId);
  BillingDto billing = billingDao.selectBilling(orderId);
  DeliveryDto delivery = deliveryDao.selectDelivery(orderId);

  // 2)배송 취소 여부 확인 - 3)배송중이라면 배송취소
  delivery.cancel();

  // 4)각 테이블에 취소상태 갱신
  order.cancel();
  biling.cancel();

  return order;
}

객체에 객체가 수행해야 하는 업무를 분담시키는 것으로써 Service에서는 트랜잭션, 도메인 간의 순서보장의 역할만을 제공하고 비지니스 로직을 Domain에서 처리하는 방식이다.
order, billing, delivery 각각에 cancel 기능이 담겨있어, 다른 Service에서도 재사용하기 쉬워지고, 코드 가독성이 높아졌다.

풍성한 도메인 오브젝트

정보 저장 뿐만이 아니라, 내부의 정보를 이용하는 기능도 가지고 있는 오브젝트를 풍성한 오브젝트라 한다.
데이터와 데이터를 사용하는 로직을 모아두기 때문에 응집도가 높음
어떤 비즈니스 로직은 특정 도메인 오브젝트와 깊은 관계가 있을 수 있음
해당 로직을 도메인 오브젝트에 넣고, 서비스 계층의 비스니스 로직에서 재사용하도록 함

결론

Service는 비즈니스 로직을 담는 것이 아닌, 트랜잭션 처리와 도메인 모델간의 순서 보장의 역할을 부여하는 것을 지향해야 한다. 비즈니스 로직은 도메인 모델에 넣자.
이로써 얻는 이점은, 재사용성을 높이고 코드 가독성이 좋아진다.

출처
https://ksb-dev.tistory.com/m/210
https://incheol-jung.gitbook.io/docs/study/ddd-start/1
https://hongs-coding.tistory.com/119
토비의 스프링 3.1 Vol. 1 스프링의 이해와 원리 : http://www.yes24.com/Product/Goods/7516721
스프링 부트와 AWS로 혼자 구현하는 웹 서비스 : http://www.yes24.com/Product/Goods/83849117

객체지향의 사실과 오해

ilot — Mon, 7 Nov 2022 17:38:52 +0900

Summary

1장 요약

2장 요약

3장 요약

4장 요약

5장 요약

6장 요약

7장 요약

생각

대학교에서 객체지향 수업을 들을 때, 보통 절차지향과 비교한다. 절차지향은 코드를 작성한 순서대로 프로그램이 진행되고, 객체지향은 객체와 객체 간의 상호작용을 통해 프로그램이 진행된다고. 그러면서 곧바로, 현실 물체를 프로그램 코드인 객체로 변신시키는 게 객체지향의 핵심이고, 원리는 캡슐화, 상속, 추상화, 다형성이 있고, 그 뒤 곧바로 c++의 문법에 대해 배웠던 것 같다. 결국 대학교를 졸업하고 한참 뒤에야, 이 책을 읽으면서 객체지향이란 무엇인가를 곰곰이 되뇌이게 되었다.

본 책을 통해서 간단히 객체지향이 왜 나오게 되었는가, 객체지향을 왜 쓰는가, 객체지향 방식으로 애플리케이션을 설계하려면 어떻게 해야하는 가 등을 알게 되었다. 마치 수학 공식처럼, 단순히 객체지향의 원리를 달달 외운다고 해서, 객체지향의 본질을 깨우칠 순 없는 것 아닌가. 본디 프로그램 설계에는 유스케이스가 있었고, 이에 따라 도메인 모델을 설계하고, 이를 토대로 협력의 내용을 결정하고, 협력을 통해 발생되는 신규 메시지, 인터페이스, 객체까지. 이들의 통합적인 관리와 유연한 유지보수를 위해 객체지향이 필요했고, 그에 따라 캡슐화, 상속, 추상화, 다형성이든, SOLID든, 디자인 패턴이든 나오게 되었던 것 같다.

이에 확장하여 디자인 패턴에 대해 배워보고 싶다. 디자인 패턴이 객체지향에 종속되는 것은 아니지만, 애플리케이션을 설계할 때 단순히 객체간의 상호작용이 아닌, 결국 애플리케이션의 통합적인 관리와 유연한 유지보수를 위함이다. 타 개발자가 나의 코드를 바라보았을 때, 한번에 알아먹을 수 있는 개발자가 되고 싶다는 생각이 들었다.

독서 기간 : 2022-10-01 ~ 2022-11-07
참조 : http://www.yes24.com/Product/Goods/18249021

[Design Pattern] Composite Pattern (컴포지트 패턴)

ilot — Mon, 7 Nov 2022 11:03:44 +0900

출처 : https://www.inflearn.com/course/디자인-패턴

컴포지트 패턴 (Composite Pattern)

그룹 전체와 개별 객체를 동일하게 처리할 수 있는 패턴.
클라이언트 입장에서는 전체나 부분이나 모두 동일한 컴포넌트로 인식할 수 있는 계층 구조를 만든다. (Part-Whole Hierarchy)

컴포지트 패턴

장점

복잡한 트리 구조를 편리하게 사용할 수 있다.
다형성과 재귀를 활용할 수 있다.
클라이언트 코드를 변경하지 않고 새로운 엘리먼트 타입을 추가할 수 있다.

단점

트리를 만들어야 하기 때문에 (공통된 인터페이스를 정의해야 하기 때문에) 지나치게 일반화 해야 하는 경우도 생길 수 있다.

예시 (as-is)

public class Item {

  private String name;
  private int price;
  
  public Item(String name, int price) {
    this.name = name;
    this.price = price;
  }
  
  public int getPrice() {
    return this.price;
  }

}

public class Bag {
  
  private List<Item> items = new ArrayList<>();
  
  public void add(Item item) {
    items.add(item);
  }
  
  public List<Item> getItems() {
    return items;
  }

}

public class Client {

  public static void main(String[] args) {
    Item doranBlade = new Item("도란 검", 450);
    Item healPotion = new Item("체력 물약", 50);
    
    Bag bag = new Bag();
    bag.add(doranBlade);
    bag.add(healPotion);
    
    Client client = new Client();
    client.printPrice(doranBlade);
    client.printPrice(bag);
    
  }
  
  // 아래 printPrice가 client에 구현하는 게 맞나?
  // 리프들에 공통적으로 구현되는 메서드를 interface로 분리하자
  private void printPrice(Item item) {
    System.out.println(item.getPrice());
  }
 
  private void printPrice(Bag bag) {
    int sum = bag.getItems().stream().mapToInt(Item::getPrice).sum();
    System.out.println(sum);
  }

}

예시 (to-be)

// Component
public interface Component {

  int getPrice();

}

// Leaf
public class Item implements Component {

  private String name;
  private int price;
  
  public Item(String name, int price) {
    this.name = name;
    this.price = price;
  }

  @Override
  public int getPrice() {
    return this.price;
  }

}

// Composite
public class Bag implements Component {
  
  private List<Component> components = new ArrayList<>();
  
  public void add(Component component) {
    components.add(component);
  }
  
  public List<Component> getComponents() {
    return components;
  }
  
  @Override
  public int getPrice() {
    return components.stream().mapToInt(Component::getPrice).sum();
  }

}

public class Client {

  public static void main(String[] args) {
    Item doranBlade = new Item("도란 검", 450);
    Item healPotion = new Item("체력 물약", 50);
    
    Bag bag = new Bag();
    bag.add(doranBlade);
    bag.add(healPotion);
    
    Client client = new Client();
    client.printPrice(doranBlade);
    client.printPrice(bag);
    
  }

  private void printPrice(Component component) {
    System.out.println(component.getPrice());
  }

}

활용

자바의 라이브러리 Swing에서의 setVisible

[Design Pattern] 전략 패턴 (Strategy Pattern)

ilot — Sun, 30 Oct 2022 18:35:16 +0900

출처 : https://www.inflearn.com/course/디자인-패턴

전략 패턴 (Strategy Pattern)

여러 알고리즘을 캡슐화하고 상호 교환 가능하게 만드는 패턴.
클라이언트가 직접 컨텍스트에서 사용할 알고리즘을 선택한다.
- 생성자에서, 혹은
- 특정 Operator에서 알고리즘을 선택해서 넘겨줄 수 있다.

장점

새로운 전략을 추가하더라도 기존 코드를 변경하지 않는다. OCP를 완벽하게 지키고 있다.
상속은 한 객체만 가능한데, 이 대신 위임을 사용할 수 있다.
런타임에 전략을 변경할 수 있다.

단점

복잡도가 증가한다.
클라이언트 코드가 구체적인 전략을 알아야 하기 때문에, 의존성이 생긴다.

예시 (as-is)

public class BlueLightRedLight {

  private int speed;
  
  public BlueLightRedLight(int speed) {
    this.speed = speed;
  }

  public void blueLight() {
    if (speed == 1) {
      System.out.println("무 궁 화    꽃  이");
    } else if (speed == 2) {
      System.out.println("무 궁 화 꽃 이");
    } else {
      System.out.println("무궁화꽃이");
    }
  }
  
  public void redLight() {
    if (speed == 1) {
      System.out.println("피 었 습 니   다.");
    } else if (speed == 2) {
      System.out.println("피 었 습 니 다.");
    } else {
      System.out.println("피었습니다.");
    }
  }

}

public class Client {

  public static void main(String[] args) {
    BlueLightRedLight blueLightRedLight = new BlueLightRedLight(2);
    blueLightRedLight.blueLight();
    blueLightRedLight.redLight();
  }
  
}

예시 (to-be : 생성자에서)

public class BlueLightRedLight {

  private Speed speed;
  
  
  public BlueLightRedLight(Speed speed) {
    this.speed = speed;
  }

  public void blueLight() {
    speed.blueLight();
  }
  
  public void redLight() {
    speed.redLight();
  }

} 

public interface Speed {

  void blueLight();
  
  void redLight();

}

public class Normal implements Speed {

  @Override
  public void blueLight() {
    System.out.println("무 궁 화    꽃  이");
  }
  
  @Override
  public void redLight() {
    System.out.println("피 었 습 니   다.");
  }

}


public class Fast implements Speed {

  @Override
  public void blueLight() {
    System.out.println("무궁화꽃이");
  }
  
  @Override
  public void redLight() {
    System.out.println("피었습니다.");
  }

}

public class Client {

  public static void main(String[] args) {
    // BlueLightRedLight blueLightRedLight = new BlueLightRedLight(new Normal());
    
    // 익명 클래스로 주입 가능
    BlueLightRedLight blueLightRedLight = new BlueLightRedLight(new Speed(){
      @Override
      public void blueLight() {
        System.out.println("BLUE LIGHT");
      }
      
      @Override
      public void redLight() {
        System.out.println("RED RIGHT");
      }
    
    });
    
    blueLightRedLight.blueLight();
    blueLightRedLight.redLight();
  }
  
}

예시 (to-be : Operator에서)

public class BlueLightRedLight {

  public void blueLight(Speed speed) {
    speed.blueLight();
  }
  
  public void redLight(Speed speed) {
    speed.redLight();
  }

} 

public interface Speed {

  void blueLight();
  
  void redLight();

}

public class Normal implements Speed {

  @Override
  public void blueLight() {
    System.out.println("무 궁 화    꽃  이");
  }
  
  @Override
  public void redLight() {
    System.out.println("피 었 습 니   다.");
  }

}


public class Fast implements Speed {

  @Override
  public void blueLight() {
    System.out.println("무궁화꽃이");
  }
  
  @Override
  public void redLight() {
    System.out.println("피었습니다.");
  }

}

public class Client {

  public static void main(String[] args) {
    BlueLightRedLight blueLightRedLight = new BlueLightRedLight();

    blueLightRedLight.blueLight(new Normal());
    blueLightRedLight.redLight(new Fast());
  }
  
}

활용

Java의 Comparator

List<Integer> numbers = new ArrayList<>();
numbers.add(10);
numbers.add(5);


// 내림차순 정렬
Collections.sort(numbers, Comparator.reverseOrder());

Collections.sort(numbers, new Comparator<Integer>() {
  @Override
  public int compare(Integer o1, Integer o2) {
    return o1 - o2;
  }
});


// 오름차순 정렬
Collections.sort(numbers);

Collections.sort(numbers, Comparator.naturalOrder());

Spring의 Interface은 대부분 전략패턴이 적용되어 있다.
- ApplicationContext : ClassPathXmlApplicationContext, FileSystemXmlApplicationContext, AnnotationConfigApplicationContext, ...
- PlatformTransactionManager : JdbcTransactionManager, JpaTransactionManager, ...

[Spring] Async

ilot — Fri, 28 Oct 2022 23:05:30 +0900

참조 : https://www.baeldung.com/spring-async

1. 개요

Spring에서 제공하는 비동기 작업과 애노테이션 @Async에 대해서 알아본다.
@Async를 Bean의 메서드에 선언하는 것만으로 해당 메서드는 별도의 쓰레드에서 수행된다. 즉, @Async가 선언된 메서드를 호출하는 객체는 메서드가 끝날 때까지 기다리지 않는다.

2. Async 옵션 켜기

@Configuration과 @EnableAsync를 사용하여 Async 옵션을 켤 수 있다.

@Configuration
@EnableAsync
public class SpringAsyncConfig {
  // ...
}

@EnableAsync의 속성 부여를 통해 다양한 설정이 가능하다.
- annotation : @EnableAsync는 Default로 스프링의 @Async과 EJB 3.1의 javax.ejb.Asynchronous를 탐색한다. 이 옵션을 변경하여 다른 것을 탐색하도록 할 수 있다.
- mode : 사용할 advice의 타입을 지정한다. (JDK 프록시 기반 혹은 AspectJ weaving을 통해)
- proxyTargetClass : 사용할 프록시 타입을 지정한다. (CGLib 혹은 JDK를 통해) 이 속성은 mode가 AdviceMode.PROXY로 지정되었을 때만 작용된다.
- order : AsyncAnnotationBeanPostProcessor가 적용되어야 할 순서를 설정할 수 있다. 기본값으로, 존재하는 모든 프록시 객체를 고려하여 맨 마지막에 적용된다.

3. 애노테이션 @Async

애노테이션 @Async에는 두가지 제한점이 있다. 애노테이션이 지정되는 순간, 프록시 객체 형태로 수행되기 떄문이다.
- 제한점 1 : public 메서드에서만 적용 가능하다.
- 제한점 2 : 동일한 클래스 내에서 호출 시, 비동기 호출이 불가하다.

3.1 아무것도 반환하지 않는 메서드

@Async
public void asyncMethodWithVoidReturnType() {
  System.out.println("Execute method asynchronously. " + Thread.currentThread().getName());
}

3.2 반환값이 있는 메서드

@Async가 지정된 메서드는 Future로 감싼 값을 반환할 수 있다.

@Async
public Future<String> asyncMethodWithReturnType() {
  System.out.println("Execute method asynchronously. " + Thread.currentThread().getName());
  try {
    Thread.sleep(5000);
    return new AsyncResult<String>("hello world");
  } catch (InterruptedException ignored) {
  }

  return null;
}

Spring은 Future를 구현한 클래스 AsyncResult를 제공하여, 비동기 메서드 호출의 결과를 추적할 수 있다.

public void testAsyncAnnotationForMethodsWithReturnType()
  throws InterruptedException, ExecutionException {

  System.out.println("Invoking an asynchronous method. " + Thread.currentThread().getName());

  Future<String> future = asyncAnnotationExample.asyncMethodWithReturnType();

  while (true) {
    if (future.isDone()) {
      System.out.println("Invoking an asynchronous method. " + Thread.currentThread().getName());
      break;
    }

    System.out.println("Result from asynchronous process - " + future.get());
    Thread.sleep(1000);
  }

}

4. 비동기 메서드의 Executor

기본적으로, 스프링은 비동기 메서드를 실행할 때 SimpleAsyncTaskExecutor를 사용한다. 그러나 다른 Executor를 사용하도록 설정할 수 있다.

4.1 메서드 레벨에서 Executor 설정 변경하기

@Configuration
@EnableAsync
public class SpringAsyncConfig {

  @Bean(name = "threadPoolTaskExecutor")
  public Executor threadPoolTaskExecutor() {
    return new ThreadPoolTaskExecutor();
  }

}

@Async("threadPoolTaskExecutor")
public void asyncMethodWithConfiguredExecutor() {
  System.out.println("Execute method with configured executor - " + Thread.currentThread().getName());
}

4.2 애플리케이션 레벨에서 Executor 설정 변경하기

Config 클래스에 AsyncConfigurer를 구현하고, 오버라이드된 getAsyncExecutor()에 변경하고자 하는 Executor를 반환하면 된다.

@Configuration
@EnableAsync
public class SpringAsyncConfig implements AsyncConfigurer {

  @Override
  public Executor getAsyncExecutor() {
    return new ThreadPoolTaskExecutor();
  }

}

5. Exception Handling

반환 타입이 Future인 Async 메서드 실행 중에 Exception 발생 시, Future.get()메서드가 Exception을 던지게 된다.
만일 Async 메서드의 반환 타입이 void라면, Async 메서드 호출하는 곳으로 Exception이 전파되지 않는다. 이 경우에는 추가 설정을 통해 Exception을 처리해야 한다.
아래와 같이, 커스텀 Exception Handler 클래스를 생성하여야 한다. AsyncUncaughtExceptionHandler의 handleUncaughtException에 예외 처리 로직을 넣으면 된다.
클래스를 생성하여, AsyncConfig의 getAsyncUncaughtExceptionHandler()의 반환 값으로 넣어주면 된다.

public class CustomAsyncExceptionHandler implements AsyncUncaughtExceptionHandler {

  @Override
  public void handleUncaughtException(Throwable throwable, Method method, Object... obj) {
    System.out.println("Exception message - " + throwable.getMessage());
    System.out.println("Method name - " + method.getName());
    for (Object param : obj) {
      System.out.println("Parameter value - " + param);
    }
  }

}

@Configuration
@EnableAsync
public class SpringAsyncConfig implements AsyncConfigurer {

  @Override
  public Executor getAsyncExecutor() {
    return new ThreadPoolTaskExecutor();
  }

  @Override
  public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
    return new CustomAsyncExceptionHandler();
  }

}

99. 더 읽어 볼 것

[Java] Collection의 of 사용 시 주의할 점

ilot — Wed, 26 Oct 2022 23:03:59 +0900

Java 9부터 사용할 수 있는 of를 통해 Map, Set, List 등의 Java Collection을 손쉽게 초기화할 수 있습니다.

1. value에 null이 들어가면 안된다.

다만, Map.of(), Set.of(), List.of() 등을 사용할 때, value에 null을 넣게 되면 NullPointerException이 발생합니다.

public class CollectionOfTest {

  @Test(expected = NullPointerException.class)
  public void mapOfTest() {
    Map<String, Object> map = Map.of("key1", null); // NullPointerException 발생
  }

  @Test(expected = NullPointerException.class)
  public void listOfTest() {
    List<String> list = List.of("a", null); // NullPointerException 발생
  }

  @Test(expected = NullPointerException.class)
  public void setOfTest() {
    Set<String> set = Set.of("a", null); // NullPointerException 발생
  }

}

2. Map.of()에는 개수 제한이 있다

key를 11개를 넣어보니..

key-value 쌍을 10개까지만 오버라이드 된 것을 확인할 수 있다.

Map.of()에는 개수 제한이 있으므로, 11개 이상의 Map을 초기화 하고 싶다면 Map.ofEntries()를 사용해야 한다.

참고로, Set.of()와 List.of()는 파라미터를 가변인자로 받고 있기 때문에, 파라미터 개수 제한이 없다.

List.of()

Set.of()

3. of()와 ofEntries()는 Immutuable 객체를 반환한다.

of와 ofEntries는 Immutable 객체를 반환하므로, 이를 반환받은 객체에 put이나 remove가 불가능하다.

@Test(expected = UnsupportedOperationException.class)
public void immutableTest() {
  Map<String, Object> map = Map.of("key01", "a");
  map.put("key2", "test"); // UnsupportedOperationException 발생
}

참조 : https://velog.io/@sangwoo0727/Map.of-를-통한-Map-초기화-주의할-점