[Chapter05] 이미 데이터 중심적으로 구현된 프로그램을 효율적으로 개선하려면 어떻게 해야할까요?

[YJGwon]

희망편은 처음 설계부터 객체중심적으로 해나가는 것일 테지만, 실제로 실무에서는 이미 데이터 중심적으로 만들어진 코드를 다루게 될 일도 많은 것 같아요. 이미 데이터 중심적으로 설계된 코드는 변경이 어려워서 리팩토링 역시 큰 비용을 수반하게 되는데요, 이럴 경우에 어떤 시점에 리팩토링을 해야 비용 측면에서 실용적인 리팩토링을 할 수 있을까요? 또, 어떻게 리팩토링해야 단계적으로 개선해나갈 수 있을까요?

[pythonstrup]

• 와우 너무 날카롭고 좋은 질문인데요??!?
• 리팩토링하기 가장 좋은 시점은 코드 스멜이 강하게 느껴질 때인 것 같아요!
  • 예를 들어, 새로운 기능을 추가하려고 하는데 기존 코드의 강한 결합도 때문에 좀처럼 진행이 안될 때 리팩토링을 할 것 같습니다.
  • 강제로 기능을 붙이려고 하면 오히려 기회비용이 커질 것 같아요!

단계적 개선

1. 가장 이상적인 구조를 먼저 생각해 본다. 설계를 다시 해본다. (사실 저는 1번은 잘 안하는 거 같아요...ㅋㅋㅋㅋ)
   • 현재 객체의 행동을 전부 정리한다.
   • 객체의 행동에 따라 객체의 협력을 재정의해보거나 새로운 객체를 추가해본다.
2. 캡슐화할 수 있는 기능들을 먼저 캡슐화해본다.
3. 객체를 추가해 책임을 나눠본다.
4. 객체의 역할이 보인다면 추상화(인터페이스, 추상클래스)를 통해 역할을 정의하고 구현체를 나눠본다.

추상화가 가장 나중인 이유는?

• 섣부른 추상화는 항상 참사를 부르는 것 같아요.
• 그래서 저는 역할이 명확해보일 때까지 추상화에 대한 판단을 미뤄요!

[pythonstrup]

책임 분리

• 4장에서는 ReservationAgency에 집중되어 있는 로직을 각각의 객체로 캡슐화하는 작업은 이미 진행했습니다. (2번의 작업)
  • 코드 내용: https://github.com/mobilohas/object/tree/main/example/src/main/java/chapter04/bell/improvement
• 여기서는 4장의 코드를 개선하기 위해 3번의 작업을 수행해볼게요!
• Screening과 Movie에서 할인 금액 계산이라는 책임을 분리해볼 수 있을 것 같아요. 할인에 대한 행동과 상태를 DiscountPolicy라는 객체로 떼어내볼 수 있을 것 같습니다.
  • MovieType보다는 DiscountType 네이밍이 맞는 것 같아 이름을 변경해봤습니다.

public class Screening {

  private Movie movie;
  private int sequence;
  private LocalDateTime whenScreened;

  public Screening(final Movie movie, final int sequence, final LocalDateTime whenScreened) {
    this.movie = movie;
    this.sequence = sequence;
    this.whenScreened = whenScreened;
  }

  public Money calculateFee(final int audienceCount) {
    return movie.calculateFee(whenScreened, sequence).times(audienceCount);
  }
}

public class Movie {

  private String title;
  private Duration runningTime;
  private Money fee;
  private DiscountPolicy discountPolicy;

  public Movie(final String title, final Duration runningTime, final Money fee, final DiscountPolicy discountPolicy) {
    this.title = title;
    this.runningTime = runningTime;
    this.fee = fee;
    this.discountPolicy = discountPolicy;
  }

  public Money calculateFee(LocalDateTime whenScreened, int sequence) {
    return fee.minus(discountPolicy.calculateDiscountAmount(whenScreened, sequence));
  }
}

• 덤으로 isDiscountable라는 구현을 캡슐화할 수 있게 되었네요!

public class DiscountPolicy {

  private DiscountType discountType;
  private Money discountAmount;
  private double discountPercent;
  private List<DiscountCondition> discountConditions;

  public Money calculateDiscountAmount(LocalDateTime whenScreened, int sequence, Money movieFee) {
    if (!isDiscountable(whenScreened, sequence)) {
      return Money.ZERO;
    }
    return switch (discountType) {
      case AMOUNT_DISCOUNT -> discountAmount;
      case PERCENT_DISCOUNT -> movieFee.times(discountPercent);
      case NONE_DISCOUNT -> Money.ZERO;
    };
  }

  private boolean isDiscountable(LocalDateTime whenScreened, int sequence) {
    for (DiscountCondition condition : discountConditions) {
      if (condition.getType().equals(DiscountConditionType.PERIOD)) {
        if (condition.isDiscountable(whenScreened.getDayOfWeek(), whenScreened.toLocalTime())) {
          return true;
        }
      } else {
        if (condition.isDiscountable(sequence)) {
          return true;
        }
      }
    }
    return false;
  }
}

• 이 정도만 해도 코드가 좋아진 게 눈에 띄네요.
  • 불필요한 예외 처리가 사라졌습니다.
  • Screening과 Movie가 할인에 대한 정보를 너무 많이 가지고 있었는데 해당 로직이 DiscountPolicy에 캡슐화되면서 책임이 명확해지고 가독성도 더 좋아진 것 같아요.

[pythonstrup]

역할 분리

• DiscountType로 역할을 나누고 있는데, 추상클래스로 나누면 훨씬 좋을 것 같네요!
  • isDiscountable이라는 구현을 같이 사용해보려 합니다.
  • isDiscountable의 접근제한자를 private에서 protected로 수정했습니다. (상속받은 객체들에서 사용해야 하기 때문에)

public abstract class DiscountPolicy {

  private List<DiscountCondition> discountConditions;

  public DiscountPolicy(final List<DiscountCondition> discountConditions) {
    this.discountConditions = discountConditions;
  }

  public Money calculateDiscountAmount(LocalDateTime whenScreened, int sequence, Money movieFee) {
    if(isDiscountable(whenScreened, sequence)) {
      return calculateDiscountPolicyAmount(whenScreened, sequence, movieFee);
    }
    return Money.ZERO;
  }

  protected boolean isDiscountable(LocalDateTime whenScreened, int sequence) {
    for (DiscountCondition condition : discountConditions) {
      if (condition.getType().equals(DiscountConditionType.PERIOD)) {
        if (condition.isDiscountable(whenScreened.getDayOfWeek(), whenScreened.toLocalTime())) {
          return true;
        }
      } else {
        if (condition.isDiscountable(sequence)) {
          return true;
        }
      }
    }
    return false;
  }

  abstract protected Money calculateDiscountPolicyAmount(
                       LocalDateTime whenScreened, int sequence, Money movieFee);
}

• 이제 type은 필요 없을 것 같아요! 각각의 구현체가 타입 역할을 대신하기 때문에요!

public class AmountDiscountPolicy extends DiscountPolicy {

  private Money discountAmount;

  public AmountDiscountPolicy(
      final Money discountAmount,
      final List<DiscountCondition> discountConditions) {
    super(discountConditions);
    this.discountAmount = discountAmount;
  }

  @Override
  public Money calculateDiscountPolicyAmount(
      final LocalDateTime whenScreened, final int sequence, final Money movieFee) {
    return discountAmount;
  }
}

public class PercentDiscountPolicy extends DiscountPolicy {

  private double discountPercent;

  public PercentDiscountPolicy(
      final double discountPercent,
      final List<DiscountCondition> discountConditions) {
    super(discountConditions);
    this.discountPercent = discountPercent;
  }

  @Override
  public Money calculateDiscountPolicyAmount(
      final LocalDateTime whenScreened, final int sequence, final Money movieFee) {
    return movieFee.times(discountPercent);
  }
}

public class NoneDiscountPolicy extends DiscountPolicy {

  public NoneDiscountPolicy(final List<DiscountCondition> discountConditions) {
    super(discountConditions);
  }

  @Override
  public Money calculateDiscountPolicyAmount(
      final LocalDateTime whenScreened, final int sequence, final Money movieFee) {
    return Money.ZERO;
  }
}

[pythonstrup]

• 여기서 더 해볼 수 있는 것들
  • DiscountCondtion의 역할 분리를 진행할 수 있습니다.
  • 메소드에 인자가 너무 많이 전달되고 있고 있습니다. 객체로 캡슐화하여 전달할 수 있습니다.

[JisuPark-dev]

밸이 위에서 단계적 개선을 4가지 단계로 말씀해주셨는데요! 1번이 안된 상태에서 캡슐화하면 적절하지 못한 책임이 캡슐화될 것 같아요. (왠지 모비닥에는 그런 경우가 많은 것 같아요...!) 그래서 모비닥 만약에 리팩토링하게 된다면, 설계부터 그려본 후에 캡슐화를 시도해볼 것 같습니다!