⭐️ 들어가며

자주 강조하지만 객체지향 애플리케이션의 가장 중요한 재료는 클래스가 아닌 객체들이 주고받는 메시지다.

애플리케이션은 클래스로 구성되지만 메시지를 통해 정의된다.

객체가 수신하는 메시지들이 객체의 퍼블릭 인터페이스를 구성한다. 훌륭한 퍼블릭 인터페이스를 얻기 위해서는 책임 주도 설계 방법을 따르는 것만으로는 부족하다.
유연하고 재사용 가능한 퍼블릭 인터페이스를 만드는 데 도움이 되는 설계 원칙과 기법을 익히고 적용해야 한다. 이런 원칙과 기법들을 살펴보는 것이 이번 장의 주제이다.

⭐️ 협력과 메시지

📌 클라이언트 - 서버 모델

협력은 어떤 객체가 다른 객체에게 무언가를 요청할 때 시작된다. 메시지는 객체 사이의 협력을 가능하게 하는 매개체이다.

협력 안에서 메시지를 전송하는 클라이언트, 메시지를 수신하는 서버라고 표현하는 클라이언트 - 서버 모델이 있다.

• Switch: 클라이언트
• Hitter: 서버

Switc가 Hitter에 온도를 높이라고 요청하면 Hitter는 열에너지를 주게 된다.
이 같은 경우는 우리가 Rest API 통신을 통해 많이 겪게 되는 상황인데, 프론트와 백엔드가 분리된 서버에서 자주 마주칠 수 있는 상황이다.
Hitter는 또 다른 객체에게 클라이언트 입장으로 존재할 수 있다. 가령 전기 에너지를 얻기 위해 다른 객체를 찾을 수 있다.

📌 메시지와 메시지 전송

메시지(message)

• 개체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단
• 한 객체가 다른 객체에게 도움을 요청하는 것을 메시지 전송(message sending) 또는 메시지 패이싱(message passing)라고 한다.
  • 이때 메시지를 전송하는 객체를 메시지 전송자(message sender)라고 부르고 메시지를 수신하는 객체를 메시지 수신자(message receiver)라고 부른다.
    • 클라이언트 - 서버 모델 관점에서는 메시지 전송자는 클라이언트, 메시지 수진자는 서버라고 부르기도 한다.
• 메시지는 오퍼레이션명(operation name)과 인자(argument)로 구성된다.

메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저를 메서드라고 부른다.

메시지와 메서드의 구분은 메시지 전송자와 메시지 수신자가 느슨하게 결합될 수 있게 한다. 메시지 전송자는 자신이 어떤 메시지를 전송해야 하는지만 알면 된다. 수신자가 어떤 크래스의 인스턴스인지, 어떤 방식으로 요청을 처리하는지 모르더라도 원활한 협력이 가능하다. 메시지 수신자 역시 누가 메시지를 전송하는지 알 필요가 없다. 단지 메시지가 도착했다는 사실만 알면 된다.

📌 퍼블릭 인터페이스와 오퍼레이션(operation)

퍼블릭 인터페이스

• 객체가 의사소통을 위해 외부에 공개하는 메시지의 집합
  • 퍼블릭 인터페이스에 포함된 메시지를 오퍼레이션(operation)이라고 부른다.
    • 오퍼레이션은 수행 가능한 어떤 행동에 대한 추상화다.

📌 시그니처(signature)

시그니처(signature)

• 오퍼레이션(또는 메서드)의 이름과 목록을 합친 것
  • 오퍼레이션은 실행 코드 없이 시그니처만을 정의한 것이다. 메서드는 이 시그니처에 구현을 더한 것이다. 일반적으로 메시지를 수신하면 오퍼레이션의 시그니처와 동일한 메서드가 실행된다.

⭐️ 인터페이스 설계 품질

좋은 인터페이스

• 최소한의 인터페이스
• 추상적인 인터페이스

최소주의를 따르면서도 추상적인 인터페이스를 설계할 수 있는 가장 좋은 방법은 책임 주도 설계 방법을 따르는 것이다. 그러나 책임 주도 설계 방법이 훌륭한 인터페이스를 얻을 수 있는 지침을 제공한다고 하더라도 올바른 설계에 도달하기 위해서는 훌륭한 인터페이스가 가지는 공통적인 특징을 알아야 한다.

퍼블릭 인터페이스의 품질에 영향을 미치는 원칙과 기법

• 디미터 법칙(Law of Demeter)
  • 오직 하나의 도트(.)만 사용하라(use only one dot)
    • 디미터 법칙을 따르기 위해서는 클래스가 특정한 조건을 만족하는 대상에게만 메시지를 전송하도록 프로그래밍해야 한다.
    • 디미터 법칙은 캡슐화를 다른 관점에서 표현한 것이다.
    • 디미터 법칙을 위반하는 코드: screening.getMovie().getDiscountConditions();
• 묻지 말고 시켜라(Tell, Don't Ask)
  • 객체의 상태에 대해 묻지 말고 시켜라. 상태 기반으로 결정을 내리면 후에 객체의 상태를 변경시킨다면? 어디서 값이 변경된건지 찾기 위해 헤맬 가능성이 있다. 상태를 묻는 오퍼레이션보다 행동을 요청하는 오퍼레이션으로 대체해서 인터페이스를 향상시키자.
• 의도를 드러내는 인터페이스(Intention Revealing Interface)
  • 구현과 관련된 모든 정보를 캡슐화하고 객체의 퍼블릭 인터페이스에는 협력과 관련된 의도만을 표현해야 한다.

⭐️ 원칙의 함정

설계는 트레이드오프의 산물이다. 적용하려는 원칙과 기법들을 모든 사례에 억지로 끼워맞추려고 한다면 부적합한 상황에서도 무질서한 코드가 생성될 수 있다. 원칙을 어느부분에서 적용하고 적용하지 않을까, 어느부분에서 적용하면 유용하게될까를 고민하자.

디미터의 법칙중. 하나의 도트만을 사용하라는 것은 list.stream.filter.~~~ 와 같은 곳에서도 적용하라는 것이 아니다.
이 메서드 체이닝은 동일한 클래스의 인스턴스를 반환한다. builder패턴의 경우에도 동일하다.
이처럼 기차 충돌과 같은 코드여도 외부에 정보를 노출하지 않는다면 디미터 법칙을 준수한 것이다.

묻지않고 시켜라가 적용 될 경우가 있는데 자료구조의 객체의 경우 내부를 노출해야하는데, 결국에 내부정보를 Public하게 공유해야한다.
객체에 시키는 것이 항상 가능하지 않다. 가끔은 물어보아야한다.

⭐️ 명령 - 쿼리 원칙

필요에 따라 물어야 한다는 사실을 이해한다면 명령-쿼리 원칙을 알아보자.

용어

• 루틴: 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈
• 프로시저: 정해진 절차에 따라 내부 상태를 변경하는 루틴의 한 종류
• 함수: 정해진 절차에 따라 필요한 값을 계산해서 반환하는 루틴의 한 종류

명령 - 프로시저와 동일한 개념으로 보고 쿼리 - 함수와 동일한 개념으로 본다.

---

명령과 쿼리를 분리해서 얻는 장점이 무엇일까??
가장 큰 장점은 코드가 예측하기 쉬워진다는 것이다.
가령 코드를 보면

public int findItemNo(Someclass someclass) {
  someClass.setItemNo(5);
  return someClass.getItemNo();
}

분명 아이템 이름을 찾으라고 메서드를 명명해놓고 파라미터를 받는 객체의 상태를 변경한 후 이 값을 리턴한다.

그렇다면 이 someClass 아무도 모르게 상태변경이 되어버린 것이다.

이처럼 메서드를 통해 예측할 수 없는 결과가 나온다면 버그가 발생할 수도 있고 디버깅하기 위해 메서드들을 샅샅히 찾아보아야 한다.

분리를 하자

public void changeItemNo(SomeClass someClass, int itemNo) {
  someClass.itemNo = itemNo;
}
public int changeItemNo(SomeClass someClass) {
  return someclass.getItemNo();
}

물론 위의 코드들은 내부 구현을 통해 getter와 setter방식으로 짤 수 있겠지만. 요점은 메서드가 구현하는 기능에 대해서 명령 쿼리로 분리하는 것이다.

컴퓨터에서 명령은 부수효과(중간에 상태가 변하는)를 가져다 주는데, 이 부수효과가 아예 존재하지 않다면 불변성(상태가 변하지 않음)을 족하며 참조 투명성 즉, 해당 기능에 어디에 입력되어도 같은 결과를 반환하는 결과를 주게된다.

객체지향은 상태변경이라는 부수효과를 기반으로 생각하기 때문에 참조투명성은 예외에 가깝다.

그러나, 명령-쿼리 원칙으로 이 간극을 최대한 줄일 수 있다.

---

출처
오브젝트 - 코드로 이해하는 객체지향 설계
https://github.com/eternity-oop/object