[Chapter05] 파라미터 - 캡슐화 위반

[pythonstrup]

• 2장의 설계가 훨씬 좋다는 것에 동의합니다. 다만 이런 경우는 없을까? 하는 생각이 들어 남겨봅니다.

public boolean isDiscountable(DayOfWeek dayOfWeek, LocalTime time)를 살펴보자. 이 메소드는 객체 내부에 DayOfWeek와 LocalTime 타입의 시간 정보가 포함되어 있다는 사실을 외부에 노출하고 있다.... public boolean isDiscountable(int sequence) 메소드 역시 객체가 int 타입의 순번 정보를 포함하고 있음을 외부에 노출한다.... 만약 DiscountCondition의 속성을 변경해야 한다면 어떻게 될까? 아마도 두 isDiscountable 메소드의 파라미터를 수정하고 해당 메소드를 사용하는 모든 클라이언트도 함께 수정해야 할 것이다. (126p)

• 파라미터로 노출되어 있기 때문에 DiscountCondition의 속성이 변경되면 isDiscountable()에 전달되는 파라미터 또한 수정되어야 한다고 하는데요. 변경이 필요한 점은 2장의 설계 또한 마찬가지 아닌가라는 생각이 들었어요.
• 2장에서 나온 설계를 보면 Screening 객체 통으로 해당 파라미터들이 전달됩니다. 어차피 DiscountCondition의 구현체의 속성이 수정되면 Screening이 변경되어야 합니다.
  • 메소드 파라미터를 수정할 필요는 없지만 Screening의 변수가 수정되어야 합니다. (1계층 타고 들어가야 하기 때문에 귀찮을 수도..?)
  • 그렇다면 경우에 따라선 책임 중심 설계로 만든 코드의 수정 비용은 오히려 더 클 수도 있지 않을까?라는 이상한 생각이 들었습니다.

참고

• 2장의 경우, DiscountCondition가 인터페이스입니다. 각각의 구현체가 가진 속성 값을 개성있게 구성할 수 있습니다. 반면 4장의 DiscountCondition는 모든 할인 조건의 요구사항을 전부 가지고 있는 구현체입니다.

[JisuPark-dev]

public class PeriodCondition implements DiscountCondition {

  private DayOfWeek dayOfWeek;
  private LocalTime startTime;
  private LocalTime endTime;

  public PeriodCondition(final DayOfWeek dayOfWeek, final LocalTime startTime,
                         final LocalTime endTime) {
    this.dayOfWeek = dayOfWeek;
    this.startTime = startTime;
    this.endTime = endTime;
  }

  @Override
  public boolean isSatisfiedBy(final Screening screening) {
    return screening.getStartTime().getDayOfWeek().equals(dayOfWeek)
        && startTime.compareTo(screening.getStartTime().toLocalTime()) <= 0
        && endTime.compareTo(screening.getStartTime().toLocalTime()) >= 0;
  }
}

[JisuPark-dev]

위 코드로 제가 이해하기로는 condition의 속성값이 변하더라도, isSatisfiedBy의 인터페이스(Screening으로 요청했을 때 boolean을 반환한다)는 변하지 않고, 내부 구현만 변하게 되므로 해당 인터페이스를 사용하고 있는 곳까지 영향이 퍼지는 것을 막는 다는 점에서 캡슐화가 잘 되어있다고 생각합니다.

다만, 말씀하신데로 변경사항이 screening에 속성들에도 영향을 끼쳐서, screening의 생성을 수정해야한다면, 어쩌면 영향도가 더 커질 것 같다는 생각이 드네요.

[pythonstrup]

"의존성의 방향은 안정적인 방향으로 흘러야 한다." by @YJGwon