'오브젝트: 코드로 이해하는 객체지향 설계' 2주차
분량 : 6장 ~ 10장
기간 : 22.5.15 ~ 22.5.21
클래스는 도구에 불과하다.
애플리케이션은 클래스의 집합으로 구성되는 것이 아닌 메시지를 통해 정의된다.
객체지향 애플리케이션의 가장 중요한 재료는 객체들이 주고받는 메시지 즉, 객체가 수행하는 책임이다.
condition.isSatisfiedBy(screening)
condition : 수신자
isSatisfiedBy : 오퍼레이션명
screening : 인자
condition의 실제 타입에 따라 isSatisfiedBy 구현이 달라지기 때문에 구현된 isSatisfiedBy가 메서드가 된다.
ex)
condition은 DiscountCondition이라는 인터페이스 타입으로 정의돼 있지만 실제로 실행되는 코드는 인터페이스를 실체화한 클래스의 종류에 따라 달라짐
condition이 PeriodCondition의 인스턴스라면 PeriodCondition에 구현된 isSatisfiedBy 메서드가 실행됨
하나의 오퍼레이션에 대해 오직 하나의 메서드만 존재하는 경우 세상은 꽤나 단순해진다. 이런 경우에는 굳이 오퍼레이션과 메서드를 구분할 필요가 없다. 하지만 다형성의 축복을 받기 위해서는 하나의 오퍼레이션에 대해 다양한 메서드를 구현해야만 한다. 따라서 오퍼레이션의 관점에서 다형성이란 동일한 오퍼레이션 호출에 대해 서로 다른 메서드들이 실행되는 것이라고 정의할 수 있다.
좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스다.
책임 주도 설계를 통해 메시지를 먼저 선택함으로써 협력과는 무관한 오퍼레이션이 인터페이스에 스며드는 것을 방지
클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 프로그래밍 해야한다.
캡슐화의 원칙이 클래스 내부의 구현을 감춰야 한다는 사실을 강조한다면 디미터 법칙은 협력하는 클래스의 캡슐화를 지키기 위해 접근해야 하는 요소를 제한한다.
Ex
// 디미터 법칙을 위반하는 코드
screening.getMovie().getDiscountConditions();
수신자의 내부 구조에 대해 물어보고 반환받은 요소에 대해 연쇄적으로 메시지를 전송한다.
=> 기차 충돌(train wreck)
// 수정된 코드
screening.calculateFee(audienceCount)
디미터 법칙과 묻지 말고 시켜라는 훌륭한 설계 원칙이지만 절대적인 법칙은 아니다.
설계가 트레이드오프의 산물이라는 것을 잊지 마라.
원칙이 현재 상황에 부적합하다고 판단된다면 과감하게 원칙을 무시하라. 원칙을 아는 것보다 더 중요한 것은 언제 원칙이 유용하고 언제 유용하지 않은지를 판단할 수 있는 능력을 기르는 것이다.
아래 코드는 디미터 법칙에 위배되는 코드인가?
IntStream.of(1, 15, 20, 3, 9).filter(x -> x > 10).distinct().count();
그렇지 않다. of, filter, distinct 메서드는 모두 IntStream이라는 동일한 클래스의 인스턴스를 반환한다.
단지 IntStream을 다른 IntStream으로 변환할 뿐 ,객체를 둘러싸고 있는 캡슐은 그대로 유지된다.
루틴 : 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈
루틴 = 프로시저(procedure) + 함수(function)
명령 : 객체의 상태를 수정하는 오퍼레이션
쿼리 : 객체와 관련된 정보를 반환하는 오퍼레이션
Ex) 문제되는 코드
public class Event {
private String subject;
private LocalDateTime from;
private Duration duration;
public boolean isSatisfied(RecurringSchedule schedule) {
if (from.getDayOfWeek() != schedule.getDayOfWeek() ||
!from.toLocalTime().equals(schedule.getFrom()) ||
!duration.equals(schedule.getDuration())) {
// 문제점
reschedule(schedule);
return false;
}
return true;
}
isSatisfied 메서드는 Event 객체의 상태를 수정하고, 값을 반환한다.
명령과 쿼리의 두 가지 역할을 동시에 수행하고 있다.
=> isSatisfied를 두번 실행했을 경우 한번을 false, 한번은 true가 되므로 디버깅과 코드 예측이 어려워진다.
public boolean isSatisfied(RecurringSchedule schedule) {
if (from.getDayOfWeek() != schedule.getDayOfWeek() ||
!from.toLocalTime().equals(schedule.getFrom()) ||
!duration.equals(schedule.getDuration())) {
return false;
}
return true;
}
// event class를 이용하는 다른 class의 메서드
if(!event.isSatisfied(schedule)) {
event.reschedule(schedule);
}
명령과 쿼리를 분리하면 코드는 예측 가능하고 이해하기 쉬우며 디버깅이 용이한 동시에 유지보수가 수월해질 것이다.