오브젝트 Ch.6

Manx·2022년 5월 18일
0
post-thumbnail

'오브젝트: 코드로 이해하는 객체지향 설계' 2주차
분량 : 6장 ~ 10장
기간 : 22.5.15 ~ 22.5.21

Ch.6 메시지와 인터페이스

클래스는 도구에 불과하다.
애플리케이션은 클래스의 집합으로 구성되는 것이 아닌 메시지를 통해 정의된다.
객체지향 애플리케이션의 가장 중요한 재료는 객체들이 주고받는 메시지 즉, 객체가 수행하는 책임이다.

메시지, 메시지 전송, 메서드, 오퍼레이션

  • 메시지(message) : 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단
  • 메시지 전송 or 패싱 : 한 객체가 다른 객체에게 도움을 요청하는 것
  • 메시지 = 오퍼레이션명(operation name) + 인자(argument)
  • 메시지 전송 = 수신자 + 메시지
condition.isSatisfiedBy(screening)

condition : 수신자
isSatisfiedBy : 오퍼레이션명
screening : 인자

condition의 실제 타입에 따라 isSatisfiedBy 구현이 달라지기 때문에 구현된 isSatisfiedBy가 메서드가 된다.

ex)
condition은 DiscountCondition이라는 인터페이스 타입으로 정의돼 있지만 실제로 실행되는 코드는 인터페이스를 실체화한 클래스의 종류에 따라 달라짐
condition이 PeriodCondition의 인스턴스라면 PeriodCondition에 구현된 isSatisfiedBy 메서드가 실행됨

하나의 오퍼레이션에 대해 오직 하나의 메서드만 존재하는 경우 세상은 꽤나 단순해진다. 이런 경우에는 굳이 오퍼레이션과 메서드를 구분할 필요가 없다. 하지만 다형성의 축복을 받기 위해서는 하나의 오퍼레이션에 대해 다양한 메서드를 구현해야만 한다. 따라서 오퍼레이션의 관점에서 다형성이란 동일한 오퍼레이션 호출에 대해 서로 다른 메서드들이 실행되는 것이라고 정의할 수 있다.

인터페이스와 설계 품질

좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스다.

  • 최소한의 인터페이스 : 꼭 필요한 오퍼레이션만을 인터페이스에 포함
  • 추상적인 인터페이스 : 어떻게 수행하는지가 아닌 무엇을 하는지를 표시

책임 주도 설계를 통해 메시지를 먼저 선택함으로써 협력과는 무관한 오퍼레이션이 인터페이스에 스며드는 것을 방지

디미터 법칙

  • 객체 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라.
  • 낯선 자에게 말하지 말라
  • 오직 인접한 이웃하고만 말하라

클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 프로그래밍 해야한다.

  • this 객체
  • 메서드의 매개변수
  • this의 속성
  • this의 속성인 컬렉션의 요소
  • 메서드 내에서 생성된 지역 객체

캡슐화의 원칙이 클래스 내부의 구현을 감춰야 한다는 사실을 강조한다면 디미터 법칙은 협력하는 클래스의 캡슐화를 지키기 위해 접근해야 하는 요소를 제한한다.

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);
}

명령과 쿼리를 분리하면 코드는 예측 가능하고 이해하기 쉬우며 디버깅이 용이한 동시에 유지보수가 수월해질 것이다.


명령어 프로그래밍과 함수형 프로그래밍

  • 명령어 프로그래밍 : 상태를 변경시키는 연산들을 적절한 순서대로 나열함으로써 프로그램을 작성
  • 함수형 프로그래밍 : 부수효과가 존재하지 않는 수학적인 함수에 기반
    참조 투명성의 장점을 극대화할 수 있으며, 실행 결과를 이해하고 예측하기가 더 쉽다.
profile
백엔드 개발자

0개의 댓글