[오브젝트] 6장 '메시지와 인터페이스'

6장에서는 퍼블릭 인터페이스(객체가 수신하는 메시지)를 작성하기 위한 설계 원칙을 알려준다.

 

- 디미터 법칙

- 묻지 말고 시켜라

- 의도를 드러내는 인터페이스

- 명령-쿼리 분리 원칙

 

설계 원칙을 조합하면 직관적이고, 예측 가능하며, 유연한 퍼블릭 인터페이스를 만들 수 있다. 

 

메시지 = 오퍼레이션명 + 인자

메시지 전송 = 오퍼레이션명 + 인자 + 메시지 수신자

시그니처 = 오퍼레이션(메소드)명 + 파라미터목록

 

디미터 법칙

협력하는 객체의 내부 구조에 대한 결합으로 인해 발생하는 설계 문제를 해결하기 위해 제안된 원칙

-> 점(.)을 하나만 사용하자 use only one dot

 

// 안좋은 예 (train wreck)
screening.getMovie().getDiscountConditions();

 

내부 상태를 묻는 오퍼레이션을 행동을 요청하는 오퍼레이션으로 바꾸자.

그리고 인터페이스는 어떻게 하는지가 아니라 무엇을 하는지 얘기해야 한다. 

 

// 점이 연달아 나와 안좋은 예처럼 보이지만 IntStream의 내부 구조가 
// 외부로 노출되지 않기 때문에 디미터 법칙을 위반한 것은 아니다. 

IntStream.of(1, 15, 20, 3, 9).filter(x -> x > 10).distinct().count();

 

디미터 법칙의 위반 여부는 묻는 대상이 객체인지, 자료 구조인지에 달려있다. 

- 객체는 내부구조를 숨겨야 하고

- 자료 구조는 내부를 노출해야 한다.

 

 

명령-쿼리 분리 원칙

Command-Query Seperation - 질문이 답변을 수정해서는 안된다. 

 

루틴(routine) 은 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈이고

루틴은 다시 프로시저(procedure)와 함수(function)로 구분된다. 

 

루틴

- 프로시저(명령/command) :

-> 부수효과(side effect)를 발생시킬 수 있지만 값을 반환할 수 없다.

-> 객체의 상태를 수정하는 오퍼레이션 (반환값없음)

- 함수(쿼리/query) :  

-> 값을 반환할 수 있지만 부수효과를 발생시킬 수 없다. 

-> 객체의 정보를 반환하는 오퍼레이션 (상태 변경할 수 없음)

 

 

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

명령형 프로그래밍(imperative programming)

- 부수효과를 기반으로 하는 프로그래밍

- 대부분의 객체지향 언어들이 여기에 속함 -> 메시지에 의한 객체의 상태 변경에 집중하기 때문에

 

함수형 프로그래밍(functional programming)

- 부수효과가 존재하지 않는 수학적인 함수에 기반함.

- 참조 투명성(referential transparency)의 장점 극대화 및 프로그래밍의 실행결과를 이해하고 예측하기 쉬움

- 하드웨어의 발달로 병렬 처리가 중요해진 최근에는 함수형 프로그래밍의 인기가 더 높다. 

 

 

지금 하고 있는 개인 프로젝트는 폴더구조를 DDD 방식으로 도메인을 command랑 query로 나누어서 작성하고 있다. 단순히 조회를 요청하는 경우가 많으니까 query를 따로 뺐다고 생각했는데, 객체지향적인 관점에서 상태를 수정하는 오퍼레이션과 객체의 정보를 반환하는 오퍼레이션을 구분해 놓으면 버그가 적고, 디버깅이 용이하며, 쿼리의 순서에 따라 실행결과가 변하지 않는 코드를 작성할 수 있어서 참조 투명성의 장점을 조금이나마 누릴 수 있다고 한다. 

 

command와 query의 뜻을 정확히 알 수 있게 되어서 이번 장은 좀 더 재밌게 읽은 것 같다. 

 

 

// TODO 

병렬 처리란 무엇인가? 자바스크립트는 함수형 프로그래밍인가?